- From: Cameron Jones <cmhjones@gmail.com>
- Date: Wed, 11 Feb 2015 14:00:07 +0000
- To: Shawn Steele <Shawn.Steele@microsoft.com>
- Cc: "Phillips, Addison" <addison@lab126.com>, "www-international@w3.org" <www-international@w3.org>
On Tue, Feb 10, 2015 at 5:52 PM, Shawn Steele <Shawn.Steele@microsoft.com> wrote: >> Part of a locale includes a region designation which is a geographic component, so i would say that it's harder to remove location from locale and purely define a locale as a language and void of geography. > > BCP-47 language tags fail some cases because you can't represent "Canadian English speaker in the United States". It's being overloaded to represent things that aren't always a good fit. I'd much prefer discrete language, region, Timezone, currency, etc fields. > > -Shawn > > You can represent that as "en-CA-u-tz-PT" if you are in the Pacific Time Zone, for example. The location is irrelevant as the locale is not meant to be a location designator, only a time zone designator which may include a location for specificity. The problem with discrete fields is that these can not be communicated across HTTP and included as part of the Content-Language negotiation. How are you supposed to know how to specify the time zone for a user if you don't use the information in BCP-47? With ip4 this could be done resolving a geolocation however with ipv6 this is becoming far more difficult and error prone. Another problem with IP location is that this does not represent user preference, only network properties, which isn't representative for people who are traveling or otherwise want to register a preference outside of their network location. I don't think BCP-47 is being overloaded, what is the purpose of the encoding if not to represent how information should be presented? The encoding has all the flexibility of discrete fields, but combined within a single encoding so it can be passed around and used as an identifier. Thanks, Cameron
Received on Wednesday, 11 February 2015 14:00:35 UTC