W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > December 2011

[Bug 13408] UA should use element locale for i18n

From: <bugzilla@jessica.w3.org>
Date: Tue, 13 Dec 2011 11:57:02 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RaQyk-0005xa-UL@jessica.w3.org>

--- Comment #6 from Cameron Jones <cmhjones@gmail.com> 2011-12-13 11:57:01 UTC ---
(In reply to comment #5)
> Language and locale aren't the same thing. A language can at best imply a
> locale. Hence my proposed wording.

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

> > "The language of an element is determined through language resolution algorithm
> > defined in section Browsers may provide configuration to override and
> > present elements according to the conventions of a user's preferred locale."
> If it's a note, it shouldn't contain the normative word "may". Also, we can't
> reference section numbers since they change all the time (and vary from edition
> to edition at any one time). 

I can see that section numbers can not be maintainable, it could be replaced
with a link. the important factor is the reference to the normative section.

What's wrong with using "may" in a non-normative context? if a note is
non-normative it shouldn't matter what prose is used? it makes no difference to
use the word "can" or some other word denoting an option.

> I don't see how this is an improvement over the current note (with or without
> my proposed modification). What is the problem you are trying to solve?

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.

this is an issue because if a user navigates to a page in a different language
the page will contain foreign text and formats yet the controls are still
rendered in the user's native locale. 

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. 

this creates confusion which exists through any cross-language browsing
experience and especially in form controls as additional importance as an area
that user input and clarity is required. 

the problem with the specification is that browsers should not be encouraged to
use their user's locale by default. the language of the page has already been
defined by the author and this should be used.

the statement that browsers "may" provide override configuration is more a
suggestion of progressive enhancement so that if browsers wish to retain
current behaviour believing that their users have come to expect the existing
behaviour, they could do so as default configuration. at the very least this
mandates the ability for users to disable automatic overriding of page\element
language, yet i hope that i've been able to illustrate that this is a bug.

> > this is fine but the notes should not be explicitly required as language
> > resolution is already defined. 
> I don't understand what you mean here.

i hope i've clarified the issue with the above. i have no predisposition to
what the exact change or text should be as long as the change addresses the
existing contradiction.

i also note that at the end of normative section 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?

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 Tuesday, 13 December 2011 11:57:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:02:10 UTC