Re: CSS Localization

On Fri, Jan 16, 2015 at 7:28 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Fri, Jan 16, 2015 at 8:42 AM, Cameron Jones <cmhjones@gmail.com> wrote:
>> On Tue, Jan 13, 2015 at 9:08 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> On Mon, Jan 12, 2015 at 7:53 AM, Cameron Jones <cmhjones@gmail.com> wrote:
>>>> On Fri, Jan 9, 2015 at 9:39 PM, Tab Atkins Jr. <jackalmage@gmail.com> 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:
>>>>
>>>> http://www.voyages-sncf.com
>>>>
>>>> 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
>>> confusing.
>>
>> This does not interfere with the previous case of the configured
>> browser locale as the site would use the HTTP "Accept-Language"
>> request header to determine the initial locale of the page.
>>
>> After this, the user would have to choose a manual override from the
>> normal HTTP language negotiation process by clicking on the
>> appropriate national flag. As such, there are no implications for any
>> other users as the default would remain the same.
>>
>> For multiple users of the same terminal in an internet cafe, they may
>> have to reset the language back to their choice if the internet cafe
>> has not configured their systems to clear sessions between users.
>
> You appear to be implying that sites would only use this feature in
> conjunction with checking the Accept-Language header of the response?
>
> This is extremely unlikely, to put it mildly.  And if it's something
> that sites *should* do, browsers can do it too, and do it better and
> more reliably.  No need to give any control to the page in this case,
> and risk them getting it wrong.
>
> For anything that's not browser-provided, if a page really wants to
> localize, they can do so as you suggest (by checking Accept-Language)
> and localizing with the facilities provided by their server-side
> language.  All major languages provide CLDR functionality, I believe,
> for formatting numbers, currencies, dates, etc.
>
>>> 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.
>>
>> Localization is a complicated area and i would expect that specific
>> advice should be given alongside specification text to ensure that
>> such functionality is properly understood for what purpose it is
>> defined and how it should be used.
>>
>> I agree that the "common wisdom" fallacy would be undesirable, however
>> it is not inevitable.
>>
>> The proposal allows sites to override default localization under
>> explicit instruction from users as an out-of-band negotiation process.
>
> Reiterating my earlier point, if the *users* are giving some explicit
> instruction, it's much more effective for them to give it to the
> browser itself, so the browser can apply their wishes to *all* pages,
> not just those who went to the trouble of setting everything up
> correctly.  If the user's wishes can be accommodated in an automatic
> way, the browser can do it better than the page; if the wishes can't
> be accommodated automatically, then providing browser-level
> functionality for it doesn't seem helpful.
>

So every multilingual site which is currently using the 'national
flag' UI pattern should instead try to inform uses how to change their
locale in each of the browser preference panels?

Given that they could already have taken that approach but instead
have found it far more user friendly to just provide the UI controls
themselves, it seems that this will not fly.

The impact of not providing locale control is that sites will just not
use the new form controls because they don't have the adequate ability
to control their function.

The ability to apply a BCP-47 code to a form control through CSS is
not limited to changing the base language. The additional BCP-47
extensions provide the ability to specify such additional localization
variations such as timezone, calendar, currency, etc. By providing a
general 'locale' property in CSS this provides the ability for these
additional variations to be used to configure localization. For
example, this would set a date input to use the British English with
the Chinese calendar in the US LAX timezone:

input[type="date"] {
  locale: "en-gb-x-ca-chinese-tz-uslax";
}

It is the features and conciseness of the BCP-47 codes which make them
so appealing as a solution to localization.

>>>>> [...] 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.
>>
>> I'd argue that there is little difference between the localization of
>> inputs from data. Both involve the same requirements regarding
>> targeting and configuration of formatting through CSS properties.
>
> No, there's significant difference.  Inputs contain well-known data
> types, and don't require any parsing or similar, just formatting.
> Arbitrary data requires parsing and datatype tagging.


You still need parsing when dealing with inputs - the user can do free
text entry which needs to be parsed against the format.


>
>> The proposal didn't provide the details on the specifics for
>> formatting, it was an initial appraisal of the base requirements for a
>> prospective solution. I would expect this to be actualized as a matter
>> of producing a specification of the functionality.
>>
>> The main aspect of formatting would be to resolve some skeleton to
>> either parse or format the raw data. This skeleton could be provided
>> by the host OS using native library integration, or resolving a BCP-47
>> code and looking up the CLDR, or from a manual skeleton as defined
>> through CSS (with syntax imported from the CLDR), ie:
>>
>> input[type="date"] {
>>   date-format: DEFAULT | SHORT | MEDIUM | LONG | "EEEE, MMMM d, y";
>> }
>>
>> input[type="number"] {
>>   number-format: DEFAULT | SHORT | DECIMAL | PERCENT | SCIENTIFIC |
>> CURRENCY | "#,###.00";
>> }
>>
>> The patterns for the CLDR are available here:
>>
>> http://cldr.unicode.org/translation/date-time-patterns
>>
>> http://cldr.unicode.org/translation/number-patterns
>
> Again, I'm still unclear why any of this is necessary; I haven't
> gotten a good example showing how a user would be helped by this, and
> how.
>
> ~TJ

The above was just a thrash at how formatting might be configurable
through CSS based on the CLDR.

Surely you must agree that formatting is stylistic and will be specified in CSS?

Thanks,
Cameron

Received on Saturday, 17 January 2015 14:05:05 UTC