[Unicode]   Common Locale Data Repository : Bug Tracking Home | Site Map | Search

CLDR Ticket #11321(closed: duplicate)

Opened 4 months ago

Last modified 4 months ago

"food calorie" is entirely bogus, needs to be removed completely and permanently from CLDR

Reported by: kent.karlsson14@… Owned by: anybody
Component: units Data Locale: all
Phase: dsub Review:
Weeks: Data Xpath:



There is no such unit as "food calorie". Granted, there are many who say, or even write, just "calorie" when they mean "kilocalorie". But that is a mistake, or more accurately, a grave error, and should not be supported in any way whatsoever anywhere.

The translation data in CLDR for "food-calorie" is even more bogus, and will only confuse programmers as well as end users. That gravely misleading data must be removed from CLDR, sooner rather than later.

It is not a good idea to present bogus units, with bogus translations, to programmers nor to end users.


Change History

comment:1 in reply to: ↑ description Changed 4 months ago by srl

Replying to kent.karlsson14@…:

There is no such unit as "food calorie". Granted, there are many who say, or even write, just "calorie" when they mean "kilocalorie". But that is a mistake, or more accurately, a grave error, and should not be supported in any way whatsoever anywhere.

It's not bogus. The guidelines state specifically:

“energy-foodcalorie”, kilocalories for food energy; may have same translation as energy-kilocalorie.

comment:2 Changed 4 months ago by doug@…

CLDR did not invent the term "Calorie" to mean "kilocalorie." Rightly or wrongly, it has been in use in some cultures for a long time.

comment:3 follow-up: ↓ 4 Changed 4 months ago by kent.karlsson14@…

No, it's an error, not a culture. As for the "guidelines to translators", that does not help one bit; there is an arbitrary mixture of this and that in the submitted data.

Now, a few days ago I bought a soft drink. Looking closer at the label, it claimed that it contained 500 megalitres (500 ML) of beverage. Clearly a mistake. But a common one. Not everyone who should pay attention do... Does that mean that CLDR should have a "food-millilitres" "unit" (allowing a mix of mL, ML and other strings; per locale to boot, which is complete nonsense). OF COURSE NOT! It would be just as bogus as "food-calorie" is. Mistakes/errors can be forgiven in the small (e.g. for some food packages). But such mistakes must not be institutionalised, like being supported by CLDR (used in lots of software globally), as "the right thing to do" (even globally, as CLDR really does attempt to be global).

So again, please delete the bogus "food-calorie" from CLDR. Both the idea and the data (in CLDR) are misleading, arbitrary and useless.

comment:4 in reply to: ↑ 3 Changed 4 months ago by srl

Replying to kent.karlsson14@…:

No, it's an error, not a culture.

Put another way, daylight savings/summer time (in my opinion) is bogus and misleading, but removing support for it from CLDR would not be to anyone’s benefit.

However, what may be an issue that can be corrected here is:

                <unitPreferences category="energy" usage="food">
                        <unitPreference regions="001">foodcalorie</unitPreference>
                <unitPreferences category="energy" usage="person-usage">
                        <unitPreference regions="001">kilocalorie</unitPreference>

The above preference data doesn't sound right, I would expect kJ to be more common for energy-food. The translation guidelines could leverage the preference data to note "this unit is used in this region, etc.."

Last edited 4 months ago by srl (previous) (diff)

comment:5 Changed 4 months ago by kent.karlsson14@…

Yes. People err. And kelvin-calories (Kcal)... Obviously another error. I did not say that people did not err. I fact I said it was a quite common error to say or even write "calories" when meaning "kilocalories". That does not make it any less of an error. I also said that such errors can be forgiven in the small (e.g. on some food packages; i.e. I'm not going to lobby any food (package) producer; but more on that below). But such errors must not be institutionalised (effectively "standardised", but CLDR is not a standard). "Food calories" is bogus, there is no such unit, and it must not be supported in any standard or "close to a standard" (like CLDR, which is effectively treated as a global standard even though it is not a standard). And "allowing it to be 'kcal'" does not help; CLDR translators submit effectively random values anyway; and even if it had helped, the very idea of "food calories" is still bogus.

Note that in many, if not most, countries (e.g. the EU countries, Australia, Japan, ...), some of the units, and their proper designation, used in food package labelling is governed by legal or regulatory requirements. That includes "kcal" and "kJ" for energy (per 100g) in a commercial food product.

Food labelling requirements (which does not prevent people from erroneously saying/writing "calorie" when meaning "kilocalorie" outside of such labels):

  • Australia+NZ: www.foodstandards.gov.au/consumer/labelling/panels/Pages/default.aspx
  • EU: ec.europa.eu/food/sites/food/files/safety/docs/labelling_legislation_qanda_application_reg1169-2011_en.pdf, section 3.2
  • Japan: ap.fftc.agnet.org/ap_db.php?id=460&print=1 (informal description in English, referring to legal req.)
  • HK (China): www.cfs.gov.hk/english/faq/faq_14.html (informal page, but surely derives from legal req.)
  • etc. etc. etc.

As for the USA (and Canada?): the labels have the table entry heading "Calories", but the unit (kcal) is not required to be written out. The implicit unit is kcal (NOT cal or Cal, or "food calories" or some such). As USDA puts it: "kcal kilocalorie (commonly known as calories)"; see www.ars.usda.gov/ARSUserFiles/80400525/Data/hg72/hg72_2002.pdf, page v. Yes, that is doing the right thing and the wrong thing at the same time; but, unfortunately, it is common worldwide to say/write calories and mean kilocalories. It is the same effect as saying kilo when meaning kilogram (unit is kg, not k) or hecto when meaning hectogram; sometimes "degree" (or the degree sign) is left out for celsius or fahrenheit. It's inaccurate (without the degree sign C is really coulomb and F is really farad), but common, since it is tempting to short out what can be thought of as implicit parts.

So, there is a difference between headings in food labels and running text use on one hand, and the actual unit designation on the other hand. It is unfortunate that the unit is not required to be written out in the USA (and Canada) food labels. If the energy content (which is a better description than "caloric content") is also, as is optional, given in kJ, it would be best to write out both units (kcal and kJ) explicitly, under the heading "Calories", even though not (yet) formally required. Anyway, no trace of "food calories" or "Cal" even for the case of USA and Canada food labels.

Conclusion: "food calories" is bogus, there is no such unit, never has been, never will be. There is no Cal unit designation; just a misunderstanding. And yes, it does seem to be close to a CLDR invention. It is definitely CLDRs idea to try to spread this bogus idea worldwide, and gather bogus data for it worldwide. Wikipedia used to have an article about it; but now only mentions it in very degrading terms. It certainly does not come from any food labels; not even from "certain cultures" (where the unit, kcal, is not normally written out on the food labels). Don't confuse the table entry heading with the unit. In most other countries that have regulatory requirements on the matter, the corresponding heading is "Energy" (etc. in other languages), and the units are required to be written out (usually both kJ and kcal are required). Less room for confusion. But there is no "food calories" unit in any form or fashion anywhere in the world. (Except in CLDR, from which this bogus unit must be deleted.)

comment:6 Changed 4 months ago by srl

  • Status changed from new to closed
  • Xref set to 10969
  • Resolution set to duplicate

Add a comment

Modify Ticket

as closed
Next status will be 'new'
Next status will be 'closed'

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.