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

RE: ICYMI: [manifest] I18N review in progress

From: Phillips, Addison <addison@lab126.com>
Date: Tue, 3 Mar 2015 16:57:12 +0000
To: Marcos Caceres <w3c@marcosc.com>
CC: "public-i18n-core@w3.org" <public-i18n-core@w3.org>
Message-ID: <7C0AF84C6D560544A17DDDEB68A9DFB52EC37B4C@ex10-mbx-9007.ant.amazon.com>
Some personal comments follow.

> > 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.

I think there are two problems here. This problem has to do with metadata *about* the localization of a given Web application--that is, what languages/locales it is available in. There are many ways that a Web application might negotiate language with the user (Accept-Language header, navigator.language, IP address sniffing, user cookie, usw.) and these cannot easily be expressed in the manifest. Maybe this is irrelevant to what you're trying to do here.

> 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.

This seems extremely suspect to me. The manifest can authoritatively provide the endpoint, name, and icon for the application, but not metadata about it?

> The background for this decision is here:
> https://github.com/w3c/manifest/issues/208

I happen to also agree with the original issue here. I agree that the manifest specification is not the place to define language negotiation. If you had a specification that detailed how language negotiation *must* be done, then you could address 208 fully.

However, I would tend to agree with commenters on 208 that providing non-authoritative metadata about application localization is useful.

> > 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">


How do I know to do that? How do I know what languages are available? (Note: the language tag for Japanese is 'ja')

> 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).

What if you have multiple languages for the same Web application? Would you do:

<link lang="en" rel="manifest" href="manifest_en">
<link lang="ja" rel="manifest" hfref="manifest_ja">
<link lang="zh-Hans" rel="manifest" hfref="manifest_zh_Hans">
... etc...

I think you're making the incorrect assumption that 1 page == 1 language == 1 manifest

> > 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?

Let's take this in two parts:

Bidi/Direction: I suppose it would be sufficient from the point of view that a sufficiently motivated speaker of a bidirectional language could make it work. But it is hugely inconvenient. In markup languages we generally discourage the Unicode bidi controls. While the manifest isn't a "markup language" per-se, its contents are generally intended to be used in this kind of context. Bidi isolation alone is insufficient. 

Manifests are likely to be generated automatically, which would thus require having the bidi controls in a context removed from the manifest itself. This creates additional problems for bidirectional language users: they have to know to insert the controls in situations where they would normally use markup.

Put another way, the availability of the Unicode bidi controls does not mean that we don't need to provide an appropriate markup mechanism. Especially since we still need to provide for some other data...

Language: you still need to provide language information about the manifest's natural language content items. Among other things, correct font selection rides on providing language metadata to the text drawing layer. Inferring the language of the text by sniffing the bits is inaccurate or impractical. The best practice is to provide this as additional data.

Note that this is about information *inside* the manifest. I often have the case where I need separate display strings that are localized for the *same* Web application--whether the Web application is localized or not. Lacking a localization model within the manifest means that there has to be a means of generating many manifests and then retrieving the "correct" one for my needs. Further, the manifest itself won't contain what language the strings inside it are in.

Hope this helps,


Received on Tuesday, 3 March 2015 16:57:47 UTC

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