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


--- Comment #29 from Cameron Jones <cmhjones@gmail.com> ---
I think it might be better to start with some appraisal of whether
auto-localization is a feature or a bug.

The ramifications of auto-localization being a feature are quite explosive, and
i don't believe that the implications have been thought through.

What benefit is auto-localization providing today such that it warrents the
necessity for an escape hatch? 

We must consider the eventuality that if an escape hatch is provided, will it
be used by default? Does this not render the default behaviour a bug?

> (In reply to Ian 'Hixie' Hickson from comment #28)
> If we want a mechanism to turn localisation on or off, then CSS is probably
> the best place for it, not the markup. 

In lieu of some specific syntax to consider, i think this could be problematic
as the locale will be defined through the same place as it is needed to be

> (In reply to Cameron Jones from comment #26)
> > 
> > I'm not that sure that mindless copy/paste should be a design consideration.
> It's one of the main ways that Web development happens.

As a declarative language, HTML by definition is a description of *what* the
document means. There are no useless or unimportant definitions. Everything has
an effect. Therefore, supporting a model of copy/paste which is not simply a
manifestation of referential transparency would violate the essential nature of
a declarative language.

You can not say something has meaning, and then ignore it at will (or when
*some* people use it incorrectly/without consideration for its effects). To do
so would be to render valid uses invalid and "break things across the web"(tm).

If people have copy/pasted that their page is within the Inuit locale then
lo(!) forever more it shall be.

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

Received on Tuesday, 29 July 2014 16:30:26 UTC