W3C home > Mailing lists > Public > public-sysapps@w3.org > June 2013

Re: Manifest internationalization Model

From: Charles McCathie Nevile <chaals@yandex-team.ru>
Date: Sun, 16 Jun 2013 09:41:07 +1000
Cc: "Janusz Majnert" <j.majnert@samsung.com>, public-sysapps@w3.org
To: "Marcos Caceres" <w3c@marcosc.com>, "Jonas Sicking" <jonas@sicking.cc>
Message-ID: <op.wyrgytjny3oazb@131-113-150-203.event.mita.keio.ac.jp>
On Tue, 12 Mar 2013 18:42:43 +0900, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, Mar 12, 2013 at 2:18 AM, Marcos Caceres <w3c@marcosc.com> wrote:
>> On Tuesday, 12 March 2013 at 09:00, Janusz Majnert wrote:
>>> 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?
>> In W3C widgets they are in the same file, but you are correct that in  
>> Google's format it is in a separate file.
>>> 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.
>> This advantage comes at a cost (for packaged apps). The Google format  
>> allows for large scale localisation of applications - it also provides  
>> an i18n API for working with localised data that neither W3C widgets  
>> nor API FxOS provides. This is not a bad thing, as JS libraries can be  
>> used to fill this gap - you just don't get this functionality out of  
>> the box, like you do with Google's Apps.

Well, it provides for working with text strings. Other stuff (customised
images, styles, etc) are pretty painful :(

>> While developing W3C widgets, at least one large organisation raised  
>> concerns about not being able to split the localisation tasks across  
>> multiple files, as it made it harder for them to distribute the work of  
>> localising content to their localisation centres around the world (as  
>> everything is in one file).

Yeah. But then apart from the manifest data, the google stuff looks worse
for this use case.

> I definitely think that we should add better support for i18n for
> apps. But it needs to be looked at in the greater perspective of i18n
> for the web. I'm hesitant to build an app-specific solution for web
> content when the problem doesn't seem very different than for
> webpages.

I think this is a shame...

In fact there are some significant differences. There is no server-side to
do language negotiation, or manage cookies, or many of the things that
make the base-level of Web internationalisation "work".



Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
         chaals@yandex-team.ru         Find more at http://yandex.com
Received on Sunday, 16 June 2013 07:41:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:36:13 UTC