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

Do you mean the ECMAScript Internationalization API [1, 2]? I don't see how it would help here: It provides collation, number formatting, and date and time formatting, but not language detection or translation.

Norbert

[1] http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts
[2] http://norbertlindenberg.com/2012/02/ecmascript-internationalization-api/index.html


On Jun 27, 2012, at 18:24 , Navarr Barnier wrote:

> Pardon my note, but I do not believe there is a necessary reason to send multiple language strings to the web notification system.
> 
> I believe there is work externally to do localization within ECMAScript as per the existence of Object.toLocaleString.  As such, It may be more proper for localisation to be handled by the JavaScript instead of by the notifications themselves, as their content is provided to them via JavaScript, and it it being in the JavaScript creates a more standard internationalization system between different native APIs, instead of each creating it's own individual internationalization system.
> -----
> Navarr T. Barnier (熊軍平野)
> me@navarr.me
> http://navarr.me/
> 
> 
> 
> On Wed, Jun 27, 2012 at 8:58 PM, Phillips, Addison <addison@lab126.com> wrote:
> Hi Doug,
> 
> (personal comments)
> 
> Support or the lack thereof for base direction or language specific formatting/processing isn't really a "hint" and I don't think it would be a good idea to reduce the implementation attention given to either by calling them that. Web Notifications goes out of its way not to define the appearance, display, or handling of the data structures it defines. In some cases, implementers might work around a native system's lack of bidi APIs in various ways (such as inserting Unicode bidirectional controls).. In other cases this might not be effective or possible.
> 
> Still, if I send a notification with a dir="rtl", I pretty much do *depend* on the receiving system processing that in order for my notification to display correctly in all cases. Lack of support is, of course, a natural consequence of legacy systems. But it would be better to put the pressure on system vendors to do the right things than require people to type in their messages in odd ways or embed further bidi controls in content because the direction is "only a hint".
> 
> Setting the natural language of text, by contrast, is, in fact, a hint (although a useful one for systems that care), rather than a specific processing instruction. There are many *potential* effects from setting the language, but none would be appear to me to be appropriate for you to define in WN.
> 
> One other note, which Norbert raised in our conference call today but didn't make it into our earlier comments, was that it should also be possible to have within a notification multiple title or body items with separate language tags, since the sending system cannot always know the receiving systems' preferred language. Offering a choice in the notification would enable a "poor man's" language negotiation to occur. This is, obviously, not the primary use case, but not an impossible one.
> 
> Regards,
> 
> Addison
> 
> > -----Original Message-----
> > From: Doug Turner [mailto:dougt@mozilla.com]
> > Sent: Wednesday, June 27, 2012 5:37 PM
> > To: Phillips, Addison
> > Cc: www-international@w3.org; public-web-notification@w3.org; Olli.Pettay
> > Subject: Re: Web Notifications I18N Review: [I18N-ISSUE-161, I18N-ISSUE-162]
> >
> > This brings up a good point that I wanted to share with the group.  A few
> > months ago, I audited the many native notification system.  Most of these
> > systems do not have any concept of RTL/LTR.  Lets make sure we express this
> > fact in the spec by calling out that NotificationDirection is only a hint.  I would
> > hate to have web developers depend on this working on systems that clearly
> > can't support it.
> >
> > As for language of their user-visible text - The same is going to be true.
> >
> > Regards,
> > Doug Turner
> >
> > ----- Original Message -----
> > From: "Addison Phillips" <addison@lab126.com>
> > To: public-web-notification@w3.org
> > Cc: www-international@w3.org
> > Sent: Thursday, June 28, 2012 2:16:54 AM
> > Subject: Web Notifications I18N Review: [I18N-ISSUE-161, I18N-ISSUE-162]
> >
> > Hello, Web Notifications,
> >
> > The Internationalization Core WG has actioned me [1] with relaying our review
> > comments of your document:
> >
> >    http://dvcs.w3.org/hg/notifications/raw-file/tip/Overview.html
> >
> > Dated: 2012-06-27
> >
> > We are tracking these items as I18N-ISSUE-161 and I18N-ISSUE-162 in Tracker
> > [2].
> >
> > Our comments are:
> >
> > 161: Notifications have no way to identify the language of their user-visible text
> > (title and body). Knowledge about the language is often necessary for the user
> > agent to select the right font or to pronounce the text correctly - see
> > http://www.w3.org/International/questions/qa-lang-why
> >
> > [there are similar comments from other WG members]
> >
> > 162: (Section 5) It's a little odd that title is converted to Unicode before setting
> > the direction, while body has its direction set first. Can those be made
> > consistent? [This is an editorial comment and minor]
> >
> > [1] http://www.w3.org/2012/06/27-i18n-minutes.html I18N-ACTION-134 [2]
> > http://www.w3.org/International/track/issues/161
> > http://www.w3.org/International/track/issues/162
> >
> > Thanks and best regards (for I18N)
> >
> > Addison
> >
> > 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:03:09 UTC