Re: CSS Localization

On Fri, Jan 9, 2015 at 9:39 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Thu, Jan 8, 2015 at 7:03 AM, Cameron Jones <cmhjones@gmail.com> wrote:
> > Hello www-style,
> >
> > I'm following up on discussions across html and i18n wgs regarding
> > localization of form controls and other locale-specific data:
> >
> > https://www.w3.org/Bugs/Public/show_bug.cgi?id=17859
> >
> > I'd invite you to read through the discussion but i'll also summarize
> what
> > was derived and try to provide some suggestions for what could be a
> > localization module for CSS.
> >
> > ---------------
> >
> > There is new functionality added within HTML5 which is inherently
> > international and requires localization for display to the user. These
> > include the new form controls (eg: date, number, etc) and other data
> > elements, ie <time> and potentially <data> too.
> >
> > HTML includes a global "lang" attribute for defining the locale of an
> > element using BCP-47 codes, and a method for deriving the applicable
> locale
> > based on an element's parent, meta extension, http header or platform
> > locale.
> >
> > 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 is believed that the place to define the functionality for configuring
> > the render locale and any further localization customizations (ie format
> > skeletons) should be provided through CSS as a matter of separation of
> style
> > from content.
> >
> > As such, it is believed that no further changes to HTML are necessary and
> > that in order to support the functionality added to HTML5 there is the
> need
> > for additional functionality within CSS.
>
> What's the use-case for overriding the user's platform locale



The use case for overriding the user's platform locale can be seen in any
existing site which currently offers content in multiple languages. This is
very common in continental Europe where sites need to serve a multitude of
language speakers, for example:

http://www.voyages-sncf.com

These sites offer language selection as a part of their website controls
where
the locale can be chosen out-of-band with respect to platform locale or
HTTP headers. This is mostly offered for pragmatic reasons where users are
unable to change their locale settings either from lack of knowledge or
technical restrictions like using a terminal in internet cafes, etc.

The common way this is implemented is using a combination of URL redirects
for
serving content and HTTP cookies for storing user configuration.

If there is no way to override the locale used for render then these sites
are
unable to use the new form controls or other data elements as they will
always render according to the locale as set within the browser or
operating system.

Within European locales there are very different cultural conventions for
the
display of date/time and number formats. As such if a user selects their
own
language for content but the forms inputs continue to use the platform
locale
this would be very confusing and i doubt any of these sites would make use
of
them over their current in-house solutions which use text fields.

>
> [...] or having inputs with different locales on the same page?
>
>
The use case for having inputs/data in different locales on the same page
can
probably be better illustrated by also considering multi-regional sites. In
this
case we consider sites which use the same base language but want to display
information according to multiple regional conventions - so for example
displaying dates in both US time format and UK time format on the same
page.
Configuration pages, educational documents, examination pages and
documentation
purposes are some candidates as use cases.

Thanks,
Cameron




> ~TJ
>