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


--- Comment #34 from Ian 'Hixie' Hickson <ian@hixie.ch> ---
(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

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

> > This bug is just a feature request from authors to be able to control the
> > localisation more specifically.
> The bug is that it is impossible to show anything *other* than the
> "user's local platform conventions".

I don't understand the difference between those statements.

> There is no backwards compatibility to support.

I feel it is important to handle the backwards-compatibility implications
described in comment 24.

> 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

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.

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

> For a tangential discussion, what scope is there within a "living standard"
> for the appropriate review and refinement of new features? If the first
> draft is baked in stone with the first implementation, this doesn't provide
> the necessary environment for global standards development impacting
> disparate users. 

Web standards are set in stone by the first content to rely on a particular
implementation, whether or not the standard is described as "living" or not.
You could publish a standard and have it be a W3C Recommendation for 10 years,
but if nobody has used it, you could change it tomorrow. You could publish an
IETF RFC draft marked with all manner of "DO NOT USE" or "UNSTABLE DRAFT"
warnings, but if someone deploys a new version of amazon.com using that feature
five seconds later, your review period is over. Similarly, if your draft
doesn't match what was actually shipped, yet people depend on the feature, then
your draft needs to be updated to match what was shipped, regardless of whether
you like it, and regardless of whether you called your draft a "first public
working draft" or an "ISO standard".

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.

> I thought that you were implying that the locale could be set through CSS
> properties, in which case there is scope for infinite loops when you
> consider the additional requirement of needing to style based on locale
> selectors:
> :locale("fr") {
>  locale: "en"; 
> }
> :locale("en") {
>  locale: "fr"; 
> }

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

There's no infinite loop here, since the properties cannot affect the state
that the selectors depend on.

> > > There are no useless or unimportant definitions.
> > 
> > That's clearly false. There's lots of ways of including useless or
> > unimportant HTML markup. For example:
> > 
> >    <span class=""></span>
> > 
> > ...is semantically moot.
> Nope. Still means something. That it has no content is moot.
> I can still style it. I can still JS some content into it. Removing it from
> the page might break it in unknown or unexpected ways. We cannot make that
> judgment.

CSS cannot affect the semantics of that piece of markup. It's semantically moot
regardless of how you style it.

Script could mutate the content, certainly. In that case it would be different
content, and might no longer be semantically moot.

In the absence of script or style, that markup does nothing useful. My point is
just that the statement "There are no useless or unimportant definitions." is
not unconditionally true.

> Within the specific context of <html lang="">, I think that is a throwback
> to the bygone days of (X)HTML 4(.01) (Strict|Transitional|Frameset) when it
> was too confusing and difficult to remember what anyone should put at the
> top of their shiny new HTML page. That technological requirement forced
> people to lookup and use the closest DOCTYPE to hand, with little
> consideration for what else they were copying (lang, xml:lang, dir, xmlns).

This kind of authoring behaviour goes far beyond page boilerplate.

> What is the problem with users getting "their documents working by copying
> and pasting something that works nearly as they want" and then mutating the
> <html lang=""> until it works well enough for them?

The "problem" is just that it means we can't change what "lang" does, qv
comment 24.

> > It's not the semantic meaning we have to preserve, it's the user-visible end
> > result.
> But we have no standard user-visible behavior at present.

The world doesn't care if the behaviour is standard or not. It cares about
whether it is deployed or not.

> All we have are partial implementations of a draft specification.

That's all we ever have.

> If an english monoglot visits a french website, what use is there in
> 'localizing' the page data for them? Either they understand the content or
> they do not.

There are multiple locales even within English.

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.

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

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

Received on Wednesday, 30 July 2014 20:48:41 UTC