[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 #26 from Cameron Jones <cmhjones@gmail.com> ---
(In reply to Addison Phillips from comment #25)
> (In reply to Ian 'Hixie' Hickson from comment #24)
> > Here's a more detailed description of the scenario I described in comment 20:

I'm not that sure that mindless copy/paste should be a design consideration.

The state of play is that there are local settings which affect the
presentation of the data to the user with the effect that the meaning of the
document changes in regards to how - or where - it is viewed.

We should remember that this only affects the new HTML5 date/time form controls
and prior to this i don't think browsers were imposing auto-localization (there
was no such functionality).

So, i guess to step back, we could ask if the approach taken by browsers in 
implementing the HTML5 date/time controls is just a bug? That was my initial
appraisal.

However, i believe that the descision by browsers to auto-localize has been
taken in the name of the user's best interest. In some regards this does remove
the ambigous situtation as the user will always see data within their own
locale. 

So in effect, the browser has protected its internal integrity across pages at
the cost of a website's integrity across browsers.

Given that the browser advertises its locale within the HTTP header, i don't
think that it should be auto-localizing as the page should have already been
localized in processing the appropriate response.

However, this kind of auto-behaviour is also seen with translation tools which
incurred the requirement to introduce the translate="no" attribute. This
auto-localize case is effectively synonumous with that use case and so should
be served with the same solution, namely a global localize="no" attribue.

This would also allow for turning on/off the existing behaviour over partial
DOM trees.

> 
> I agree that this scenario might be a problem, in cases where the browser
> displays the value formatted in an ambiguous form. I notice that Chrome does
> this currently--and thus your scenario already exists in reverse. If I visit
> a page for (let's say) British Airways and see that the date of my travel is
> 02/01/2014 while the page is in UK English, mightn't I naturally assume that
> this is January 2nd rather than February 1st (the locale of my computer)?
> What if I'm using an unfamiliar computer, such as in an Internet cafe?
> 
> The page author has no control now. Isn't that an issue?
> 

One of the main problems with auto-localize is that it is impossible to declare
form controls in a specific locale.

This means that multi-lingual pages are impossible.

So, it is impossible to write lanaguge tutorials or other cross-cultural
educational documents.

> (In reply to Addison Phillips from comment #25)
> Expanding on Cameron's comment, just having @localized might be good. We
> might also provide picture string/format control/skeleton? Or are we getting
> too baroque in what we expect from HTML?
> 
>    <input type=date name=xxx lang=en-US localized=mdy /> <!-- produces
> month-day-year format with appropriate local separators for US English -->
> 
>    <input type=date name=xxx lang=en-US /> <!-- produces a date value
> localized according to the browser locale, since no @localized -->

Thinking about @localized (which i impied would be boolean), i think it would
be better to follow the approach from translate="no" as stated above.

The ability to control the format was something i thought would be better
placed for CSS as it *should* be a purely presentational customization.

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

Received on Thursday, 24 July 2014 16:20:48 UTC