Re: Proposal: Locale Preferences API

On Friday, 26 July 2013 at 22:51, Andrew Cunningham wrote:

> I think the first question is do you mean a localisation or do you mean a locale?

As Albert said, I think I'm referring to "writing systems" (or whatever term is used to express what is generally sent by browser via HTTP).  

Remember that the simple case we are trying to solve is:  

1. web application is localized in a set of language-regions (e.g., en-US, en-AU, etc.).  
2. user has some language preferences, in order (e.g., en-AU).
3. Given 1 and 2, is there overlap to make a "best match"?   

That's all (for now) - we think/hope that will cover the majority of use cases for the average developer (assume I'm the average developer, as you can see I've already screwed up the terminology around all this and I've been looking at this i18n stuff for a while … it's complicated).
> I think there is a need to express a locale but I don't think from the description of your text you actually mean a locale.

Yes, sorry about that. I'm using it in the loses sense in what is commonly used in browsers (i.e., simple language tags, rarely beyond two or three sub-tags, and likely with no extensions… "en-US, jp, es" and friends).   
> BCP47 can be used to identify locals, but CLDR introduced an extension to BCP47 to be able appropriate identification of a locale:
> http://cldr.unicode.org/index/bcp47-extension
> The HTTP header is about languages, not locales, there isn't enough data to clearly identify a locale.

Agreed. Should I just change everything to just talk about languages and "writing systems" and not mention locales at all?   
> In theory change in locale doesn't just affect language, it should change date, time, number representations, it sorry change how data is sorted, it should change any ordered lists ... it should kick in a whole set of changes on content, not just language.

Yeah, in this API we are just interested in changes in language-region I guess. The other locale information would be handled by ECMA-402.

Received on Friday, 26 July 2013 23:15:06 UTC