On Thu, 14 Jul 2022 20:17:14 GMT, Andy Goryachev <d...@openjdk.org> wrote:
>> Actually, my point was that since Swing is localized only in languages that >> can be dealt with (0, 1, other) choice patterns (or no plural pattern such >> as in Japanese), `ChoiceFormat` can still be used. Once we support complex >> plurals such as Arabic, we may need a more sophisticated solution. > > We seem to have resources localized in French. French rules are as follows: > one → n within 0..2 and n is not 2; > other → everything else > > ChoiceFormat simply cannot be used for number localization, we should remove > it being mentioned in MessageFormat javadoc, at least remove the example with > plurals. > > The whole idea is that localization process does not require a code change. > With ChoiceFormat, it does - as the choices depend on language, and rules for > some languages cannot be expressed as a set of choice, as for example in > Ukrainian and many other Slavic languages: > > one → n mod 10 is 1 and n mod 100 is not 11; > few → n mod 10 in 2..4 and n mod 100 not in 12..14; > many → n mod 10 is 0 or n mod 10 in 5..9 or n mod 100 in 11..14; > other → everything else Yes, you are right that `ChoiceFormat` is not for general localization. However, the supported UI translations in the JDK are English, German (new in 19), Japanese, and Simplified Chinese. (https://www.oracle.com/java/technologies/javase/jdk18-suported-locales.html for JDK18). That's why I made the point. ------------- PR: https://git.openjdk.org/jdk/pull/9327
