W3C home > Mailing lists > Public > public-i18n-core@w3.org > January to March 2015

Re: ICYMI: [manifest] I18N review in progress

From: Marcos Caceres <w3c@marcosc.com>
Date: Mon, 2 Mar 2015 12:27:24 +1000
To: addison@lab126.com
Cc: public-i18n-core@w3.org
Message-ID: <etPan.54f3cb04.1190cde7.667b@Zero-privacy.local>
Hi Addison, i18n Core, 

> -------- Forwarded Message --------
> Subject: [manifest] I18N review in progress
> Date: Thu, 26 Feb 2015 16:54:58 +0000
> From: Phillips, Addison 

Thank you for the feedback thus far. 

> There are two concerns that I want to note in advance that perhaps you can clarify:
> 1. There is no localization model or apparently a means of finding out about the availability  
> of different languages of a given app, including alternate icons, names, short names  
> and such. I'm curious as to whether there is an intention to provide this capability? 

It is not our intention to provide this. The languages of an application are provided by the UI of a web page itself, not the manifest. So, to swap language, an web developers would provide a preference within the web application itself.  

Furthermore, the manifest is a lazy-loaded (or potentially never loaded!) resource, hence can't be relied on to provide authoritative information about the languages of application. 

The background for this decision is here: 

> What do authors of localized web applications do?

Our proposals is that authors localize content on the server instead. So:

<link rel="manifest" href="manifest?lang=jp"> 

In case of another language swap, the author simply updates the href attribute of the link element to point to the correct localized manifest (by either refreshing the page or using JS). 

> 2. There is no provision for language or bidirectional control for natural language  
> text inside a manifest. For example, you can't tag the name of an app as being in Japanese  
> (necessary for correct font selection by the host environment, for example) or to set  
> the base direction of the name (so that mixed right-to-left and left-to-right text is  
> drawn correctly).

As JSON is Unicode, the expectation is that developers would use appropriate unicode markers to set direction for mixed-direction content. Would that be sufficient? 

I've (re)opened an issue about this on Github:
Received on Monday, 2 March 2015 02:29:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:02:05 UTC