Re: CSS Localization

On Tue, Jan 13, 2015 at 8:05 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
> * Tab Atkins Jr. wrote:
>>People using their own computer likely have it set up with the correct
>>locale (definitely not always true, but I think true enough that we
>>can consider most people in this category).  So they don't need any
>>help from us; localized inputs will already be displaying "correctly"
>>for them.
>>
>>This applies whether I'm visiting pages in my locale or not.  As an
>>en-US speaker, I expect to see dates in the US format, and would find
>>a German-locale date input confusing to work with, even on a German
>>site.  (I've had occasion to buy train tickets on a French-only site,
>>for example, which is confusing enough without dates looking wrong to
>>me.)  So when I'm working on my own computers, letting the page set
>>the locale of its inputs is actually harmful to me.
>>
>>The only case where help is needed is if someone doesn't control the
>>locale of the computer they're using, [...]
>
> That is not a valid conclusion. A typical setup around here is a german
> operating system with an en-us web browser which in my case is set to
> prefer generic "en" in the Accept-Language header in the hope to avoid
> machine translations into german. I do not know what the browser might
> think my preferred locale is for automatic localisation when visiting
> en-gb or alternatively en-us sites, and I am sure it would be extremely
> confusing if any automatic localisation is not immediately obvious and
> understandable. "Mittwoch, 14. Januar 2015, 04:55 Uhr Berliner Zeit"
> might be fine (if I unreasonably assume a site has no bugs with respect
> to timezones and such), but for dates like "2015-12-01" or numbers like
> "123,456" without additional context, I would have no idea what they
> mean. Is it January or December, hundreds, or hundreds of thousands? Is
> the page even using automatic localisation features, or am I looking at
> things verbatim as the author entered them (and same if I were to enter
> such inputs).

You appear to be saying that putting localization in page control is a
bad thing?  I've brought up the confusion aspect already in having
inputs localized to the country the page was developed in, rather than
the country the user is in.

>>I think the set of people that can be helped by this is smaller than
>>the set of people who can be harmed, and the risk of sites applying
>>this commonly is too great.  It's very easy to imagine it becoming
>>"common wisdom" to set the page's CSS locale to the same as the HTML
>>lang, which harms most people's ability to use foreign sites.
>
> If not doing that is so obviously the right thing as you suggest, that
> seems an unlikely outcome.

You know as well as I do that there's a huge difference between
"obviously the right thing" and "after discussion and thought, clearly
the right thing".

>>Displaying data is different from setting the locale of inputs.  This
>>proposal doesn't even attempt to do formatting of arbitrary data on
>>the page.
>
> The message that started this thread was clearly considering input and
> output. What is clearly lacking though is clear differentation between
> modes of input and output. Clearly a site does not need to control the
> localisation of a browser-controlled date picker that reliably and un-
> ambiguously conveys to the user how the site will interpret the input,
> for instance.

You're right that it's somewhat unclear, but it does appear that
Cameron is suggesting precisely that - that a page be allowed to
control the localization of a browser-controlled input.

~TJ

Received on Friday, 16 January 2015 19:20:54 UTC