Fix inverse unit handling

Description currently has only one paragraph about inverse handling. This paragraph needs improvement, and the specification of inverse fleshed out. The sentence on the inverse:

"The quantity for a complex unit that has a reciprocal is formed by prepending “inverse-” to the quantity, such as inverse-consumption."

  • Currently unitPreferenceData in has "consumption-inverse" usages, not "inverse-consumption".

  • How this data is to be used is not clear. Both "consumption" and "consumption-inverse" have regions="001" entries, meaning default fallbacks.

  • Should there be only one entry (only "consumption", and not "consumption inverse")?

  • Or should these two be treated as a merged entry automatically, which would mean priority for the 001 region needs to be established?

  • If we want this tweakable, API's using this data might need an "enable inverse" and "disable inverse" option, then the fallback is useful (but precedence needs to be clear for "enable inverse").






Hugo van der Merwe
April 7, 2021, 4:19 PM

PRs 991 and 1010 fixed the unit preferences merging consumption and consumption-inverse for vehicle-fuel. This solution makes sense to me, it works, I think no spec work is needed.

I propose: drop “docs-spec” component, “spec” label, “SPEC:” prefix in the issue name, then mark “Done”?

Peter Edberg
February 4, 2021, 7:31 PM

In addition to the existing PR-991 for units.xml, also need to fix the test data in CLDR but used by ICU. I am making that fix now=> done in PR-1010

Hugo van der Merwe
January 27, 2021, 8:01 PM

I think we know what the desired behaviour is for ICU NumberFormatter for “usage/vehicle-fuel” - so I can special-case this into the code until we figure out how to handle this properly in CLDR data?

Hugo van der Merwe
January 27, 2021, 8:00 PM

ICU currently special-cases consumption-inverse. unitQuantities doesn’t have an explicit inverse entry for consumption, it only has this:

For unitPreference handling, the unitPreferences entity could have an attribute that indicates inverting is acceptable for category=”consumption” usage=”vehicle-fuel”. E.g. changing from this:

To this:

It means for any inverted unitQuantity FOO, we should not just add on “FOO-inverse” or “inverse-FOO” and continue normally, we should, at preference-resolution time, fall back from FOO-inverse to FOO if FOO is flagged as invertible.

Then we need the desired fallback behaviour for when both <FOO-inverse> and <FOO invertible> is present. I’m also considering fallbacks from <consumption / vehicle-fuel> to <consumption / default> when, say, default is flagged as “invertible”.

Mark Davis
January 26, 2021, 12:21 AM

Considering further, I think we want to keep the distinction between them, so this is only a spec issue.





Mark Davis


Hugo van der Merwe


Hugo van der Merwe



Fix versions