Re: CSS Localization

On Mon, Jan 12, 2015 at 7:53 AM, Cameron Jones <> wrote:
> On Fri, Jan 9, 2015 at 9:39 PM, Tab Atkins Jr. <> wrote:
>> What's the use-case for overriding the user's platform locale
> The use case for overriding the user's platform locale can be seen in any
> existing site which currently offers content in multiple languages. This is
> very common in continental Europe where sites need to serve a multitude of
> language speakers, for example:
> These sites offer language selection as a part of their website controls
> where
> the locale can be chosen out-of-band with respect to platform locale or
> HTTP headers. This is mostly offered for pragmatic reasons where users are
> unable to change their locale settings either from lack of knowledge or
> technical restrictions like using a terminal in internet cafes, etc.
> The common way this is implemented is using a combination of URL redirects
> for
> serving content and HTTP cookies for storing user configuration.
> If there is no way to override the locale used for render then these sites
> are
> unable to use the new form controls or other data elements as they will
> always render according to the locale as set within the browser or
> operating system.
> Within European locales there are very different cultural conventions for
> the
> display of date/time and number formats. As such if a user selects their own
> language for content but the forms inputs continue to use the platform
> locale
> this would be very confusing and i doubt any of these sites would make use
> of
> them over their current in-house solutions which use text fields.

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, such as the internet cafe case
you bring up.  This is in direct opposition to the previous case - a
page that declared its input locale to help cafe users (who are,
presumably, attempting to access a site from their home country while
using an internet cafe abroad) will hurt my experience by making
inputs less consistent when I visit the page.  It also assumes that
the cafe user actually *wants* to see the page in its native locale;
for users who are *from* the country that the computer has its locale
set to, seeing foreign sites in a different locale will also be

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.

>> [...] or having inputs with different locales on the same page?
> The use case for having inputs/data in different locales on the same page
> can
> probably be better illustrated by also considering multi-regional sites. In
> this
> case we consider sites which use the same base language but want to display
> information according to multiple regional conventions - so for example
> displaying dates in both US time format and UK time format on the same page.
> Configuration pages, educational documents, examination pages and
> documentation
> purposes are some candidates as use cases.

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.  You wouldn't use two inputs with differently-configured
locales just to display the time in two locales.  If there *were* two
inputs, for setting a time of something for a US and UK location, I
definitely would *not* want those to display with different
conventions; that is a horrible UX that just invites mistakes (like
not realizing that the "3/5/2015" displayed in both inputs is
referring to dates two months apart).

So, this part seems irrelevant.


Received on Tuesday, 13 January 2015 21:09:40 UTC