Re: CSS Localization

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.)

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.

> 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?

>> 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". ^_^

> 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

Received on Tuesday, 20 January 2015 23:50:10 UTC