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

Hi Addison,

"Phillips, Addison" <addison@lab126.com>, 2015-07-10 20:26 +0000:
> 
> 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).

OK, given that at this point I think it’s unlikely we’re going to get UAs
interested in implementing that lower requirement, I’ve filed a issue
against the current in-development version of the Notifications spec
proposing that the requirement simply be to pass the value on as-is.

  https://github.com/whatwg/notifications/issues/46

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

Right, I’ve filed a separate issue suggesting that the spec define an
actual document-conformance requirement (aka authoring requirement) for
BCP-47 validity of the lang value.

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

I think that (just above) is essentially what we’ll end up with if the two
issues I filed are accepted. Of course feel free to add comments to those
issues if you have more to add there or if you disagree.

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

OK

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

OK, I’ll update that test case.

Thanks,

  —Mike

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

https://lists.w3.org/Archives/Public/public-i18n-core/2015JulSep/0001.html

-- 
Michael[tm] Smith https://people.w3.org/mike