1. An additional kind of rounding rule is needed for CompactDecimalFormat, to round down, suppress insignificant trailing decimal 0s (as too misleading), and have a minimum number of significant digits (eg 1 sig. dec. leads to unacceptable error) but otherwise be fixed.
So for 1369
1.3K
13K
136K
1369K
but for 1069
1K
10K
...
This probably needs a modified rounding mode, and maybe API to pass it in to CDF.
2. The client needs to be able to find out the *effective* plural category, to get better agreement with the surrounding message. For example:
For 1021, resulting in "1K books", the effective number is 1000 — and its plural category is plural. So the effective plural category is plural.
The original number 1021 does not appear in the output. It can't be used for agreement, because it is singular in many languages (ending with 21), and languages agree with what is visible.
Note: we haven't yet researched this, but it may be that some languages use as the effective plural category the visible number without multiplying by the suffix. That is, they would have the equivalent of "1K book" because the "1" is singular. On the CLDR side we need to find out if there are any such languages and have a flag if there are that ICU can pick up.
GoogleIssue:71886008 (#comment7)
Revisit after this ticket is fixed.
CLDR ticket: https://unicode.org/cldr/trac/ticket/12010
I just now merged the ICU4J implementation into ICU master. Next up is the C++ version of that logic.
I submitted the C++ port (PR #972) of the previous Java implementation (PR #833).
I think we can mark this bug as fixed now.
Fix implemented in ICU4J (PR #833) and ICU4C (PR #972).