- From: Cameron Heavon-Jones <cmhjones@gmail.com>
- Date: Sat, 21 Jan 2012 14:19:10 +0000
On 20/01/2012, at 6:58 PM, Bronislav Klu?ka wrote: > >>> Hello >>> >>> There are two recent threads on localisation of form fields, one on input type=date, the other on the Decimal comma in numeric input. Both are about the question whether the form field value should be displayed according to the element's language, or rather based on the user's preferred locale. This looks like a basically interesting question to me; I see use cases for both: >>> >>> Use case for using User's preferred locale: >>> - The user is viewing a website in a foreign language, using his/her own computer. >>> >>> Use case for using the element's language: >>> - The user is viewing a website in his/her own language, but using a computer in an internet caf? in a foreign country (where (s)he might not even be able to change the language settings of the browser). >>> >>> As some formats may be very different, both situations can lead to misunderstanding of the values displayed in the form, and thus wrong submissions. It was pointed out, that the comma may be a 1000 or a decimal separator. Or, dates are arranged differently, e.g. M/D/Y in English, but D.M.Y in German. >>> >>> This makes me think, if UAs could be encouraged to invent some kind of UI for per-session overriding the localisation settings of both UA and website content. >> >> I think translation is the word here and accurately identifies the potentially inaccurate process taking place. >> >> Thanks, >> Cameron Jones > > No, localization is, localization goes beyond simple translation > > Brona Yes, but my point is that what is really desired here is translation, not localization. If the representation is within a specific language\locale and the user desires a different language\locale then that process is one of translation including transformation of localization. Thanks, Cameron Jones
Received on Saturday, 21 January 2012 06:19:10 UTC