Re: [whatwg] Localisation of form fields
On 4.5.2012 23:17, Ian Hickson wrote:
On Fri, 27 Jan 2012, Bronislav Klu�~Mka wrote:
we are currently discussing localization in form fields, but that may
result in some unfortunate behavior if implemented alone, because data
will be displayed in localized representation in form fields but not in
HTML - server can translate text, but not localize data, since it has no
idea about local settings (language is not enough) and when data are
inserted into HTML on UA side using scripting, the problem is the same.
Suggestion
1/ output element
output element should follow similar logic for presentation as form fields
there is an example of output usage
http://dev.w3.org/html5/spec/the-output-element.html#the-output-element
form onsubmit=return false oninput=o.value = a.valueAsNumber +
b.valueAsNumber
input name=a type=number step=any +
input name=b type=number step=any =
output name=o/output
/form
but imagine full stop as thousands separator, comma as decimal , inserting
12.135,5 + 4.125,6 would result in 16261.1 (Number is fine, presentation
confusing)
so output element should follow presentation form of the forms as well
I agree. I think, though, that that's really something for the CSS layer
first. We can define all manner of data types and how they should be
localised, but without rendering-level support, it's not especially useful.
2/ FormatSettings object
[Constructor(),
Constructor(DOMString locale),
Constructor(FormatSettings locale),
]
interface FormatSettings {
attribute DOMString CurrencyString;
attribute Number CurrencyFormat;
attribute Number CurrencyDecimals;
attribute DOMString ThousandSeparator;
attribute DOMString DecimalSeparator;
attribute DOMString DateSeparator;
attribute DOMString TimeSeparator;
attribute DOMString ShortDateFormat;
attribute DOMString LongDateFormat;
attribute DOMString TimeAMString;
attribute DOMString TimePMString;
attribute DOMString ShortTimeFormat;
attribute DOMString LongTimeFormat;
attribute Array ShortMonthNames;
attribute Array LongMonthNames;
attribute Array ShortDayNames;
attribute Array LongDayNames;
attribute bool DaylightSavingTime;
attribute Number TimeZoneOffset;
DOMString format (String input, Array data)
Number CurrencyAsNumber (DOMString value)
Number StringAsNumber (DOMString value)
Date StringAsDate (DOMString value)
[and probably set of constants representing different types of error
regarding formatting and data sanitation]
}
What does the JS library space look like on this front? Is this something
that's done at all?
I agree that it makes sense to let Web pages style text to fit the user's
locale, but I don't think we should do it at the JS level if we can help
it. In particular, having the JS level have to explicitly use the
TimeSeparator for example seems like asking the authors to do too much
minutiae that could be taken care of at a higher level (CSS).
I can see you are pushing for CSS because of presentation level, but
1/ you need to display currency or number, what would you do?
span style=format-type: number; format-decimal-separator:
',';123.22/span
something like that? I can see that, but would be better something like
data role=number value=123.22 style=format-type: number;
format-decimal-separator: ','; /
data role=currency value=2.22 char=$ style=format-type: number;
format-decimal-separator: ','; format-currency-format: 2 /
this could enhance machine processing capabilities.
Nothing to do with JS API, you just brought me back to this already
discussed element.
We are discussing making data information universal (one data, several
localization).
2/ I would only assume that libraries for large, international projects
do contain such functionality, but there's no way to get the settings
from underlying OS.
3/ I would prefer moving with JS first, you can create display by
applying FormatSettings.format function (to get CSS functionality) but
it can give you additional functionality as well (FormatSettings
functions). Or essentially create both CSS and JS together as
complementary functionality.
Brona
Re: [whatwg] Localisation of form fields
2/ FormatSettings object
[Constructor(),
Constructor(DOMString locale),
Constructor(FormatSettings locale),
]
interface FormatSettings {
attribute DOMString CurrencyString;
attribute Number CurrencyFormat;
attribute Number CurrencyDecimals;
attribute DOMString ThousandSeparator;
attribute DOMString DecimalSeparator;
attribute DOMString DateSeparator;
attribute DOMString TimeSeparator;
attribute DOMString ShortDateFormat;
attribute DOMString LongDateFormat;
attribute DOMString TimeAMString;
attribute DOMString TimePMString;
attribute DOMString ShortTimeFormat;
attribute DOMString LongTimeFormat;
attribute Array ShortMonthNames;
attribute Array LongMonthNames;
attribute Array ShortDayNames;
attribute Array LongDayNames;
attribute bool DaylightSavingTime;
attribute Number TimeZoneOffset;
DOMString format (String input, Array data)
Number CurrencyAsNumber (DOMString value)
Number StringAsNumber (DOMString value)
Date StringAsDate (DOMString value)
[and probably set of constants representing different types of error
regarding formatting and data sanitation]
}
What does the JS library space look like on this front? Is this something
that's done at all?
What are you looking for?
There is plenty of JS i18n code out there for formatting and parsing
dates and numbers.
Are you talking specifically about conversion of form values between
an over-the-wire format and a localized display format?
--
Benjamin Hawkes-Lewis
Re: [whatwg] Localisation of form fields
On Mon, May 7, 2012 at 9:32 AM, Bronislav Klučka bronislav.klu...@bauglir.com wrote: I can see you are pushing for CSS because of presentation level, but 1/ you need to display currency or number, what would you do? span style=format-type: number; format-decimal-separator: ',';123.22/span something like that? I can see that, but would be better something like data role=number value=123.22 style=format-type: number; format-decimal-separator: ','; / data role=currency value=2.22 char=$ style=format-type: number; format-decimal-separator: ','; format-currency-format: 2 / this could enhance machine processing capabilities. Compare: http://wiki.csswg.org/ideas/content-formatting http://lists.w3.org/Archives/Public/www-style/2012Mar/0575.html -- Benjamin Hawkes-Lewis
Re: [whatwg] Localisation of form fields
On 7.5.2012 12:09, Benjamin Hawkes-Lewis wrote:
2/ FormatSettings object
[Constructor(),
Constructor(DOMString locale),
Constructor(FormatSettings locale),
]
interface FormatSettings {
attribute DOMString CurrencyString;
attribute Number CurrencyFormat;
attribute Number CurrencyDecimals;
attribute DOMString ThousandSeparator;
attribute DOMString DecimalSeparator;
attribute DOMString DateSeparator;
attribute DOMString TimeSeparator;
attribute DOMString ShortDateFormat;
attribute DOMString LongDateFormat;
attribute DOMString TimeAMString;
attribute DOMString TimePMString;
attribute DOMString ShortTimeFormat;
attribute DOMString LongTimeFormat;
attribute Array ShortMonthNames;
attribute Array LongMonthNames;
attribute Array ShortDayNames;
attribute Array LongDayNames;
attribute bool DaylightSavingTime;
attribute Number TimeZoneOffset;
DOMString format (String input, Array data)
Number CurrencyAsNumber (DOMString value)
Number StringAsNumber (DOMString value)
Date StringAsDate (DOMString value)
[and probably set of constants representing different types of error
regarding formatting and data sanitation]
}
What does the JS library space look like on this front? Is this something
that's done at all?
What are you looking for?
There is plenty of JS i18n code out there for formatting and parsing
dates and numbers.
Are you talking specifically about conversion of form values between
an over-the-wire format and a localized display format?
--
Benjamin Hawkes-Lewis
Not at all, those function are just additions for the code of this
object: actual user's OS settings of localization parameters (those
object attributes).
Brona
Re: [whatwg] Localisation of form fields
On 7.5.2012 12:11, Benjamin Hawkes-Lewis wrote: On Mon, May 7, 2012 at 9:32 AM, Bronislav Klučka bronislav.klu...@bauglir.com wrote: I can see you are pushing for CSS because of presentation level, but 1/ you need to display currency or number, what would you do? span style=format-type: number; format-decimal-separator: ',';123.22/span something like that? I can see that, but would be better something like data role=number value=123.22 style=format-type: number; format-decimal-separator: ','; / data role=currency value=2.22 char=$ style=format-type: number; format-decimal-separator: ','; format-currency-format: 2 / this could enhance machine processing capabilities. Compare: http://wiki.csswg.org/ideas/content-formatting http://lists.w3.org/Archives/Public/www-style/2012Mar/0575.html -- Benjamin Hawkes-Lewis This was not about CSS properties (i just chose some names), it's about the fact, that CSS will only give you presentation, but this is about data, data with specific meaning (number, currency) and how to specify them one way and let those data be displayed localized... it would seem like a semantic loss not to use this text property - that it is specific data, something with clear semantics, not just some set of characters. There can be number, currency, phone number, IP address... Brona.
Re: [whatwg] Localisation of form fields
On 7.5.2012 12:09, Benjamin Hawkes-Lewis wrote: Are you talking specifically about conversion of form values between an over-the-wire format and a localized display format? -- Benjamin Hawkes-Lewis No, I'm talking about just client side processing / diplaying. What I want is new abilities that can enhance browser based applications. E.g. think about calendar. Doing it in e.g. Delphi, I would ask OS to give me first week day. Doing it in browser, i would have to ask user. Format number into input? Why bother, type=number will do it for you, Format number into contenteditable Sure i can use CSS for presentation, input for inserting, JS libs for some other tasks... but actually having those information in raw form can give ability to perform task you simply cannot now (or you cannot do them exactly) i18n can tell you about generic settings what user might most likely have... It will tell you nothing about what user actually has. B.
[whatwg] Localisation of form fields
On Thu, 12 Jan 2012, Schalk Neethling wrote:
Is there a way to specify the locale input type=daye should use or does
it simply use the current locale? If so, does it choose the server
locale or the user locale?
It should use the user's locale for input (as determined by the user
agent), and should always be transmitted over the wire using the fixed
format described in the spec.
If we add author-level control for this kind of thing, it should be in
CSS, since it is presentational.
On Thu, 12 Jan 2012, Schalk Neethling wrote:
There will need to be a js, or server side function if js is not
available, function that converts whatever you get to the format you
require/expact. I was just curious what the default behavior would be
for the input element and, whether there would be a way to indicate
which format you wish returned.
The format you get will always be the same (the format described in the
spec). That's independent of what the user sees.
On Thu, 12 Jan 2012, Schalk Neethling wrote:
Ok, so reading some of the discussion, maybe being more precise with our
html lang= would help or, is this not inherited down the chain so, when
declaring input type=date, one needs to specify lang=en-US?
Will that have the desired effect as described earlier in the thread?
On Thu, 12 Jan 2012, Cameron Heavon-Jones wrote:
No, the current state is that the user's preferred locale will always be
used for localization.
If the language resolution algorithm was being used you would be able to
define it through the lang attribute or through http headers.
If you want to have specific localization you will have to roll your
own, you could still define the language on the attribute but you would
need to perform the formatting yourself using javascript.
This is currently correct. We may one day add a locale= attribute or
some such.
On Fri, 20 Jan 2012, Markus Ernst wrote:
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).
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.
That's not necessarily a bad idea, but I don't know what we can do to
encourage it.
On Fri, 27 Jan 2012, Bronislav Klu�~Mka wrote:
we are currently discussing localization in form fields, but that may
result in some unfortunate behavior if implemented alone, because data
will be displayed in localized representation in form fields but not in
HTML - server can translate text, but not localize data, since it has no
idea about local settings (language is not enough) and when data are
inserted into HTML on UA side using scripting, the problem is the same.
Suggestion
1/ output element
output element should follow similar logic for presentation as form fields
there is an example of output usage
http://dev.w3.org/html5/spec/the-output-element.html#the-output-element
form onsubmit=return false oninput=o.value = a.valueAsNumber +
b.valueAsNumber
input name=a type=number step=any +
input name=b type=number step=any =
output name=o/output
/form
but imagine full stop as thousands separator, comma as decimal , inserting
12.135,5 + 4.125,6 would result in 16261.1 (Number is fine, presentation
confusing)
so output element should follow presentation form of the forms as well
I agree. I think, though, that that's really something for the CSS layer
first. We can define all manner of data types and how they should be
localised, but without rendering-level support, it's not especially useful.
2/ FormatSettings object
[Constructor(),
Constructor(DOMString locale),
Constructor(FormatSettings locale),
]
interface FormatSettings {
attribute DOMString CurrencyString;
attribute Number CurrencyFormat;
attribute Number CurrencyDecimals;
attribute DOMString ThousandSeparator;
attribute DOMString DecimalSeparator;
attribute DOMString DateSeparator;
attribute DOMString TimeSeparator;
attribute DOMString ShortDateFormat;
attribute DOMString LongDateFormat;
attribute DOMString TimeAMString;
attribute DOMString TimePMString;
attribute DOMString ShortTimeFormat;
attribute DOMString LongTimeFormat;
attribute Array ShortMonthNames;
attribute Array LongMonthNames;
attribute Array ShortDayNames;
attribute Array LongDayNames;
attribute bool DaylightSavingTime;
attribute Number TimeZoneOffset;
DOMString format (String input, Array data)
Number CurrencyAsNumber (DOMString value)
Number StringAsNumber (DOMString value)
Date StringAsDate (DOMString value)
[and
Re: [whatwg] Localisation of form fields
Am 21.01.2012 15:19 schrieb Cameron Heavon-Jones: 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. I see that point. Reading the Decimal comma discussion, I am sure a simple per-session method to translate form input formats into other locales (without translating text) would be a handy thing, but I admit this list may not be the appropriate place to discuss it.
Re: [whatwg] Localisation of form fields
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
[whatwg] Localisation of form fields
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.
Re: [whatwg] Localisation of form fields
On 20/01/2012, at 3:56 PM, Markus Ernst 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
Re: [whatwg] Localisation of form fields
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
