RE: Web Notifications I18N Review: [I18N-ISSUE-161, I18N-ISSUE-162]

Doug Turner responded:
> 
> > 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.
> 
> No.  Our implementation will know exactly who requested the notification.

That wasn't the "anonymous" I meant, though. Suppose I offer a service that users can subscribe to that pushes notifications (stock prices, baseball scores, weather updates, etc.). Does the sender have to individually compose the notifications according to each user's language preference as separately negotiated in advance?

> 
> > 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.
> 
> I am not in favor of encouraging people to do things in an API that can't be
> implemented uniformly.  On most systems (cocoa, windows, linux, android) we
> just can implement them properly.

Uniformly bad implementation is not a benefit. My hope would be that, having specified it, implementers would then do a good job of processing these values.

For language-related information, legacy systems often are developed to work in a homogenous environment---all users share a configuration, language, etc. On distributed, heterogeneous systems, like the Web, this works less well, which is why language information because important. [Direction information is always important]

> 
> > We are not asking that Web Notifications make direction or language
> *obligatory*, only that they are available.
> 
> Addison, do you know why these existing system notification systems have been
> quite successful without these properties available?  Have you heard of any
> demand for such attributes?

Your observation is one I sometimes hear when I bring internationalization requirements to developers. I think that it supposes that an "imperfect" notification system has no utility when compared to having no notification system at all. 

Have I heard demand for such attributes? Why yes I have :-). In my day job I've been implementing several notification type systems.

The bidi case, as Asmus mentioned earlier on this thread, cannot be avoided. While completely right-to-left or left-to-right content works without additional information, mixed direction content in right-to-left languages is common and cannot be properly displayed without additional "help" to the Unicode bidirectional algorithm.

Please take a look back at some of the bidi references, for example:

   http://www.w3.org/International/questions/qa-bidi-controls


   http://www.w3.org/International/docs/html-bidi-requirements/


These documents show several examples of why directional markup is a requirement and why it is immaterial whether existing notification systems have implemented it or not: they are broken without it. Systems that do not provide an API for base directionality sometimes can be worked around by adding additional Unicode bidi controls to the content.

Similarly, systems use language information to control rendering or handling of text. If you implemented a notifications handler that read the text aloud, perhaps for visually impaired users, you would want language attributes in order to select the correct "voice" and "dictionary" for generating the TTS. Or you can use the language information to select fonts or provision language-specific features related to the content of the notification. While omitting language information is not the same barrier to presentation as the lack of bidi markup is, language metadata is valuable and ultimately systems that do not provide language metadata work less well than those that do.

A trivial example that I have is here:

   http://inter-locale.com/test/lang-attr-test.html


Notice how Firefox is using language information to do something useful: in this case, altering the shapes of the apostrophe and ellipsis characters according to user expectations in the English text and selecting fonts in the Asian texts. The untagged text produces a "ransom note" effect.

> 
> I prefer to just inherent the language/direction from the document that makes
> the notification request.  This keeps the API neat and simple.  If it becomes
> clear that this isn't enough and/or more systems start supporting i18n directly
> in their notification API, we should reconsider.
> 

Direction and language both have scope--while they can be set at the document level, they can both be set at the local element level as well. You're assuming that documents themselves are homogenous, which isn't always so. 

I tend to favor simple, neat APIs myself. But omitting direction and language is ignoring the fact that these are necessary to display natural language text correctly on the Web.

It is unlikely that international users will come looking for us waving pitchforks, torches, and requirements if we don't add these now. But they will notice that things don't work so well (and not be able to fix it for themselves). I know it seems counterintuitive that a system can't display something as simple as a string without any additional fuss or metadata. But it turns out that displaying language-bearing text is not quite that simple.

Best regards,

Addison

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.

Received on Tuesday, 3 July 2012 17:04:11 UTC