>
> I fully agree that an API to obtain the locale list that a browser would send
> to
> the server directly from the browser would be very useful. But since that API
> would be browser specific, I don't think it belongs into an ECMAScript
> specification. Something like window.navigator.acceptLanguage might be the
> right API...
Why would it be browser specific? Language priority lists are well-understood
and the other APIs (such as the matching API) are in terms of a LocaleList. It
would be permissible for an implementation to return a list with exactly one
item in it, of course.
I guess the question here is "what does 'default locale' mean in the ES
context?" My first reaction was similar to what you have in the spec: it's a
well-defined, specific locale. But thinking about it made it seem less clear to
me, especially once I started to think about the interplay between client-side
and server-side processing, noting again that implementations can return a
list-of-one-item. It is a good thing for Accept-Language and DefaultLocale to
be somewhat holistic. Of course a browser might *not* return the same thing as
Accept-Language as the default locale: it would not have to be required. In
Eric's case, for example, it might be the local system language priority list.
>
> Are you proposing addLikelySubtags/removeLikelySubtags as new API, or as
> part of canonicalization?
Putting it into canonicalization might be too strong. In our implementation,
the use of these methods is actually hidden inside the matcher (so that
"zh-Hans-CN" always finds "zh-CN"---or vice versa---depending on which is
available), but the tags that you put in are the tags that come out.
For example, if I do:
LookupMatcher m = new LookupMatcher("zh-CN,de,fr");
value = m.match("zh-Hans-CN"); // value is "zh-CN" because that's what's in
the list
Addison
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
