[Bug 17859] Mechanism to enable localisation of form controls and other locale-specific data

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17859

--- Comment #37 from Cameron Jones <cmhjones@gmail.com> ---
(In reply to Ian 'Hixie' Hickson from comment #36)
> > I was considering the possibility that :locale() might be needed to allow
> > CSS rules to target specific localizations. It would match against either
> > the platform locale or page locale depending on which was enabled (pending
> > such a feature in CSS).
> 
> Ah, I see. That's one option. I was thinking more that the page locale would
> be set by the page (e.g. using lang=""), the platform locale would be set by
> the user (in system settings), and the CSS side would just let you specify
> which of those two locales to use when customising something, plus the
> ability to specify dedicated formats. As in:
> 
>    span.currency { content: format(page-locale, contents, 'USD') }
> 
> ...to take the element's contents, format it according to the page's locale,
> and put that in the rendering (assuming USD as the currency).

Ok, i agree with the logic but for implementation i was thinking more in terms
of defining CSS properties than functions. This would be more granular and
allow overriding through selectors.

The two main requirements are the need to set the applicable locale and to
configure the format.

A 'locale' property could be an enumerated option, with two options as
"page-locale" and "user-locale" as you noted. That implies resolution to a base
BCP-47 value, which leads me to think it could also provide an override point
within CSS, ie:

* {
    locale: <page-locale | user-locale | BCP-47 | inherit | initial | unset> 
}

This would allow localization to be configured without specifying specific
formats. For example, to configure an <input type="date"/> to use "en-US" date
format:

input[type="date"] {
    locale: "en-US";
} 

Without the ability to set a locale (or variant) through CSS, we would only be
able configure format skeletons:

input[type="date"] {
    format: "mm/d/y";
}

> 
> Similarly:
> 
>    span.currency { content: format(user-locale, contents,
> attr(data-currency)) }
>    span.currency { content: format('%03.2f %currency', attr(data-price),
> attr(data-currency))) }
> 
> We also need a way to configure the input control bindings somehow to enable
> or disable localisation. I don't know exactly how this should work. I'll let
> the Web Components guy figure that out.
> 

If the locale is controlled by property, this could just be another enumerated
value; 'no-locale' or even just 'off'. This would allow the raw
machine-readable data to be directly rendered as text.


> 
> >   span.currency:locale(en-AU)::after {
> >    content: "USD";
> >   }
> 
> Being able to select based on the user's locale is an interesting idea, but
> somewhat orthogonal to this issue, I think.
> 

Yes, it's just a potential corner case. 

> 
> > Dates in the form "YYYY-MM-DD" is an international syntax and does not exist
> > as a cultural format in any locale.
> 
> Yet my system platform's locale is set to use that as a date format. And I
> want Web pages to honour that.
> 

This is only relevant for client-side localization as there is no way to encode
this kind of configuration in a universal format, especially as a condensed
identifier like BCP-47 and the locale extentions.

It definitely highlights the usefulness of the 'user-locale' setting as the
interation with the Operating System is ideal. 

The syntax of a CSS 'format' configuration should probably allow for these
existing conventions so that the integration can be seemless. In addition to
custom format skeletons, it is also common for dates to provide format
enumerations: SHORT, MEDIUM, LONG.

This implies there could be both a method for configuring which format an
element should use for presentation, and a method for configuring the specific
format skeletons.

> 
> > Consider potential use cases for:
> > 
> > [snip]
> 
> I don't really understand the use cases here. When would you want someone to
> enter a roman numeral, only for it to be converted to a decimal value,
> instead of just letting the author enter the value in whatever form they
> want that their browser accepts, for example?

The use case is that of being able to configure an <input> for localized data.
The specific example of roman numerals is not important - what i am drawing
from is the locale extensions of BCP-47 and the data available through the
CLDR. There are various numeral systems defined and the approach for supporting
them is identical. Shouldn't it be possible for users of alternate numeral
systems to use their own? 

An interesting point i have heard in relation to non-ascii input data is that
the input methods (ie, keyboards) don't exist for these code points to be
generated - however, with more people using mobile technology as a primary
device and the use of virtual keyboards as standard, there seems to be no
reason that people should not be capable of operating within a completely
localized environment.

The calendar and timezone BCP-47 extensions seem quite self explanatory of how
these can apply to the date/time inputs. Similar to <input type="number">,
these localization would only apply to the presentation of values so the wire
value would be completely independent of this. It is also natural to assume
that a user would want to see dates/times in their own calendar and timezone.

The currency use case is quite compelling. There has been previous discussion
about supporting a currency input but AFAIK the current recommendation is to
use number inputs. The great thing about BCP-47 and CLDR is that all the
currency codes and symbols are already defined, maintained and available. There
is also a natural default mechanism where, for example, a 'en-US' locale
identifier will use USD.

One aspect of currency which is different from the other data is that it is
generally not regarded to be localizable. If we compare it to date/times for
example, we can localize a date into a different timezone and calendar but it
will still refer to the same temporal instant. The case for currency is that
changing the unit changes the value, and is generally not what people want -
essentially you can not 'localize' a currency value, it can only be
'translated' between currencies at moments in time.

What this means for HTML localization is that if 'user-locale' is the default
applicable locale, we would need a different default for handling currency so
that it is rendered using the 'page-locale'. I think the best way this could be
achieved is through the default browser stylesheets which could hold all the
initial values for localization:

* {
    locale: "user-locale";
}

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Monday, 11 August 2014 16:31:13 UTC