- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 29 Jun 2011 11:16:34 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Adrian Bateman <adrianba@microsoft.com>, "HTML WG (public-html@w3.org)" <public-html@w3.org>
On Tue, Jun 28, 2011 at 8:20 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> 3. String localisation >> >> a. There are numerous examples on the web today of web developers searching >> for a way to localise the 'browse' button that is used on file upload >> controls [1],[2],[3],[4],[5]. There is already at least one public example >> of web developers asking how they can localise the date control [6]. A rich >> datetime control requires strings and it should be expected that string >> localisation will become an issue in these controls if developers do not >> have a way to specify their requirements. > > Yes, this does indeed seem like a problem. I don't agree with Tab that > you generally want to simply use the locale of the browser. It always > looks pretty terrible to me when I'm browsing on a swedish website > that suddenly has a few random elements with english in them, or the > other way around. So I think that more often than not websites will > want to use the locale of the website. > > One solution to this would be to use the lang attribute on the <input> > (or an ancestor of it) to allow the website to choose which language > to use for the strings. This would of course require UAs to have the > names of the months and weekdays localized into terribly many > languages. I don't know if this is realistic or not, but given the > small number of strings that needs to be localized, it might work. Or > at least it might work well enough to cover 80% of the use cases. > > A pretty terrible fallback would be to introduce attributes which let > the site define the strings to use for the month and weekday names. If this does need to be addressed, I agree that having the UA localize based on the element's language is the best solution. ~TJ
Received on Wednesday, 29 June 2011 18:17:22 UTC