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

CLDR Ticket #10969(accepted)

Opened 9 months ago

Last modified 3 months ago

Food Calories

Reported by: Christoph Päper <christoph.paeper@…> Owned by: pedberg
Component: docs-spec Data Locale:
Phase: spec-beta Review:
Weeks: Data Xpath:
Xref:

ticket:11321

Description

It is true that in nutrition information and diets, calories are often still used even in otherwise fully metric countries, but in formal situations, kilojoules are always listed as well. I haven't seen alt="formal" yet, only alt="informal", thus I assume the following would be more appropriate as a default:

<unitPreferences category="energy" usage="food">
  <unitPreference regions="001">kilojoule</unitPreference>
  <unitPreference regions="001" alt="informal">foodcalorie</unitPreference>
  <unitPreference regions="US">foodcalorie</unitPreference>
</unitPreferences>

Attachments

Change History

comment:1 Changed 9 months ago by Christoph Päper <christoph.paeper@…>

PS: This probably applies to usage="person-usage" as well, although the unit there is kilocalorie (which is hardly ever distinguished from foodcalorie).

comment:2 Changed 5 months ago by pedberg

  • Owner changed from anybody to pedberg
  • Phase changed from dsub to rc
  • Priority changed from assess to medium
  • Status changed from new to accepted
  • Milestone changed from UNSCH to 34

comment:3 follow-up: ↓ 4 Changed 3 months ago by pedberg

  • Phase changed from rc to spec-beta
  • type changed from data to spec
  • Milestone changed from 34 to 35

Well, foodcalorie is not an an actual unit, it is a meta-unit; it is meant to mean "whatever unit is used for food energy". In some regions that will be kilocalories, in others it will be calories. This was created before we had the supplemental <unitPreferenceData> and was an attempt at handling that usage mapping for one particular kind of unit. In retrospect we should not have created foodcalorie and should have just created the <unitPreferenceData>. But since we have it, it really handles the <unitPreferenceData> mapping for the food energy category, so we don't need the extra preference structure above.

I will think about this a bit more, including how to document this issue.

comment:4 in reply to: ↑ 3 Changed 3 months ago by kent.karlsson14@…

Replying to pedberg:

Well, foodcalorie is not an an actual unit, it is a meta-unit;

I understand that that was your intention.

it is meant to mean "whatever unit is used for food energy".

No, you intended to cover kcal and the fictitious Cal; NOT "whatever unit is used for food energy", in particular kJ is not intended to be covered.

In some regions that will be kilocalories, in others it will be calories.

No, calories is too small a unit to be practical. Hence kcal is used instead, globally. That does go for all over the world, also USA, Canada and India. The "unit" Cal (with capital C) does NOT exist anywhere in the world. It is just that (confusingly) some countries (like USA, Canada, India) require food package labeling that says "Calories", AS A TITLE, instead of "Energy". The unit, however, is still kcal. But the unit is not always required to be written out. In many countries the units are required to be written out, usually both kcal and kJ are required on food package labels.

What in addition may confuse you, is that people tend to say/write calories, when meaning kilocalories. Put it down to "linguistic laziness" if you like. This does NOT depend on language, or region, and not even on what is required to be written on food packaging labels. As USDA puts it: "kcal kilocalorie (commonly known as calories)"; see www.ars.usda.gov/ARSUserFiles/80400525/Data/hg72/hg72_2002.pdf, page v. This holds globally, regardless of language, region, and what is required to be written on food packaging.

This was created before we had the supplemental <unitPreferenceData> and was an attempt at handling that usage mapping for one particular kind of unit. In retrospect we should not have created foodcalorie and should have just created the <unitPreferenceData>. But since we have it, it really handles the <unitPreferenceData> mapping for the food energy category, so we don't need the extra preference structure above.

That is not true. Both above suggested "remedies" are false since the premises are false. The actual case is as I explained it above. The only right thing to do is to purge everything related to "foodcalories" from CLDR. Both data (which is bogus, random, and useless), unit preference data (i.e. the bits that use "foodcalorie"), and DTD.

I will think about this a bit more, including how to document this issue.

Sorry, but this mistake cannot be documented away.

More details in ticket:11321.

comment:5 follow-up: ↓ 6 Changed 3 months ago by doug@…

People use the term “Calorie”, with or without the initial capital C, to mean kilocalorie. Using words like ‘bogus’ and ‘laziness’ and ‘mistake’ does not change this. The mistake is in proposing changes to CLDR for the purpose of trying to reform language usage in the real world.

comment:6 in reply to: ↑ 5 Changed 3 months ago by kent.karlsson14@…

Replying to doug@…:

People use the term “Calorie”, with or without the initial capital C, to mean kilocalorie.

I know. And I know perfectly well that that is impossible to "fix" in any language; so I have not suggested fixing that. As I said: "This holds globally, regardless of language, region, and what is required to be written on food packaging."

Using words like ‘bogus’ and ‘laziness’ and ‘mistake’ does not change this. The mistake is in proposing changes to CLDR for the purpose of trying to reform language usage in the real world.

Trying to use CLDR to introduce a unit that does not exist, never has exited and never will exist, is a great mistake.

It is still a factual error to say/write calorie when meaning kilocalorie, but it is a globally (and commonly) "executed" error, not locale dependent. For lack of better description, it can be put down to "linguistic laziness" (which also affect "kilo" for "kilogram" and a few others); use a better term if you have one.

"Foodcalorie" in CLDR is still entirely bogus, and the data "collected" is even more bogus and even random.

comment:7 Changed 3 months ago by kent.karlsson14@…

Not sure I want to put my name to this, since I don't really like it, but it is way better than the current situation. One could have:

 <unit type="energy-kilocalorie" alt="informal-and-incorrect-but-common-omission-of-kilo">

This would apply ONLY ONLY ONLY to the long form, NEVER EVER to the short/narrow forms.

At least that would reflect the actual state of affairs in the real world. One would still(!!) have to determine from context (somehow) if "calorie" really means "calorie" ("formal" context) or "kilocalorie" ("informal" context). But the current (otherwise very bogus!!!) approach has the same problem.

And also:

 <unit type="mass-kilogram" alt="informal-and-incorrect-but-common-omission-of-gram">
 <unit type="mass-hectogram" alt="informal-and-incorrect-but-common-omission-of-gram">

Again, ONLY ONLY ONLY for the long form, NEVER EVER to the short/narrow forms.

comment:8 Changed 3 months ago by srl

  • Xref set to 11321

comment:9 follow-up: ↓ 10 Changed 3 months ago by pedberg

We may want to deprecate foodcalorie and use the unitPreference mechanism instead. I am in the midst of some weeks of travel (and yes my hurried comment:4 used the wrong units), will consider when I return.

comment:10 in reply to: ↑ 9 Changed 3 months ago by kent.karlsson14@…

Replying to pedberg:

use the unitPreference mechanism instead.

As I mentioned, that approach is also VERY VERY WRONG.

comment:11 Changed 3 weeks ago by mark

  • Component changed from other-supplemental to docs-spec
View

Add a comment

Modify Ticket

Action
as accepted
Author


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

 
Note: See TracTickets for help on using tickets.