Fix inverse unit handling

Description

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

Activity

Show:

Hugo van der Merwe 
April 7, 2021 at 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 at 7:31 PM
(edited)

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 at 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 at 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 at 12:21 AM

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

Fixed

Details

Components

Labels

Priority

Fix versions

Assignee

Reviewer

Reporter

Created May 14, 2020 at 5:59 PM
Updated April 7, 2021 at 4:56 PM
Resolved April 7, 2021 at 4:55 PM