- From: Scott Wilson <scott.bradley.wilson@gmail.com>
- Date: Tue, 12 Mar 2013 10:25:48 +0000
- To: 전종홍 <hollobit@etri.re.kr>
- Cc: Janusz Majnert <j.majnert@samsung.com>, "public-sysapps@w3.org" <public-sysapps@w3.org>, "'public-webappstore@w3.org'" <public-webappstore@w3.org>, Melvin Carvalho <melvincarvalho@gmail.com>
- Message-Id: <9037F978-34F3-4A7B-AECD-AF66F8484C4D@gmail.com>
Note also that W3C P&C has localization of the metadata within the manifest; the separate files are for localized versions of the content (images, html, xml etc).
On 12 Mar 2013, at 10:07, 전종홍 wrote:
> BTW, we need to start to talk about the standardized manifest format.
>
> This is a draft comparison table for the manifest in the Web Stores.
> (It compares three types of manifest format : W3C Widget, Mozilla App Store, Chrome Store)
>
> http://www.w3.org/community/webappstore/wiki/Manifest
> (excel format : https://docs.google.com/spreadsheet/ccc?key=0AqtcXb4fZGyCdHlSX3RWY0ExSzk3bndyYnFHZlNlZVE&usp=sharing )
>
> Best Regards,
>
> --- Jonathan Jeon
>
> -----Original Message-----
> From: Janusz Majnert [mailto:j.majnert@samsung.com]
> Sent: Tuesday, March 12, 2013 6:01 PM
> To: public-sysapps@w3.org
> Subject: Re: Manifest internationalization Model
>
>
> Hi,
> If I understand correctly, in Firefox OS the localised strings are in the main manifest file, while in Widgets P&C and Google's format, separate files are used? If so, I think Firefox OS model has the advantage that for hosted apps the user gets localised UI (app name, author etc) before actually installing the app. This makes hosting the app a bit easier.
>
> /Janusz
>
> On 2013-03-11 18:11, Marcos Caceres wrote:
>> Hi,
>> TL;DR: We need to settle on an i18n model for the manifest format. We have a few options here (based on the membership of the group):
>>
>> 1. Firefox OS's model [1].
>> 2. Google packaged apps's [2].
>> 3. W3C Packaged Web Apps (widgets) i18n model [3].
>>
>> Each of the models have their own pros and cons. Below I describe each model.
>>
>> My recommendation is that we use the FireFox OS one, but with a few modifications:
>>
>> * Mozilla's i18n model currently only supports language tags with only two sub-tags. This should be fixed to allow three or more sub tags (I've got confirmation from Mozilla that they are willing to change this: https://bugzilla.mozilla.org/show_bug.cgi?id=846269). However, this depends on affected populations of people (see discussion on www-international: http://lists.w3.org/Archives/Public/www-international/2013JanMar/0305.html).
>>
>> * Language tag decomposition should follow BCP47's lookup algorithm (and an "application locale" should be derived from the union of the user agent locale and the manifest's declared locales).
>>
>> * The application locale should be exposed in JS through an interface.
>>
>> Ok… the rest is the long bla bla for each…. Will maybe put this into the Wiki or something.
>>
>>
>>
>>
>>
>> # Internationalization model of Firefox OS
>>
>> A more human readable version of this section is at [1].
>>
>> This section lists a set of localization scenarios and describes how Firefox OS handles these different use cases. The section makes some recommendations about how particular use cases could be better addressed.
>>
>> To simplify the discussion, this document assumes the runtime is running in locale "en-US".
>>
>> ## CASE 1 - No localisation information.
>>
>> *Use case:* The author does not wish to explicitly localize any content.
>>
>> ```JSON
>> {
>> "name": "foo"
>> }
>> ```
>>
>> *FxOS:* When there is no localized content declared, the user agent just uses what is at the root of the manifest. Hence, the name of the app is "foo".
>>
>> ## CASE 2 - No default locale
>>
>> *Use case:* The author provides the required ```name``` member, but chooses to localize the application's name for the "en-US" locale. However, the author neglects to add the ```default_locale``` member.
>>
>> ```JSON
>> {
>> "name": "unknown-locale name",
>> "locales": {
>> "jp": {
>> "name": "jp name"
>> },
>> "en-US": {
>> "name": "en-US name"
>> }
>> }
>> }
>> ```
>>
>> *FxOS:* Despite there not being any ```default_locale```, the user agent still chooses "en-US name" as the name for the application. When neither localized content matches, the value at the root of the manifest is selected.
>>
>> ## CASE 3 - No default locale, multiple matching ranges
>>
>> *Use case:* The author declares the name of the application using a set of variants of the English language. The author omits the ```default_locale``` member.
>>
>> ```JSON
>> {
>> "name": "unknown-locale name",
>> "locales": {
>> "en-US-x-test": {
>> "name": "en-US-x-test name"
>> }
>> "en-US": {
>> "name": "en-US name"
>> },
>> "en": {
>> "name": "en name"
>> }
>> }
>> }
>> ```
>>
>> *FxOS:* The user agent selects the localized content that exactly matches the user agent's default language (so, in this case, "en-US name" is shown).
>>
>> ## CASE 4 - No default locale, with catch all
>>
>> *Use case:* The author declares the name of the application using a set of variants of the English language. However, none of them match the user agent's locale settings exactly. Fortunately, the author has included a catch all ("en").
>>
>> ```JSON
>> {
>> "name": "unknown-locale name",
>> "locales": {
>> "en-AU": {
>> "name": "en-AU name"
>> }
>> "en-GB": {
>> "name": "en-GB name"
>> },
>> "en": {
>> "name": "en name"
>> }
>> }
>> }
>> ```
>>
>> *FxOS:* The user agent first checks for "en-US", but failing that, it selects the next best match, which is "en name".
>>
>> ## CASE 5 - No default locale, multiple matching ranges
>>
>> *Use case:* The author wants to localize the name, but does not need to localize the developer information.
>>
>> ```JSON
>> {
>> "name": "unknown-locale name",
>> "developer": {
>> "name": "unknown-locale author"
>> },
>> "locales": {
>> "en-US": {
>> "name": "en-US name"
>> },
>> "jp":{
>> "name": "jp name"
>> }
>> }
>> }
>> ```
>>
>> *FxOS:* The user agent selects "en-US" as the name, and "unknown-locale author" as the author.
>>
>> ## CASE 6 - No default locale, multiple matching ranges
>>
>> *Use case:* the author wants to localize the developer name but not the developer URL.
>>
>> ```JSON
>> {
>> "name": "unknown-locale name",
>> "developer": {
>> "name": "unknown-locale author",
>> "url": "http://unknown-locale.com/"
>> },
>> "locales": {
>> "en-US": {
>> "developer": {
>> "name": "localized author"
>> }
>> }
>> }
>> }
>> ```
>>
>> *FxOS:* The user agent selects the localized developer name and uses the unknown-locale developer ```url```.
>>
>> ## CASE 7 - Default locale
>> Use case: When the author uses any value for ```default_locale```, but no localized content is given through a ```locale``` member, the author still expects some content to be displayed to the user (even if they user might not be able to understand it).
>
>>
>> ```JSON
>> {
>> "name": "unknown-locale name",
>> "developer": {
>> "name": "unknown-locale author"
>> },
>> "default_locale": "unknown-locale"
>> }
>> ```
>>
>> *FxOS:* The user agent selects "unknown-locale name" as the name of the application.
>>
>> ## CASE 8 - Language tag decomposition and lookup *Use case:*
>>
>> ```JSON
>> {
>> "name": "unknown-locale name",
>> "developer": {
>> "name": "unknown-locale author"
>> },
>> "locales": {
>> "en-US": {
>> "name": "en name"
>> },
>> "en": {
>> "developer": {
>> "name": "en developer"
>> }
>> }
>> },
>> "default_locale": "unknown-locale"
>> }
>> ```
>> The name of the app is "en name".
>>
>> *FxOS:* When neither the ```default_locale``` nor the user agent locale matches any localized content, FxOS just uses the first sub-tag of the language range (in this case, just "en"). So, "en-US" becomes "en" ([see code](https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/AppsUtils.jsm#427)).
>>
>> *[BUG 846269](https://bugzilla.mozilla.org/show_bug.cgi?id=846269)*: Because FxOS currently takes the first subtag in a language range, this will exclude language ranges initially composed of three or more subtags (e.g., zh-Hans-XQ). This means that if the user's regional preference is expressed as "zh-Hans-XQ", the following will not match any localized content (when zh-Hans would have been a reasonable match):
>>
>> ```JSON
>> {
>> "name": "unknown-locale name",
>> "developer": {"name": "unknown-locale author"},
>> "locales": {
>> "zh-Hans": {
>> "name": "zh-Hans name"
>> }
>> },
>> "default_locale": "unknown-locale"
>> }
>> ```
>>
>> ## CASE 9 - Granularity
>> Use case: The author wishes for the name of the application to be localized for a particular locale. However, the author does not want to duplicate the developer information.
>>
>> ```JSON
>> {
>> "name": "您好！颜色",
>> "locales": {
>> "en-US": {
>> "name": "Hi! Color"
>> },
>> "en-AU": {
>> "name": "G'Day! Colour"
>> },
>> "en": {
>> "developer": {
>> "name": "en developer"
>> }
>> }
>> },
>> "developer": {
>> "name": "中国开发者"
>> },
>> "default_locale": "zh-Hans"
>> }
>> ```
>>
>> *FxOS:* The user agent selects "Hi! Color" as the name, but then selects "中国开发者" as the developer. Expected ```"name": "en developer"``` to be selected. Filed [BUG 846432](https://bugzilla.mozilla.org/show_bug.cgi?id=846432).
>>
>> *Proposal:* To address the above, the user agent should arrange the user's preferred locales and decompose them in order (removing any duplicates). So, if the user has "en-US, en-AU, jp" as her preferred language settings, those would decompose to "en-US, en-AU, en, jp".
>>
>>
>> # Chrome i18n Model
>>
>> Chrome's i18n model [2] for localisation of manifest data differs quite significantly from the Mozilla one and the W3C widgets one [3]. In particularly, it's vastly more complicated in that it follows a more traditional software 18n model - some aspects are tightly bound to the Chrome apps store for some fields.
>>
>> Instead of allowing manifest content to be localized within the application manifest itself, all localized content is put into "messages.json" files in a special "_locales/language-TAG" directory (where language-TAG is, for example, en-US). The developer is then required to "key" all localised data and then Chrome reconstructs the localised content by matching keys to a magic string (__MSG_*__). For example:
>>
>> manifest.json
>> ==========
>> "name": "__MSG_application_title__", "description": "__MSG_application_description__"
>>
>>
>> _locales/de/messages.json
>> ===============
>> "application_title": { "message": "Eine lokalisierte gehostete
>> Beispielanwendung" }
>>
>>
>> Then the developer declares what the "default_locale" is, which works as a catch-all for when the user's locale does not match the locale of the application.
>>
>> Chrome then provides an API to access localised strings from within the application itself. Having the API is not a bad thing (as it takes away some of the burden of having to read files from within a package through either XHR or a file reader API), but it does lock the developer into using a particular i18n model.
>>
>> Other none standard features include using custom language tags [2]. These language tags are non-standard in that they don't conform to BCP 47. As such, some region, language, script combinations cannot, theoretically speaking, be adequately expressed. If this affects actual populations of people, I am unsure of.
>>
>>
>> # W3C Packaged Web Apps (widgets) 18n Model.
>> The model is already fully described [3] - with plenty of examples. It supports both manifest level localizations as all directory-based localisation in a manner similar to Google's.
>>
>> http://www.w3.org/TR/widgets/#internationalization-and-localization
>>
>> [1] https://gist.github.com/marcoscaceres/5055717
>> [2] https://developers.google.com/chrome/web-store/docs/i18n
>> [3]
>> http://www.w3.org/TR/widgets/#internationalization-and-localization
>> --
>> Marcos Caceres
>> http://datadriven.com.au
>>
>>
>>
>>
>
>
Received on Tuesday, 12 March 2013 10:26:30 UTC