- From: John Tamplin <jat@google.com>
- Date: Thu, 14 Apr 2011 09:53:34 -0400
On Thu, Apr 14, 2011 at 7:23 AM, Jukka K. Korpela <jkorpela at cs.tut.fi>wrote: > > I think the main problem is triggering the decimal separator mode (or >> the order of numeric day and month for that matter) on the UI locale >> rather than the locale of the page, >> > > Well that's certainly at least _one_ of the problems. And we might ask > whether a browser should use the _system_ settings, as they should probably > be expected to best reflect the user's real preferences. The entire web application, which includes both client and server-side code, must have the same idea about what locale the user is using. If the app provides a drop-down box or preference setting to choose a different locale, as most localized apps do, the web browser has to be using the same locale for any native locale processing it uses. Otherwise, you run a serious risk of having incorrect data -- if a user types "10,000" in a field when they think they are using a locale with a comma as the decimal separator, does the app receive that as 10000 or 10.000? If the app is running in en-US because the user requested it or their system locale isn't supported by the app, and the browser sends "10.000" as the value because the system locale is "de", then that is a problem. > Thus, it would be safer to compute the language of the input element, >> > > In practical terms, no. We know that authors generally fail to specify the > content language or have it mis-specified (typically, as English > irrespective of the real language) by authoring software. If you can't rely on getting the locale the app is running in, then apps are not going to be able to use any fancy features and will continue to implement their own localization since they can't rely on the browser getting it right. -- John A. Tamplin Software Engineer (GWT), Google
Received on Thursday, 14 April 2011 06:53:34 UTC