Re: CSS Localization

On Tue, Jan 13, 2015 at 11:04 AM, Koji Ishii <kojiishi@gmail.com> wrote:
> I'd be more comfortable to sort out what's needed to be localized more
> throughly, discuss how many lang/locale we need, and define attributes or
> CSS properties as appropriate.

Sure. I've been more interested in localization in terms of formatting
data and its requirements rather than UA text of labels and buttons
but they do intersect around BCP-47.

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.

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

This would enable sites to manually 'switch on' label localization
according to a fixed or derived locale, eg:

input[type="submit"] {
  locale: page-locale;
}

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


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

Again, here this might be resolved through default settings in browser
stylesheets so that the functionality is provided for override but the
legacy behavior is preserved for compatibility.

>
> I guess I18N WG is the best place to discuss across WGs and make
> recommendations. I'm not in sync with the discussion these days, but please
> help their discussion if you can.
>
> [1] https://github.com/w3c/editing-explainer/issues/31
>
> /koji


I've checked recent discussions on i18n which surfaced the following
thread titled "Locale-based forms in HTML pages":

http://lists.w3.org/Archives/Public/www-international/2014OctDec/0025.html

This also links through to a wiki with the current state of thinking:

https://www.w3.org/International/wiki/Locale-based_forms

I'll follow up these points with the respective groups and see if the
discussions move forward.

Thanks,
Cameron


>
> On Tue, Jan 13, 2015 at 12:55 AM, Cameron Jones <cmhjones@gmail.com> wrote:
>>
>> On Sat, Jan 10, 2015 at 5:09 PM, Bjoern Hoehrmann <derhoermi@gmx.net>
>> wrote:
>>>
>>> * Cameron Jones wrote:
>>> >The implementation of localization within browsers uses the platform
>>> > locale
>>> >for any localization of pages. This leaves no potential for configuring
>>> >localization either to enable a locale override or to enable
>>> > multilingual
>>> >documents to exist.
>>>
>>> It would be terribly confusing if some parts of an en-us page would use
>>> en-gb or even de-de formatting without extremely clear indication, so
>>> this sounds rather unlikely to me. As a user I would not even know what
>>> any given browser installation considers my "platform locale" to be. If
>>> I visit a en-us page in a en-us browser set to prefer en-gb content on a
>>> de-de Windows system, it'd be rather unpredictable how to inrerpret any
>>> possibly localised content.
>>
>>
>>
>> I think this is why the status quo has been to use the platform locale by
>> default. This provides the most consistent user experience across all
>> pages for
>> default OS and browser installations.
>>
>> In your example, because you had set the browser locale to en-gb all
>> localization would use that setting. That seems rational to me.
>>
>> I'm not expecting the status quo to change and for web sites to all start
>> overriding the platform locale to create confusing experiences - but in
>> the
>> case where a user wants to view a specific page in different locale i
>> think that
>> sites should be able to use the same HTML content consisting of form
>> inputs and <time>, etc.
>>
>> The scope for a confusing user experience would be limited to explicit
>> code on
>> individual sites - so they would have created the problem themselves.
>>
>>
>> Thanks,
>> Cameron
>>
>>
>>>
>>> --
>>> Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
>>> D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
>>>  Available for hire in Berlin (early 2015)  · http://www.websitedev.de/
>>
>>
>

Received on Friday, 16 January 2015 16:35:47 UTC