[Bug 27614] [XSLT30] zero-digit replacement? [I18N-ISSUE-393]

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

--- Comment #3 from Addison Phillips <addison@lab126.com> ---
(In reply to Michael Kay from comment #2)
> Personal response:

Ditto.

> 
> Note that xsl:number (in XSLT) and format-integer() (in both XSLT and
> XQuery) support other numbering systems, but format-number() (and hence
> xsl:decimal-format) does not. Neither has support for radices other than 10.

Radices other than 10 may apply to some numbering systems, but most are
actually tens based. The terminology overlap here is perhaps problematic? In
CLDR "number system" mostly means "script", e.g.
http://cldr.unicode.org/translation/numbering-systems and not different
numbering systems such as roman numerals, etc.

> 
> We introduced format-integer() to provide more flexibility than
> format-number() in the case where the numbers being formatted are integers,
> and at the same time to be context independent (there is no separate format
> declaration, as there is with format-number()). However, format-integer()
> and xsl:number still provide rather less that CLDR.

I think the I18N WG is concerned that we either try to sync up or at least
acknowledge the formatting categories and options that seem to be best current
practice, particularly as other standards (such as Javascript) also home in on
CLDR.
> 
> (And I've also found cases where CLDR seems to provide less than is needed.
> For example there seems to be a distinction in German between the
> grammatical contexts of "Chapter 101" (hunderteins) and "101 dalmations"
> (hundertundein) which I don't see in CLDR).

Actually, there are a number of these sorts of variations present in CLDR. See
for example
http://www.unicode.org/reports/tr35/tr35-numbers.html#Rule-Based_Number_Formatting

For example, in ICU4J (based on CLDR), I can write the following code:

    public static void spelloutDemo() {
        Object[] args = new Object[] { 101, 101 };

        MessageFormat mf = new MessageFormat("{0}");
        RuleBasedNumberFormat rbnf = new RuleBasedNumberFormat(Locale.GERMANY,
RuleBasedNumberFormat.SPELLOUT);
        mf.setFormatByArgumentIndex(0, rbnf);
        String[] ruleSets = rbnf.getRuleSetNames();
        for (int x=0; x<ruleSets.length; x++) {
            System.out.println(ruleSets[x]);
            rbnf.setDefaultRuleSet(ruleSets[x]);
            System.out.println(mf.format(args));
        }
    }

And produce this effect:

%spellout-ordinal-s
ein­hundert­erstes
%spellout-ordinal-r
ein­hundert­erster
%spellout-ordinal-n
ein­hundert­ersten
%spellout-ordinal
ein­hundert­erste
%spellout-cardinal-s
ein­hundert­eines
%spellout-cardinal-r
ein­hundert­einer
%spellout-cardinal-n
ein­hundert­einen
%spellout-cardinal-feminine
ein­hundert­eine
%spellout-cardinal-masculine
ein­hundert­ein
%spellout-cardinal-neuter
ein­hundert­ein
%spellout-numbering
ein­hundert­eins
%spellout-numbering-year
ein­hundert­eins

These don't produce the specific item you mention, but that might be a
shortcoming in CLDR data or it might be correct (I am not a native German
speaker and can't say what's right). If a category is missing, that might be a
candidate for addition to CLDR as well.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 29 December 2014 22:00:35 UTC