Fix inverse unit handling
https://www.unicode.org/reports/tr35/tr35-info.html#Unit_Conversion 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 https://github.com/unicode-org/cldr/blob/master/common/supplemental/units.xml 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").
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”?
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?
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:
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”.
Considering further, I think we want to keep the distinction between them, so this is only a spec issue.