On Thu, 14 Jul 2022 15:27:43 GMT, Andy Goryachev <d...@openjdk.org> wrote:
>> True plurals (as in LDML) is not yet fully supported in the JDK. >> (`CompactNumberFormat` does for its own purpose >> (https://bugs.openjdk.org/browse/JDK-8222756), but not for general use) For >> this case, I think `ChoiceFormat` is the mid-ground solution, as Swing is >> only localized in a handful of languages. > > Upon further consideration, and after discussing the state of plural forms > support in JDK with @naotoj I realized that we cannot use ChoiceFormat here > at all. The numeric choices, and their corresponding resource strings are > locale-specific, and in some cases simply cannot be coded as a finite array > (see Arabic example above). > > One possible solution would be to add proper support for plural forms to > MessageFormat (which is definitely out of scope for this bug), or perhaps - > if showing sizes 0...999 as numbers is not acceptable - to simply fix the 0 > bytes case using KB format. That is, > > 0 - "0 KB" > 1 - "1 KB" > ... > > (i.e. handle the 0 bytes case separately): > > long len = ((Long) value); > > if(len == 0) { > // shows "0 KB" for 0 bytes > text = MessageFormat.format(kiloByteString, 0); > } else { > // retain existing logic > len /= 1024L; > > if (listViewWindowsStyle) { > text = MessageFormat.format(kiloByteString, len + 1); > } else if (len < 1024L) { > text = MessageFormat.format(kiloByteString, (len == 0L) ? > 1L : len); > } else { > len /= 1024L; > if (len < 1024L) { > text = MessageFormat.format(megaByteString, len); > } else { > len /= 1024L; > text = MessageFormat.format(gigaByteString, len); > } > } > > and revert the new resource string. 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. ------------- PR: https://git.openjdk.org/jdk/pull/9327
