Re: Proposal: Locale Preferences API


I will give it some though, what you intend to do is useful, but the
question is how best to achieve it.

If you have time might  be worth a conversation.

On 27/07/2013 9:16 AM, "Marcos Caceres" <> wrote:

> 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:
> >
> > 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:35:42 UTC