W3C home > Mailing lists > Public > public-i18n-core@w3.org > April to June 2015

I18N-ISSUE-462: Human readable formats for numeric percentages ⓟ [tabular-data-model]

From: Internationalization Working Group Issue Tracker <sysbot+tracker@w3.org>
Date: Fri, 24 Apr 2015 16:17:27 +0000
To: public-i18n-core@w3.org
Message-Id: <E1YlgIB-0006tv-RK@maia.w3.org>
I18N-ISSUE-462: Human readable formats for numeric percentages ⓟ [tabular-data-model]


Raised by: Richard Ishida
On product: tabular-data-model

6.2.2 Formats for numeric types

"When parsing the string value of a cell against this format specification, implementations MUST recognise and parse numbers that consist of:"

the list that follows this makes allowances for groupChar and decimalChar, but still fails to capture real life formats from various cultures, when it comes to percentages.

For example, CLDR[1] shows formats where the percent sign appears to the left of the numeric sequence (Basque, Turkish), or where the percent sign is separated from the numeric sequence by white space (about 30 locales).

It's also not clear to me how pattern properties (which would appear to be the alternative) are taken into consideration in the validation checks (which actually are well-formedness checks, aren't they?).

It unfortunately seems a little too restrictive, and the alternative property values seem a little too simplistic, for international use.

Is there a way we can improve on that?

I'm wondering whether the spec should:
1. only specify required formats for normalized numbers (ie. converted to the canonical form)
2. do 1 and require applications to convert from real world scenarios as a separate step, taking into account the possible variations represented in CLDR
3. do 1 and provide a property that specifies a locale, which recognises values that cover all the CLDR alternatives
4. something else

[1] http://www.unicode.org/cldr/charts/27/by_type/numbers.number_formatting_patterns.html
Received on Friday, 24 April 2015 16:17:33 UTC

This archive was generated by hypermail 2.3.1 : Friday, 24 April 2015 16:17:34 UTC