-
Notifications
You must be signed in to change notification settings - Fork 14
Per Units #7
Comments
In previous discussion in TC39 about UnitFormat, @waldemarhorwat suggested that arbitrary unit combinations to be supported. If it's feasible to implement this in ICU, that would help to meet this goal. I don't have enough background in the domain to understand whether this feature is demanded by users, or how difficult it would be to implement; maybe we should discuss it further in the next Intl call. |
Arbitrary unit combinations would probably need locale data that we don't currently have in CLDR. I think it hasn't been done in ICU/CLDR yet because there hasn't been enough demand or practical use cases. |
I see, I misunderstood the above sentence. OK, let's watch out for practical use cases, and for now, just stick to the fixed list of units which are well-supported. |
Yes, what I meant by that sentence was, CLDR allows any two units to be combined into a single numerator and single denominator on a per-unit (e.g., joules per furlong). |
Closing this as a duplicate of #19. |
ICU exposes APIs for "per units", like "meters per second", and I realized that I didn't put in API for this into the current unified number format proposal.
A few units, including "meters per second", have standalone unit identifiers in CLDR. Here is the full list of CLDR units:
https://unicode.org/repos/cldr/tags/latest/common/validity/unit.xml
However, CLDR allows any two arbitrary units to be combined. Should we expose this functionality as part of the current proposal, or should we wait and do it in the future?
Note: I have previously suggested to ICU/CLDR that we should support arbitrary combinations of units in both the numerator and the denominator. That hasn't moved, but if ICU did ever add support for that, it would be nice if Intl.NumberFormat could reflect it and not necessarily be locked down to a per-unit setting that accepts only one unit.
@zbraniecki
The text was updated successfully, but these errors were encountered: