So for example "1002" is "few" in this sense (even though it's bigger than 100) but "14" is not, even though it's less than 100 and ends in 4.
It's a great abstraction that makes a lot of Fluent easier :)
As far as the cases used go, 1024 would take the genitive singular in Russian. 1025 would take the genitive plural. 1021 would take the nominative singular. Nominative plural is not used at all when counting things in Russian.
tabs-close-warning-multiple = {$count ->
[2..4] Chystáte se zavřít {$count} panely. Opravdu chcete pokračovat?
*[] Chystáte se zavřít {$count} panelů. Opravdu chcete pokračovat?
}
Specify a range (2..4). The second option shouldn't need to match as it is the default value anyway (signified by the *) n % 10 = 1 and
n % 100 != 11 or
v = 2 and
f % 10 = 1 and
f % 100 != 11 or
v != 2 and
f % 10 = 1
…where n is the absolute value of the number, f is the visible fractional digits with trailing zeros, and v is _the number_ of visible fraction digits with trailing zeros. Some rules can get even more complex than that; see [0] and [1].It's safer and more robust to rely on the plural categories defined by the Unicode: (zero | one | two | few | many | other), and by the APIs provided by the platform (ICU, Intl.PluralRules, etc.).
[0] http://www.unicode.org/cldr/charts/latest/supplemental/langu...
[1] http://unicode.org/reports/tr35/tr35-numbers.html#Operands
That's an interesting suggestion! Right now, the identifier between the brackets is required, but we could relax this in the future. In 1.0, we erred on the side of more conservative and explicit design, to improve the readability and discoverability of the syntax for translators.
My point is that while there might be a concept of "few" that does map uniquely to that range, I am not sure naming the keyword "few" is the right name for this.
Quite honestly it would be easier to understand if it were explicitly referring to the range. After all these strings are provided specific to a language anyway. As such why not encode the rules in them explicitly instead of relying on keywords?
Or are those merely user defined abstractions to accomplish reuse? I guess it would help, but I'm still not sure why this needs a whole new framework.