add more units for the next release


Deleted Component: other

Draft list is on

In addition, add structure with the SI prefixes, and specify how to use those to dynamically form names. One question is whether they should be patterns, eg (yotta{0}) or just simple strings. The former would allow more flexibility, but I'm not sure whether it is needed.

After discussion, here are some changes to the above that haven't yet been added:

Drop: farad, coloumb, lumen, candela, mole, pascal, kiloliter, energy-kilojoules

centiliter, decimeter, lux

(only certain locales, Fredrik to determine): scandinavian-mile, kryddmått (need English name), deciliter-per-kilometer and liter-per-scandinavian-mile (fuel consumption), scandinavian-cubic-mile and scandinavian-mile and scandinavian-square-mile

en-modern-only: stone, bushel, cup, tablespoon, teaspoon

change the Metric? column to be a flag indicating that SI prefixes are applicable






Mihai Nita
July 10, 2019, 5:57 PM

Whether we like it or not, this is in common use.

See for instance (search for GiB if not immediately visible):

And it is a matter of lawsuits (see and the References section at the end of

So if we don’t support this in ICU then people are forced to hard-code their own thing.

We can decided later for “patterns, eg (yotta{0}) or just simple strings”, for now we can do what we are already doing for kilobyte, megabyte, gigabyte, terabyte, petabyte (and same for bit). Meaning simple strings.

And we can leave leave patterns for a refactoring (which might touch a lot of other things beyond bit/byte)

So should we split this ticket in two, one for “binary prefixes“ and one for “patterns vs strings” refactoring?

Thank you,

May 10, 2019, 1:44 AM
Trac Comment 16 by —2018-04-03T14:55:49.616Z

for IEC units (mebi…)

May 10, 2019, 1:44 AM
Trac Comment 12 by kent.karlsson14@0885cc00c95d6cd9—2014-05-03T16:57:37.577Z

I do object to removing Scandinavian mile.

All my other comments are still standing as well! Please read comment 9 above.

May 10, 2019, 1:44 AM
Trac Comment 11 by kent.karlsson14@0885cc00c95d6cd9—2014-05-03T16:42:14.869Z

1. "<displayName>degrees kelvin</displayName>
<unitPattern count="one">{0} degree kelvin</unitPattern>
<unitPattern count="other">{0} degrees kelvin</unitPattern>"
<unitPattern count="one">{0}°K</unitPattern>
<unitPattern count="other">{0}°K</unitPattern>"
Those are wrong, there are no "degrees kelvin", it is called "kelvin", and the symbol is K, NOT °K.

2. In addition, for "weather", you have missed an important unit, mm/h, for precipitation.

May 10, 2019, 1:44 AM
Trac Comment 9 by kent.karlsson14@0885cc00c95d6cd9—2014-05-01T23:55:53.183Z

Replying to (Comment 7 mark):

Replying to (Comment 5 kent.karlsson14@…):

> Split:

> ”consumption”: split! inverses should not share a category; split into

> "consumption" (volume per distance) and

> "mileage" (for lack of better word; distance per volume)


The categories are not necessarily different physical quantities; they are simply grouping for organizational convenience. However, I will bring this up to the committee as to whether we should change this.

For all units in CLDR 25 each category has been for one and only one physical quantity. It seems to be a bad idea to depart from that.

> Delete:

> ”amount-karat”, what amount? (there is a carat used for "purity" (usually for gold),

> but that is like a percentage [parts-per-24 rather than parts-per-hundred|but] not a unit);


The karat *is* used. 7,810,000 instances on Google, compared to only 59,000 for kryddmått.

I never said it wasn't used. But it is not a unit in the same sense as the other units items in CLDR. For instance, 239 carat gold (referring to the purity, not the weight) does not make sense. And yes, the two different kinds of carat (weight and purity) are spelled the same (even though one can make an artificial distinction in English: c/k), only context decides which is meant. Another reason not to include this one in CLDR.

I agree that "amount" is ugly. Will bring that up to the committee as well. It is really a proportion.


> ”mass-carat” is ok.

> ”foodcalorie” does not make sense.


Foodcalorie *does* make sense, see Peter's email comments. It is just a different name for a quantity (kcal). But you yourself are proposing that, with scandinavian mile (=10km) or spicemeasure (=1ml)

(I haven't gotten a copy of that email...)

That is not the problem. The problem with this one is that it, beside from being a bad idea (and food products ARE marked with kJ as well as kcal (kilocalories), not "food calories"), it will confuse translators to no end. It will also confuse application programmers to no end.

Wikipedia: "Sometimes, in an attempt to avoid confusion, the large calorie is written as "Calorie" (with a capital "C"). This convention is not always followed, and not explained to the average person clearly." Indeed, and not at all helpful, especially not in a CLDR context. That people say "calorie" while referring to kilocalorie is an error, not something to be supported in any way.

> <unit type="pressure-millimeter-of-mercury">, old and now unused


Unused? Again, you appear to be only considering regional usage. 1,570,000 hits on Google.

Claimed (Wikipedia) to now be mainly used in medicine (for blood pressure); NOT for other pressures (like in meteorology or engineering). The other pressure units in CLDR are clearly geared towards meteorology, and are listed under weather. ST/beta erroneously has mm Hg under "weather", not "medicine", which would be appropriate if you insist on including it (as you say CLDR can't include all units, but you seem determined to include every one of the imperial units). For medicine there are then several other units that should be included, such as ml/h, various concentration units (for medications, blood gases), and others (I don't have a list).

> The following have various errors (see replacement below):

> <unit type="digital-gigabit">

> <unit type="digital-gigabyte">


> Add:

> <unit type="digitaldatarate-gigabit-per-second">

> <unit type="digitaldataamount-gibibyte">


As to the per second, we are using a different mechanism.

Which? Though I used to support a compositional approach, I don't anymore, for the "full name" of units; though it would work well for short/narrow forms. Not a problem with "per", as the use of inflection instead of "per" does not generalise; but still. But large "bit"
amounts are normally only used in the context of data rates.

As to gibibyte, you are disregarding previous email on this topic. While a laudable attempt, it is simply not in widescale use.

Like it or not, inclusion in CLDR will constitute a recommendation to use. But in this case:

  • The units themselves are not ill-defined; e.g. 1 megabyte is exactly one million bytes (fine, assuming for the moment that byte is interpreted as exactly 8 bit, which is not historically true, though that is the prevalent modern use; I'm sure the French translation will say "octet").

  • However, "megabyte" has much to often been used for "two raised to twenty bytes" (etc. for other prefixes). They have thus acquired an ill-definition. And for that reason they MUST NOT be used, regardless of how many hits you get in search engines. And there are now established alternative units that do not have acquired ill-definitions.

"...According to a Google search, there are 305 times (30500%) more instances of gigabyte...."

Irrelevant, as that reflects unstable, and ill-defined, usage. It would be irresponsible to recommend their use (and yes, inclusion in CLDR still will be read as recommendation of use, in this case globally). Using arguments like yours, all and any improvement for the better
would be impossible.

**Please do not repeat requests that have already clearly been denied, unless you have new

compelling evidence to present.**

See above, as I apparently do need to repeat myself.

> ampere-hour


> volume-spicemeasure


We are adding (they are already in) the cup, table/teasppon, and some scandinavian miles, but in modern coverage only for some countries. See the latest checkin.

Ok (but were not there when I wrote the comment).

However, the "bushels", "fathoms" and *other imperial* units really do need to be limited to US/GB. Only inch has a (declining) global use; declining since sizes of (large) display units are now given also in cm, the use of inch for small displays has not been all that common. And yes, jeans sizes, but there it is an approximation, and indeed you will find size tables that says things like "size 31 [be read as inches|would]....30 in..." etc. (see e.g., and press the "size chart" and see the Denim table). I.e., even though they might look like it, they are not really inch sizes.


a. '(?!sv|nb|no)' (in coverage): I think you meant ('?!sv|nb|nn)'.

b. 'key="%notEnglish" value="(?!en)"' This should refer to English (and Spanish) in US and GB *only, not English elsewhere, in particular not "global English". I.e. imperial units should be asked to be translated for en_US (NOT for 'en'), es_US, and en_GB (possibly cy, and other languages used (only) in GB).

c. 'key="%englishUnit" value="(length-fathom|length-furlong|mass-stone|volume-bushel)': PLEASE DO add all other imperial units (except inch, for some more years...) to that list.

That is for ST only, you also need to "tell" application programmers that imperial units are inappropriate outside of US/GB.

We cannot add all all units: unclear whether we need ampere-hour or milliampere-hour, or volume-scand-cubic-mile.

Can't add all units to CLDR (esp. since the systems are logically productive), but (milli)ampere-hour is a common unit for battery capacity. All portable computers and all mobile phone have batteries... I would expect a (good) battery monitor to state
the battery capacity, wether nominal/original, or even better, estimated actual maximum capacity as batteries tend to degrade over time. Also "estimated remaining capacity" (remaining charge) in mAh (not just percentage of max) could/should be of interest to display.

See A·h or Ah (it is permissible to leave out the dot, even without space) in and

Can wait with scand-cubic-mile (but seems a bit unbalanced, since you have the corresponding, and not all that common, English cubic mile), but it IS used.

> Better "type" (category) names:

> <unit type="mass-metric-ton"> -->> <unit type="mass-tonne">

> <unit type="mass-ton"> -->> <unit type="mass-short-ton">

> "acceleration-meter-per-second-squared" --> "acceleration-meter-per-second-per-second"


"Better" is debatable, but I'll bring these to the committee as well.

Well, "metric ton" does not work well with prefixes ("megametric ton"? naa). While more directed at the actual (full) name than the type name, they usually coincide (after the category/type, and ignoring hyphens) for English. "Short ton" makes it clear that it is not the "tonne". That is important both for translators and "end users". Re. "meter-per-second-per-second", that is the logic of the unit, and "square seconds" (and it will be translated as if it said that) may be a bit too strange, though I would be ok with it. "second-two" (another suggested "translated as" alternative) is no better (and quite ugly).




Mark Davis


Mark Davis


Peter Edberg





Fix versions