[Bug 13408] UA should use element locale for i18n

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

Jukka K. Korpela <jukka.k.korpela@kolumbus.fi> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jukka.k.korpela@kolumbus.fi

--- Comment #7 from Jukka K. Korpela <jukka.k.korpela@kolumbus.fi> 2012-01-12 21:09:46 UTC ---
(In reply to comment #3)
> I'll replace "the user's preferred locale" with "the user's preferred locale or
> the locale implied by the element's <span>language</span>."

I don’t see the change as implemented, so I guess it was just a proposal. In
any case, it would not solve the problem—rather, it would introduce additional
vagueness.

In general, the new features like input type="date" have not been considered
much from the localization point of view. 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?

It just gets worse if the browser can apply either the “user’s preferred
locale” or the element’s language (if indicated in markup or HTTP headers, I
presume).

The only solid basis is the language/locale of the page itself, as indicated in
markup. It will then be up to authors to indicate it if they use the new
features. If browsers allow users to override such features, using e.g. the
“user locale” on all pages, so be it, but this should not be said in a
specification; it would just confuse implementors (and authors).

The question then arises which locale definitions shall be used. I’m afraid any
realistic specification needs to allow a fallback to a “neutral” (i.e.,
US-centric) locale, when the page locale is not supported by the implementation
if input routines. Otherwise, I suggest that the CLDR definitions be applied.
They are not perfect, but the best we’ve got, and they have (in principle at
least) a mechanism for proposing changes and filing bugs.

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.

-- 
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 Thursday, 12 January 2012 21:13:56 UTC