RE: Notification.lang and Notification.dir support in Web Notifications implementations [I18N-ACTION-452]

Hello Mike,

Thanks for this note. This reply is on behalf of the I18N WG in response to my action item [1].

1. Regarding your first point, I'm not surprised that invalid language tags are just "passed through". In addition, the term 'valid', as defined in BCP47, is not generally the right level to specify normatively. It adds the burden on implementations of checking if the subtags are in the registry (and this may mean, in most cases, that there is a "valid-as-of" date associated with the implementation). So my first suggestion would be to replace term 'valid' with the BCP47 term 'well-formed'. The lower requirement of well-formed can be checked with a regular expression (albeit a somewhat complicated one). 

An even lower level of syntactical requirement is the 'obs-language-tag' construct, which has a very simple regex. Many specifications prefer to mandate this level of "content checking", even though "valid language tag" is always recommended to authors.

Ultimately, I don't think an implementation note is the right choice. If we think that implementations should be GIGO, we should make that normative. If we think that it's merely that implementations need to catch up, then we should keep normative language and make tests that show implementations failing ;-).

So, for the latter I'd suggest using the following language to replace the current text you quoted in the email below:

--
If options's lang is a well-formed BCP 47 language tag, set notification's language to options's lang, otherwise the UA should set the actual "lang" property to the empty string.
--

If you prefer the former solution, perhaps:

--
If options's lang contains a value, or the empty string, set notification's language to options's lang. The language tag should always be a valid BCP 47 language tag. Other values will be passed by the UA without checking.
--

2. Regarding direction, I agree that's about as much as you can do, although I would add to the note you quote some mention of the dir value. I'm (shall we say) "abundantly aware" of the limitations of platform notification APIs. For example, managing bidirectional text in Android Notifications still seems to sometimes require wrapping text in Unicode bidi controls such as via [2]. An implementation might do that, but nothing is free or easy in the platform itself.

Note that the text in your test wouldn't necessarily appear right-aligned. A better test would include some actual right-to-left text so that the word order can be compared (even if the host environment displays the text in a left-to-right layout). See the examples here [3], perhaps.

Addison

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

Internationalization is not a feature.
It is an architecture.

[1] http://www.w3.org/International/track/actions/452

[2] https://developer.android.com/reference/android/support/v4/text/BidiFormatter.html 
[3] http://www.w3.org/International/articles/inline-bidi-markup/uba-basics#directionalruns 

> -----Original Message-----
> From: Michael[tm] Smith [mailto:mike@w3.org]
> Sent: Tuesday, July 07, 2015 4:53 AM
> To: public-i18n-core@w3.org
> Cc: Richard Ishida; Jon Lee; Edward O’Connor
> Subject: Notification.lang and Notification.dir support in Web Notifications
> implementations
> 
> The Web Notifications WG is poised to take the Web Notifications spec at
> http://www.w3.org/TR/notifications to Rec soon, and there are two i18n-
> related points with regard to current implementations that it’s appropriate to
> give the I18N Core WG a heads-up on at this time.
> 
> Here are details about the two points
> 
> 1. Step 4 at http://www.w3.org/TR/notifications/#dom-notification states
> UA
>    requirement with regard to the value of the Notification.lang property,
>    whose purpose is to convey the language of a notification. That step
>    reads, “If options’s lang is a valid BCP 47 language tag, or the empty
>    string, set notification’s language to options’s lang, or set it to the
>    empty string otherwise.”
> 
>    Restated, if a Web application tries to set a “lang” value that is not a
>    valid BCP 47 language tag, then according to the spec, the UA should set
>    the actual “lang” property to the empty string.
> 
>    Try the following test in Firefox and Chrome and Safari (the only UAs
>    the currently implement the spec).
> 
>    http://w3c-test.org/notifications/notification-lang.html

> 
>    What you’ll find is that if you use a valid BCP 47 language tag, the UAs
>    behave as you would expect, and set the notification’s language value to
>    the BCP 47 language tag you indicated.
> 
>    However, if you use a string that is an *invalid* BCP 47 language tag,
>    no UA follows the spec requirement to set the notification’s language
>    value to the empty string.
> 
>    Instead it’s all just basically “garbage in, garbage out”: If you use
>    the string “Latn-de”, the UAs will set the notification’s lang value to
>    exactly that—without checking whether it’s a valid BCP 47 value.
> 
>    So this isn’t really a problem in the normal case, since if Web
>    developers have their Web applications use valid BCP 47 language tags to
>    begin with, everything will work as expected. (And if they set a value
>    that’s not a valid BCP 47 language tag, things aren’t going to work
>    as expected for end users—regardless of what UAs do with it.)
> 
>    So it would seem to be sufficient to address the state of the UA
>    implementations on this point just by adding a non-normative note to the
>    space saying that UAs currently don’t check whether the “lang” value is
>    a valid BCP 47 language tag, and don’t set the “lang” value to the empty
>    string if they’re given an invalid BCP 47 language tag to process.
> 
> 2. The “Direction” section http://www.w3.org/TR/notifications/#direction-0

>    of the spec has a somewhat soft requirement that the platform-level
>    widgets that actually display the text of notifications should display
>    that text in a right-to-left direction if a notification’s “dir”
>    property is set to indicate that.
> 
>    Try the following test in Firefox and Chrome and Safari (the only UAs
>    the currently implement the spec).
> 
>    http://w3c-test.org/notifications/notification-dir-rtl-manual.html

> 
>    What I believe you’ll find is that on no platforms where you test it
>    is the text rendered in a right-to-left direction. (Or depending on how
>    you have your environment set up, you may actually find otherwise, I
>    dunno. But at least in my testing, I couldn’t get the text of any
>    notification on any platform to display in a right-to-left direction.)
> 
>    All that said, it’s not clear to me that the UAs aren’t in conformance
>    with this spec on this, because the only language in the spec that comes
>    anywhere close to stating a hard requirement here is the statement,
>    “User agents are expected to honor the Unicode semantics of the text of
>    a notification’s title and body.”, which is of course not clearly using
>    RFC 2119 language for stating an actual requirement, and even if it did
>    state it using a “must” it would still not be clearly stating anything
>    exactly and specifically that UAs must do.
> 
>    Part of the reason for that is, the nature of the notifications defined
>    by this spec is that they are so-called “desktop notifications” which
>    aren’t displayed within a Web document or even within a browser window
>    but are instead displayed outside the browser, as platform-level
>    notifications, in the same way that notifications from other
>    applications running on the platform are displayed.
> 
>    So especially depending on the particular platform a UA is running on,
>    the UA may not have much control at all over the details of how the
>    notification is displayed. That makes this behavior somewhat of a UI
>    issue, and we normally try to have specs not define UI requirements, so
>    that limits what the spec can say (and try to enforce) in this case.
> 
>    So it would seem to be sufficient to address the state of the UA
>    implementations on this point just by adding a non-normative note to the
>    space telling Web developers that the current state of platforms which
>    display Web notifications is such that they can’t expect the text of
>    notifications to be displayed right-to-left on every platform.
> 
>      —Mike
> 
> --
> Michael[tm] Smith https://people.w3.org/mike

Received on Friday, 10 July 2015 20:26:51 UTC