W3C home > Mailing lists > Public > www-international@w3.org > July to September 2013

Re: Proposal: Locale Preferences API

From: Andrew Cunningham <lang.support@gmail.com>
Date: Sat, 27 Jul 2013 09:35:11 +1000
Message-ID: <CAGJ7U-Vk=VwgyScaES9dv1tzXMs-vCnc2JU4dK11ckfUFL5CCg@mail.gmail.com>
To: Marcos Caceres <w3c@marcosc.com>
Cc: www-international@w3.org, acunningham@slv.vic.gov.au

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" <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.
Received on Friday, 26 July 2013 23:35:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 September 2016 22:37:35 UTC