[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 #35 from Cameron Jones <cmhjones@gmail.com> ---
(In reply to Ian 'Hixie' Hickson from comment #34)
> (In reply to Cameron Jones from comment #31)
> > > Not sure exactly what you mean by "auto-localisation" [...]
> > 
> > "...the feature that exists today that causes form controls
> > to render according to the user's local platform conventions rather than
> > the language negotiation of HTTP and the HTML language resolution algorithm"
> 
> Ah, ok. So auto-platform-locale-localisation vs
> auto-content-locale-localisation.

Exactly.

> 
> I think good arguments can be made either way regarding which the default
> automatic localisation should be (the user's, or the author's).
> 

Yes, it becomes quite academic deciding defaults. The implications of
supporting both configurations results in the same technical requirements.

Which behavior is default and which must be configured is largely
inconsequential.

> > Since any data-point which would require localization is new to HTML5 and
> > the implementations of such features is patchy at best there is no
> > precedence for existing uses to preserve.
> 
> The relevant point to which we need to be backwards compatible is what has
> shipped.
> 
> This is made clearer by not considering the current contemporary HTML spec
> to be "HTML5". Calling it "HTML5" implies that there has been one standard
> from 2004 to 2014. There have been thousands of HTML versions in that time.
> 

Fair enough.

> 
> > That browsers have implemented some patchy prototypes which don't take into
> > account locale resolution, it has to be questioned if they have considered
> > it at all. Ergo a bug.
> 
> We can call it "bugwards compatible" if that terminology feels more accurate
> to you. The end result is the same.

I wasn't aware of the term, but it is an accurate description.

> 
> The term "Living Standard" tries to reflect this reality by removing the
> fake or misleading stability markers inherent in calling a specification a
> "draft" or "finished". While the spec is relevant, it must be updated and
> must take into account the reality it is attempting to steer.

Fair enough. I appreciate the practicalities of the process.

> 
> I assume you mean ':lang()' rather than ':locale()'. I don't think anyone
> was proposing a ':locale()' pseudo-class (what would it match against?).
> 

Ignore the prior negative example. 

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

If we consider that the effective locale may be set by the browser
configuration, authors may want to style for those locales. In the following
example the stylesheet refines the currency for Australian users by denoting
that it is USD:

    <style>
        span.currency::before {
            content: "$";
        }

        span.currency:locale(en-AU)::after {
            content: "USD";
        }
    </style>

    <span class="currency" lang="en-US">100.00</span>

> 
> Personally I would like all the sites I go to to give dates in the form
> YYYY-MM-DD, rather than the mix of MM/DD/YYYY, DD/MM/YYYY, and DD/MM/YY that
> I get now (I read content in three locales, not all English-based).
> Similarly, I want all numbers to be in the form "N,NNN.nnn" rather than the
> mix of "NNNN.nnn", "N NNN,nnn", "N'NNN.nnn", etc, that I get now. I
> personally think it's way more useful for the page to be localised to my
> platform's locale than it is for the page to be localised to the author's
> locale.
> 

Dates in the form "YYYY-MM-DD" is an international syntax and does not exist as
a cultural format in any locale. It would require the format to be overridden
either through author or user stylesheets (functionality and syntax pending).

One problem with localizing according to the platform locale is that this can
lead to inconsistencies within the page if any data has been localized on the
server. The main way to avoid this - or to phrase it another way - to provide
capabilities for people to mitigate this, is to integrate client-side
localization for any potentially localizable data.

This was the main thrust for <data> (and <time>).

> 
> > So, i conclude that the notion of client-side automated semi-translation of
> > localizable data points is a bogus concept. 
> 
> I do not draw that same conclusion, but I certainly understand where you're
> coming from. Luckily I think we can continue to expand the platform til we
> are both happy.

Yes, the conclusion i draw is from a personal authoring decision process not
from potential functional capability.

(In reply to Ian 'Hixie' Hickson from comment #33)
> There's long been talk of having CSS provide ways to localise content like
> dates and times (which would apply to <time>, for instance), and it would
> definitely also be good to have CSS have a way to provide information to
> control bindings that describes how they should be localised. If CSS were to
> add either or both of these features, I'd be more than happy to work to make
> sure HTML hooked into them appropriately.

It would be great to see this potential realized.

(In reply to Ian 'Hixie' Hickson from comment #13)
> 
>  - A list of what needs to happen with respect to automatic localisation
>     e.g. <input type=date> UI, <time> rendering... (see also comment 1)
> 

One further point is regarding the level of integration with BCP-47 locale
extensions. Has any thought been given to the potential for manifesting each of
the following attributes:

calendar
time zone data 
collation order
currency
number system

It seems that each of these has a place within HTML, if not the method to
define their application.

The application of extensions may either require some conjunction with user
locale so as to allow for pass through of things like timezone or currency, or
possibly the use of translate="no" and/or a CSS localization toggle, or perhaps
allowing partial BCP-47 extensions in lang="".

Consider potential use cases for:

<label>Enter Date\Time from the Japanese calendar</label>
<input type="datetime" lang="en-u-ca-japanese"/>

<label>Enter Date\Time from the UTC-14 timezone</label>
<input type="datetime" lang="en-u-tz-utce14"/>

<label>Select\Enter your phonebook names</label>
<select lang="en-u-co-phonebk" editable multiple sorted/>

<label>Enter some $USD</label>
<input type="currency" lang="en-u-cu-usd""/>

<label>Enter a Roman numeral</label>
<input type="number" lang="en-u-nu-roman"/>

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

Received on Thursday, 31 July 2014 16:01:56 UTC