[Bug 13408] UA should use element locale for i18n

https://www.w3.org/Bugs/Public/show_bug.cgi?id=13408

--- Comment #8 from Ian 'Hixie' Hickson <ian@hixie.ch> 2012-01-20 22:41:11 UTC ---
(In reply to comment #6)
> 
> Yes, there is HTML language defined in BCP-47 and the OS locale which may
> exhibit POSIX codes. The application of a locale in this context is one-way and
> only of use in its language so the additional information in a locale has no
> relevance.

I'm not sure what you're saying here.


> What's wrong with using "may" in a non-normative context?

"may" is defined to have normative meaning. Please read the spec's
introduction, conformance, and terminology sections for a detailed discussion
of such issues.


> the problem with the current note is that it *encourages* browsers to use user
> locale's language to localise any controls in preference to and as mandatory
> order-ride over the page\element language as defined by the author\server.

I don't see how it encourages it any more than using the page's locale. Exactly
which happens is really up to the user agent and the user. Personally, I would
much rather my browser localise everything to use my own preferred formats (the
ISO8601 ones) than ever use either my locale's or the page's locale, because my
locale's format (UK), and the formats of the pages I use (US), are both very
confusing (DD/MM/YY and MM/DD/YY respectively).


> take a simple example of a booking a US train ticket using a UK laptop. the
> date\time controls are rendered in UK locale but the page has been pre-rendered
> by the server to use US date formats, this results in a mix of MM/DD/YY and
> DD/MM/YY across the page. 

Indeed. Personally I'd want my browser to use my own preferred format for
exactly that reason.

But now consider the case of a Swiss French user browsing a Japanese site. Were
I in this situation, I would prefer that my locale be used (with French month
names) than that the Japanese locale be used (since I would have no chance of
understanding what I was doing in that locale).

Similarly, consider the case of a browser that supports the user's locale but
does not support the site's locale. How can it use the site's locale?


> i also note that at the end of normative section 3.2.3.3 it states:
> 
> "User agents may use the element's language to determine proper processing or
> rendering (e.g. in the selection of appropriate fonts or pronunciations, or for
> dictionary selection). "
> 
> Maybe this should also be updated to reference form controls?

Sure, I'll do that.


(In reply to comment #7)
> 
> In general, the new features like input type="date" have not been considered
> much from the localization point of view.

While you may disagree with the results, I assure you that localisation was
very much considered.


> As such, they tend to create
> confusion. When using, say, a page in English on a browser with German as the
> “user’s preferred locale” (an ambiguous concept), how could the user expect
> that 1.005 will be taken as one thousand and five, against the conventions used
> on the page?

I don't understand the question.


> I think the API should specify a way to query support to a specific locale.
> That is, if your page is in Swahili, you should be able to query whether input
> type="date" supports Swahili, so that you can do something about it (like using
> some alternate input) if there is no support.

Please file separate bugs for feature requests.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 20 January 2012 22:41:25 UTC