Support smart units / unit contexts / preferences


The idea here is to say that you want to format "road distance", and have the correct unit chosen based on the locale and scale.

I had an initial idea on how this could be implemented: simply add another setter to NumberFormatter like this:

Semantics: The regular "unit" setter turns into specifying the input unit; the output unit is the same as the input unit if unitContext is not specified, and the output unit could change if unitContext is specified.

We could decide whether or not to move forward with an API that directly returns the resolved unit, rather than putting it all in the formatter.

The unit preference IDs are already in CLDR data.



Shane Carr
April 19, 2019, 8:37 PM

Semantics for the multiplier: I think this should be allowed to coexist with the regular multiplier/scale setting. The number can be scaled at the same point in the code that the multiplier is applied. For efficiency, if a double is provided, computation should be performed in the double space; if a BigDecimal or decNumber is provided, computation should be performed in the exact space.


Shane Carr
July 25, 2019, 9:29 PM

Moving this to "future" because this is blocked by the CLDR design.

Younies Mahmoud
September 1, 2020, 6:51 PM
Hugo van der Merwe
October 1, 2020, 1:56 PM

We can probably close this ticket soon: as soon as it’s no longer guaranteed that a commit referencing this ticket will be in ICU 68, we should associate with new tickets instead. (Something not successfully cherry-picked into 68 must not be associated with this ticket.)

Shane Carr
October 2, 2020, 12:06 AM

Closing as Fixed. If there are any remaining changes for ICU 68, we can temporarily re-open this ticket, or submit the fix in a follow-up ticket.



Younies Mahmoud


Shane Carr








Time Needed


Fix versions