Update the index.html to address the i18n issue

[MichaelWangzitao]

Update the MiniApp Manifest index.html to address the i18n issues, I rewrite section 6 add a subsection to provide an i18n solution. #4 #5 #6， @aphillips @zhangyongjing @xfq

---

Preview | Diff

[xfq]

Suggested change

	<p>i18n/en-US.json</p>
	</div>
	<pre class="example json">
	<pre class="example json" title="i18n/en-US.json">

[xfq]

Suggested change

	<p>i18n/zh-Hans.json</p>
	</div>
	<pre class="example json">
	<pre class="example json" title="i18n/zh-Hans.json">

[xfq]

Note that this is a solution for the localization problem, but did not solve the string metadata problem, i.e., multiple natural language text fields still share the same language/direction, so it won't close issue #4, #5, and #6.

[MichaelWangzitao]

Note that this is a solution for the localization problem, but did not solve the string metadata problem, i.e., multiple natural language text fields still share the same language/direction, so it won't close issue #4, #5, and #6.

---

I'm not sure about it. This proposal allows multiple natural language text fields to be dynamically filled with local language information, such as description, which is filled with "$string:description_application" on the manifest but is actually be translated into the corresponding local language.

[xfq]

Localization of the whole manifest and language/direction metadata of strings are two different issues.

Localization

IIUC this pull request solves the localization problem.

For example, for the following manifest:

{
  "dir": "ltr",
  "lang": "en-US",
  "appID": "org.w3c.miniapp",
  "name": "$string:name",
  "short_name": "string:short_name",
  "description": "$string:description_application",
}

We can add the following to i18n/zh-Hans.json:

{
    "strings": { 
      "name":"小程序试用版",
      "short_name":"小程序",
      "description_application":"迷你程序试用版本",
    }
}

If the language of the app store is Simplified Chinese, the app store will parse the "name": "$string: name" object in the manifest, and extract the information from the zh-Hans.json file in the i18n directory.

String metadata

The language of a miniapp is Hebrew does not mean that all strings in the manifest are RTL, and the language of a miniapp is Japanese does not mean that all strings in the manifest are ja (for example, it may be a Chinese language learning app for Japanese people, and the app name is in Simplified Chinese, if the language is marked as ja instead of zh-Hans, the font may be incorrect).

For example, if we have a miniapp whose name is Easy as one שתיים three.

If the miniapp is an English miniapp (dir is ltr), it will display as expected:

If the miniapp is a Hebrew miniapp (dir is rtl), without stipulating the base direction for the string, the order of the items will change, and begin to be unreadable or misleading:

You can see the result by looking at how browsers render the following HTML snippet:

<p dir="ltr">Easy as one שתיים three</p>
<p dir="rtl">Easy as one שתיים three</p>

We can't change the manifest-wide dir from rtl to ltr, because other information (such as the description) may need to be in rtl.

Although miniapp developers could theoretically apply the Unicode directional formatting characters, they are not easy to type and it can be difficult for the developer to know how to use the characters effectively.

This is just one example use case for string-specific directional information, and there are others as well.

[espinr]

Closing this PR because we will use the i18n WG localizable manifest recommendations and follow the Web App manifest approach.