- From: Andrew Cunningham <lang.support@gmail.com>
- Date: Sat, 27 Jul 2013 09:35:11 +1000
- To: Marcos Caceres <w3c@marcosc.com>
- Cc: www-international@w3.org, acunningham@slv.vic.gov.au
- Message-ID: <CAGJ7U-Vk=VwgyScaES9dv1tzXMs-vCnc2JU4dK11ckfUFL5CCg@mail.gmail.com>
Marcos, 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. 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. > > > >
Received on Friday, 26 July 2013 23:35:42 UTC