- 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
I18N-ISSUE-462: Human readable formats for numeric percentages ⓟ [tabular-data-model] http://www.w3.org/International/track/issues/462 Raised by: Richard Ishida On product: tabular-data-model 6.2.2 Formats for numeric types http://www.w3.org/TR/2015/WD-tabular-data-model-20150416/#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