RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as 1 KB [v4]

[Andy Goryachev]

On Thu, 14 Jul 2022 19:50:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> 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.

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

-------------

PR: https://git.openjdk.org/jdk/pull/9327