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

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?

I agree with Comment #23 that we could ameliorate this issue by providing an
extension to markup to "turn on" localized formatting. What I want to avoid is
having multiple ways of marking up language/locale information in an HTML
document.

Note: I have a demo page which I think is helpful here:

   http://www.inter-locale.com/test/DateDemo.html 

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

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

Received on Wednesday, 23 July 2014 21:56:33 UTC