Re: CSS Localization

On Tue, Jan 20, 2015 at 11:49 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Sat, Jan 17, 2015 at 6:04 AM, Cameron Jones <cmhjones@gmail.com> wrote:
>> On Fri, Jan 16, 2015 at 7:28 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> 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?
>
> They shouldn't try to do anything at all.  The browser-provided inputs
> are formatted according to the computer's locale already, which is
> *probably* correct; and if it's not, it's not the responsibility of
> individual websites to correct for that.  (If it's incorrect, the user
> is at least probably *used* to the incorrect display, and has learned
> how to work with it.)
>

The national flag pattern is precisely for when the browser's locale
is incorrect with respect to what the user wants and they are
incapable either by technical restriction, inadequacy or persistent
inconvenience to change the configuration.

> For all the content provided by the page, rather than the browser,
> they already have the localization tools necessary to deliver things
> in the format they want - the national flag UI pattern.  If you can
> localize the text yourself, you can localize everything that's not
> browser-provided yourself.
>

But sites won't be able to localize the form inputs to use the same
locale the user chose through the national flag UI pattern.

If they do use the new form inputs they will have a mix of locales in
effect on the same page.

This is the worst case scenario for localizing a page and represents a
step backwards for existing sites. These sites won't transition to
using the new form inputs if they can not replicate their current
functionality in the new controls.

>> 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.
>
> You still haven't explained why someone would want to do any of this.
> Very specifically:  what user, in what situation, would be helped by a
> page setting this?  And, importantly, would they be hurt by pages
> doing this for languages other than their own?
>

A Chinese person working in LAX airport using shared access terminals
running a webapp which provides a locale setting may want to configure
their login to use their chosen localization without having to change
browser settings on every login and inadvertently affecting other
users of that terminal.

The argument about people being hurt by providing access to this
functionality is advocating for a sterile environment where browsers
must protect against nefarious or incompetent site developers. It's
always possible for programmers to write abusive routines - anyone can
include the following JS on any page today:

while(true) {
  // burn!!
}

With power comes responsibility - but the net impact of misusing or
abusing a page's locale would be the incomprehension of that
individual page, so the damage is limited to their own purposes.


>>> 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.
>
> That's against a single spec-defined grammar, though.  Dates, for
> example, have to be in the form YYYY-MM-DD if you set the input
> directly.  That's only barely "parsing". ^_^

Hmm...i was more thinking that the format skeleton would provide the
ability to enter values within that format.

Wouldn't it be more confusing for users if the format changes when
they focus the input field?

It should probably always be possible for ISO-8061 text entry, but for
this to be the only format seems very technical and not so user
friendly.

>
>> Surely you must agree that formatting is stylistic and will be specified in CSS?
>
> I don't agree.  Formatting is meaningful (for example, some calendars
> can't display some dates), and I haven't seen any reason for the
> browser-supplied things to make this configurable so far.
>
> ~TJ

There are almost limitless ways of formatting dates, especially if we
consider dates formatted with author supplied text strings.

You seem to be advocating for a single date format for all purposes -
there are many situations where anything from very short to very long
formats are in widespread use and not just for visual layout.

Whether a date contains the day of week, a numerical month or a verbal
month, a 4 digit year or a 2 digit year - these are all common
variations and not possible for a "one-size-fits-all".

Thanks,
Cameron

Received on Wednesday, 28 January 2015 14:00:46 UTC