- From: Phillips, Addison <addison@lab126.com>
- Date: Thu, 28 Jun 2012 09:18:01 -0700
- To: Anne van Kesteren <annevk@annevk.nl>, Norbert Lindenberg <w3@norbertlindenberg.com>
- CC: Doug Turner <dougt@mozilla.com>, "www-international@w3.org" <www-international@w3.org>, "public-web-notification@w3.org" <public-web-notification@w3.org>, "Olli.Pettay" <opettay@mozilla.com>
Anne wrote: > <w3@norbertlindenberg.com> wrote: > > Or can there be senders that just have no information at all about the > > user's preferred languages? > > No, the application "knows" the language (assuming it is localized to begin > with). That's always the case on the web, localization is a server affair. Having > said that, the notification can still be in another language. E.g. when I book a > ticket via Flying Blue rather than KLM the email I get will be in French (god > knows why) which presumably would be partially quoted in the body of a > notification. > I don't quite agree about localization being a "server affair". While that's true for the static HTML experience, it's not as much the case with Web apps. With internationalization of JavaScript on the horizon, it will become even less the case, since we can quit calling the server to format our messages for us! Still, it sounds as if Web Notifications can assume that the language has already been "negotiated". Can there be "anonymous Web Notifications"? That would be the use case for having multiple language title/body items. > > > Language detection unfortunately is quite unreliable for short > > strings, so there's no equivalent "auto". > > I tend to think we should wait and see if people run into actual problems here. > It is quite trivial to add language in the future too. > Is it normal for whenever an application exposes just a string there's always a > language and direction field associated with it? Strings containing natural language text need direction and language. Not all applications can provide them nor can all implementations can make use of them. This does not invalidate cases for those that can. For bidi, we have the HTML requirements document [1] that gives numerous examples. For language, one need look no further than font fallbacks to see why, for example, Japanese and Chinese users get a better experience when the language is set at draw time. Not all strings have natural language text in them. Not all strings need both or even one of the attributes. But when you need it and don't have it available, the lack is keenly felt. This particular pairing (@lang/@dir) is one of the most frequent comments that the I18N WG emits on specs as a result. > Doug seems to be saying > direction is already missing sometimes. Language is even more obscure (and > often wrong on the web, too). > We want to encourage people to do the right things, or at least make it possible. Direction and/or language metadata are often missing or unavailable, in which case the Notification won't be able to include them. But our goal is to ensure that it is *possible* to include the necessary information and get the correct results. We are not asking that Web Notifications make direction or language *obligatory*, only that they are available. Addison [1] http://www.w3.org/International/docs/html-bidi-requirements/ See also: http://www.w3.org/International/questions/qa-bidi-unicode-controls Addison Phillips Globalization Architect (Lab126) Chair (W3C I18N WG) Internationalization is not a feature. It is an architecture.
Received on Thursday, 28 June 2012 16:18:35 UTC