[Bug 17918] i18n-ISSUE-136: Recognition of number formats in Number state

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17918

Addison Phillips <addison@lab126.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |addison@lab126.com

--- Comment #4 from Addison Phillips <addison@lab126.com> ---
Your explanation makes sense, but I think that the section itself isn't clear.

As Norbert pointed out, the example is given as:

--
For example, a user agent in Persian or Arabic markets might support Persian
and Arabic numeric input (converting it to the format required for submission
as described above). 
--

This isn't clear enough: it calls out a "more special case" for Persian digits,
but potentially leaves intact an impression that ASCII input must conform to
the "algorithm to convert a string to a number". That algorithm is intended for
the internal, locale-neutral representation and is not suitable for an
international user's input. 

[Note that this algorithm doesn't handle grouping separators, although users
generally don't enter those and JavaScript toString doesn't produce them]

So, the problem isn't with the algorithms applied or the processing done
internally to the user-agent. It's that the intervening processing of the
user's input (as well as the presentation of the value to the user) is not
clearly enough earmarked as needing to be localized. I would suggest that the
way to clarify this is to modify the example given above to say:

--
For example, a user agent might support numeric input in the user's local
format, converting it to the format required for submission as described above.
This might include handling different grouping or decimal separators (such as
"12.456,78", as customary in many European locales) or local digit shaping
(such as the use of digits in Arabic, Persian, Devanagari, Thai, and other
scripts) or a combination thereof.
--

Finally, there is no guidance for how the page author can control the
appearance of the input field in the page. Ideally, the user agent would follow
@lang of the element when presenting the value so that the page looks
consistent. That is, this:

<label lang="en-GB">How much are you willing to pay:<input type=number min=0
step=0.01 name=price value=12345.67></label>

Looks like this:

  How much are you willing to pay: [ 12345,67 ]

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

Received on Tuesday, 20 November 2012 16:29:03 UTC