[Unicode]   Common Locale Data Repository : Bug Tracking Home | Site Map | Search

CLDR Ticket #3727(closed defect: fixed)

Opened 6 years ago

Last modified 2 years ago

Fractions in plurals

Reported by: mark Owned by: mark
Component: main Data Locale:
Phase: Review: pedberg
Weeks: 0.5 Data Xpath:




Description (last modified by mark) (diff)

(Updated after review.)

This is a proposal for additions to plural categories for better support of plurals with fractions. A common issue is that languages seem to work by the *visible* digits, so 1.0 hours vs 1 hour. That means that client software needs to allow for an additional parameter, which is the number of visible digits.


The patterns we have seen are:

  1. All fractions get the same form. (Eg, 'other' for Polish, English).

Can be done now.

  1. Go by the base form: that is, 2.x has the same form as 2.

Can be done now.

  1. Go by whether there are any visible fraction digits. So 1 gets 'other' but 1.0 gets 'other'.

Can't be done now. This is needed for English.

  1. Go by the last visible digit of the fraction. So 1.2 gets 'two' and 2.1 gets 'one'.

Can't be done now.

  1. Go by the last two digits of the fraction (if there are 2, otherwise one of 1/2/3). So 1.23 gets the same form as 23 does.

Can't be done now.

Design Proposal

A possibility for handling the above is to extend the rules in the following way.

  1. Define:
    • v to be the number of visible fraction digits.
    • f to be the visible fractional digits.
    • i to be the integer digits.
  1. Extend the syntax to be:
  • expr = 'n' ('mod' value)?


  • expr = ('n' | 'i' | 'f' | 'v') ('mod' value)?



Rule Changes

Then the rules can be augmented to use 'f' and 'v'. Examples:

  • For #3, one can have one: n is 1 AND v is 0
  • For #4, one can have "f mod 10 = 3"
  • For #5, "v is 2 AND f mod 10 is 3"

See also:


Change History

comment:1 Changed 6 years ago by mark

  • Description modified (diff)

comment:2 Changed 6 years ago by mark

  • Description modified (diff)

comment:3 Changed 6 years ago by jat@…

Rather than worrying about the number of visible digits, and figuring out what the rounding rules might be, I think for the "rightmost digits"-type rules they should just operate on the final string representation of the number.

Ie, if I am formatting 1.225 under the equivalent of %.2d, then the plural rules that care about the actual digits just at the end of the representation would base it off "1.23". Otherwise, you have to worry about whether it will be rounded to 1.22 instead, and I think that is far to complicated to put into the plural rules. So, the input into the plural rule selector would be (1.225, "1.23") and the rules that care could look at the suffix of the string format.

comment:4 Changed 6 years ago by mark

  • Milestone changed from UNSCH to postpone

comment:5 Changed 6 years ago by mark

  • Owner changed from somebody to mark
  • Priority changed from assess to major
  • Status changed from new to assigned
  • Component changed from unknown to spec
  • Milestone changed from postpone to 21

Tentative for 21, pending more investigation.

Spec, data; update to PluralRules code for testing/examples.

comment:6 Changed 5 years ago by mark

  • Keywords google added

comment:7 Changed 5 years ago by mark

  • Weeks set to 0.5
  • Milestone changed from 21 to 22

comment:8 Changed 5 years ago by mark

  • Component changed from spec to design

comment:9 Changed 4 years ago by mark

  • Description modified (diff)

comment:10 Changed 4 years ago by mark

  • Description modified (diff)

comment:11 Changed 4 years ago by mark

  • Description modified (diff)
  • Milestone changed from future to 23dres

comment:12 Changed 4 years ago by mark

  • Xref set to 3671

from #3671, for comparison:

We only have three kinds of behavior for fractions, where the first few are in only a few locales (5). We should verify that these are correct for those 5, since it is easy to misunderstand how the rules work.

Fract: one=0.x, 1.x; other=2.x-...
Locales: [ff, fr, kab, lag]

Fract: one=0.x; other=1.x-...
Locales: [shi]

Fract: other=0.x-...
[everything else]

x != 0

comment:13 Changed 4 years ago by mark

  • Milestone changed from 23dres to 24dsub

comment:14 Changed 4 years ago by mark

  • Description modified (diff)

comment:15 Changed 4 years ago by mark

  • Description modified (diff)

comment:17 Changed 4 years ago by mark

  • Component changed from design to data

comment:18 Changed 4 years ago by mark

  • Milestone changed from 24dsub to 24dsub2

comment:19 Changed 4 years ago by mark

Also look at the following (from 5736)

GNU Gettext documents since long that Hungarian and Turkish languages use two plural forms in a way similar to English, i.e.:
one : n is 1
other : all other cases
See also many references easily found on the web about plural forms in these two common languages such as:
For Hungarian:
For Turkish there are lots of similar references. e.g.
The data for Wolof is also wrong (there are evidences that it follows the same rule as French and Brasilian Portuguese)
Please fix CLDR data because these 3 languages are, currently, incorrectly listed as following the invariable rule with a single form (like Chinese or Japanese), notably on this page:
This is important for correctly implementing or porting Gettext, or for updating it !!

comment:20 Changed 4 years ago by verdy_p@…

This bug was about plural rules for numbers with fractions.

The report in bug 5736 (incorrectly merged as "duplicate" into this one) was unrelated as it concerned plural rules for integer numbers (though it could concern fractions, but the report did not speak about them; you also say that there's no reference for Wolof, but I provided a few of them and they are easy to find): note that initially only the forms explicitly with "number + noun" was considered, and in some languages these forms are invariant in nouns because the plural is already marked by the number itself. But translations also need to make distinctions of plural rules when the number is implied (like in English: he/she/it vs. they; him/her vs. them).

Such cases include also translations of things like "this following item: item1" vs. "these following items: item1, item2, and item3" for matching a plural rule when the actual number of items is not shown but impled by what follows (here the length of the list of items) and the plural is marked distinctile on the noun or on the determining adjectives. It may also imply grammatical adaptations in the rest of the sentence (e.g. conjugating verbs, changing grammatical case between accusative and genitive...)

comment:21 Changed 4 years ago by verdy_p@…

There's also a case when the number is not specified/unknown. Plural rules should be able to map an entry for NaN values when the actual value may be "one or several". In some cases the noun may take the singular or the plural depending on the meaning (e.g. in English with "how much"+singular noun, vs. "how many"+plural noun) or if the name is numberrable: in some cases the two meanings are valid and possible but they mean something different.

For all these cases, we need several plural rules to match an number implied by the context but still varifiable. There's mor ethan just translating "1 item" vs. "2 items" with an explicit numeral.

comment:22 Changed 4 years ago by mark

  • Review set to pedberg

comment:23 Changed 4 years ago by mark

  • Xref changed from 3671 to 3671 6211

Note: also includes fix to bug http://unicode.org/cldr/trac/ticket/6211

comment:24 Changed 3 years ago by pedberg

Split out cldrbug 6704: for Wolof plural rules (see comment:20 above).

comment:25 Changed 3 years ago by pedberg

  • Status changed from assigned to closed
  • Xref changed from 3671 6211 to 3671 6211 6704
  • Resolution set to fixed

comment:26 Changed 3 years ago by emmons

  • Milestone 24dsub2 deleted

Milestone 24dsub2 deleted

comment:27 Changed 2 years ago by pedberg

  • Milestone set to 24

Restore milestone


Add a comment

Modify Ticket

as closed
Next status will be 'new'
Next status will be 'closed'

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.