Re: CSS Localization

On Sat, Jan 17, 2015 at 1:35 AM, Cameron Jones <cmhjones@gmail.com> wrote:
>
> As far as how many locales are needed, for formatting the CLDR defines
> the dataset for all locales as they are registered. There is a
> fallback mechanism whereby if no data is present for a variant the
> base is used, and if there is no data for a base then English and its
> dataset is used.
>
> As such, i think a compilation of locales is unnecessary as we can
> assume that localization datasets can be allowed to evolve to be more
> complete over time.

I mieslead you, sorry about that. When I said "how many lang/locale we
need", I did not mean a list of English, French, etc., but rather a
list of purposes, such as:

- used for spellcheck
- used for typographic correctness (such as justification, underline, etc.)
- used for font fallback
- used for localizing default button labels
- used for date/time formatting and parsing

These items were raised in the past, including yours, and we solved
one by one. I think it's better to try to create an exhaustive list
like this, then we'd have a list of switch sources:

- lang attribute
- a possible new CSS property
- system
- current keyboard (or list of keyboards user installed)

and clarify the mapping between the two.

Does this clarify better?

>> There's a question whether UA should localize default labels of buttons
>> (such as Submit/Cancel) according to the system locale, I18N WG is working
>> on that including how to prevent breaking the web, and that discussion
>> covers date formatting I believe.
>
> The problem with labels of buttons would seem to be that the default
> legacy behavior of always using English even for localized browsers is
> inconsistent with the expected functionality as it would be
> implemented today.
>
> To resolve this without breaking the web, i think the capability can
> be defined within CSS but with the existing behavior specified in
> browser stylesheets.

I agree that locale for forms is somewhat in between content and
presentation, so I haven't made up of my idea which is better yet.

But "let's use CSS, not HTML, just because changing HTML would break
the web" does not sound like a good way to decide which way we'd like
it to be. We could add a new HTML attribute if needed. r12a brought up
an idea to use the lang attribute only when it's explicitly set to
<form> element. There could be other way to solve the backward
compatibility.

Rather, I'd like to clarify for which purpose the lang/locale is used
for, then we should have better idea whether HTML or CSS works better
for the purpose and use cases. Such design should be more instinct to
authors too.

> So, if we assume a method for defining label and
> button localization exists this would result in the browser
> stylesheet:
>
> input[type="submit"] {
>   locale: en;
> }

I agree that selector is one of the benefits to make lang/locale a CSS
property. On the other hand, we need to be aware that we will loose
the capability to style based on lang/locale, because selectors based
on other CSS properties is generally not a good idea.

So, one practical discussion whether lang/locale should be in HTML or
in CSS is that, do you want to define lang/locale based on content, or
do you want to style based on lang/locale? There may be both cases,
but I think the latter is more important.

>> Editing TF is discussing whether keyboard
>> should be changed to the locale specified by the lang attribute[1].
>
> Here, I think that using the browser locale for input is desirable as
> the default, especially as the keyboard layout tends to be tied to the
> client device.
>
> Having a method to override this for their "English Office account on
> a German pc on vacation" case is synonymous with the internet cafe
> scenario and could be configurable by locale override.
>
> For sites wanting to restrict the character set of text entry, this
> would make more sense as a HTML attribute on input fields as it would
> represent a non-stylistic constraint.

Thanks for your inputs. I'm not sure the assumption of "keyboard is
tied to client device" is true in coming decades, but the point is
that I'd like to discuss lang/locale designs with all these scenarios
in mind.

>> CSS has some features such as justification or underline positions
>> affected automatically by the lang attribute.
>
> CSS using the HTML lang attribute for justification and underline
> positions seems problematic if we assume that the default should be to
> use the browser locale for localization.

What looks strange to me is that, CSS believes that lang attribute is
working and is a good way to specify the content language, while
another group in W3C believes that no additional behaviors should be
defined against lang attribute. This needs to be resolved by
cross-group efforts.

/koji

Received on Saturday, 17 January 2015 12:00:17 UTC