Re: CSS Localization

On Sat, Jan 17, 2015 at 11:59 AM, Koji Ishii <kojiishi@gmail.com> wrote:
> 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?

Sure does.

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

Using the HTML lang attribute is not possible because it has existed
since time immemorial and can be found on virtually all pages as a
matter of copy-paste programming. Having new functionality based on
this attribute has been discounted. It still represents the locale of
the content and will continue to represent this, however the new
functionality around localization has a different scope and so jamming
it into @lang reduces configurability in addition to breaking existing
pages.

It is possible to add a new attribute to HTML, however it is
considered that localization is a stylistic function and orthogonal to
the representation of content. The same HTML page can be augmented
with any type of localization and still represent the same data.


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

I thought two-phase processing could allow for the possibility of both
applying and selecting locales? Not desirable, but if we assume these
properties would tend not to change dynamically then the impact would
be limited.

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

I meant that if the keyboard layout was to change according to what
site you visited that would be undesirable as a default.

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

The lang attribute is still specifying content language, however
perhaps the question is whether localization and its configuration is
the same as defining the content of the page?

Thanks,
Cameron

Received on Saturday, 17 January 2015 14:08:38 UTC