Open Bug 1387437 Opened 3 years ago Updated 3 years ago
Impact of the lang attribute/localization on the different form types isn't documented
:: Developer Documentation Request Request Type: New Documentation Gecko Version: unspecified Technical Contact: :: Details Following the question of one contributor on our IRC, we noticed some behaviors we couldn't explain at first and I did some tests along with talking about that with Jessica Jong, which is why it lead me here to this bug. Different languages have different rules regarding formating of some types of informations (number, dates and so on). What I'll describe below is related to the input type "number", but could apply to other input types. We noticed it with French contributor: French rules to format numbers state that the coma (decimal point) is used to separate decimals and the dot used to separate thousands. On the contrary, US rules use a dot to separate decimals, and comas to separate thousands. However, very few people use thousands separator, and as far as I know those are not recognized. But while our rules states the decimal separator is a coma, many people took the habits of using a dot for different reasons and that person wanted to have dots accepted aswell in the input. We came to the use of the lang="xx" attribute. After doing many tests on my end, it appeared that if lang and browser's language were set to the same one, it only accepted formating of that language, but if they were different, it accepted both. Scale with arrows came into the play too as this could change the way number looks by switching a coma to a dot or a dot to a coma. This can be seen with this test: browser language: en-US lang attribute: fr accept both coma and dot; step on coma lang attribute: en-US accept only dot; step on dot browser language: fr lang attribute: fr accept only coma; step on coma lang attribute: en-US accept both coma and dot; step on dot I can provide the tests I used for that purpose. I didn't tested the meta tag specifying language which would come into play too. It looks like there are precedence rules coming here where it goes up to the rules on top of the current one if it doesn't match with the current one. Resources that were provided to me: Precedence rules in Firefox: http://searchfox.org/mozilla-central/rev/f0e4ae5f8c40ba742214e89aba3f554da0b89a33/intl/unicharutil/util/ICUUtils.h#44-57 The spec, which state browsers are pretty free of their behavior: https://html.spec.whatwg.org/multipage/input.html#input-impl-notes The bug where some of those matters were discussed: https://bugzilla.mozilla.org/show_bug.cgi?id=844744 Worth mentionning that Chrome seems to adopt another behavior and accept both formatting. Anyway, considering every browser present its own behavior, having those documented somewhere clearly is worth it, in my humble opinion.
You need to log in before you can comment on or make changes to this bug.