Re: Proposal: Locale Preferences API

Talking about writing systems becomes more problematic..

Since you are talking about 2 to 4 BCP language tags at least

Language
Country
Script
Variant

Some languages use more that on script which would need to be identified,
if the language entry in IANA registry doesn't have a suppress-script
(which interestingly is how windows8 has started to implement languages -
don't you love undocumented features)

Even with same language and script there can be variant orthographies

If you want an extensible system that could handle any language, http
header accept language as it is currently implemented and used is the wrong
place to start.

Andrew
On 27/07/2013 9:16 AM, "Marcos Caceres" <w3c@marcosc.com> 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:
> > 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.
>
>
>
>