metric to non-metric conversion?

I think everyone agrees the measurements are shortsighted and a hinderence to the translation efforts as well as the user experience.

It is not clear how this should be done in the current codebase. That makes it less appealing to just code up and see what people think.
I would think you mean on-the-fly data conversion, but you might mean something else.

My ideal would be to handle *all* units in a standard metric form, and convert for the user when things are displayed... like we do for time and date, currency, etc.
Conversion will introduce rounding errors - this could be solved similar to the fractions/decimal conversion.. but you can't cover every possible case (there will still be some .998 or similar ugly conversions)

So, a future path could be:
1) Recipes are stored and retrieved as standard metric.
2) The units database table gets stripped down to metric, GREATLY simplifying translations... ("teaspoon" is a meaningless measurement in most of the world, even if you translate the term).
3) Entry UI uses user locale (Americans see "pounds, ounces etc.", most of the rest of the world gets Metric). User pref decided by their browser's preferred locale, with a link option to override this (just like many sites handle language)...
4) Conversion occurs at the last moment before display
5) Display UI uses user locale (Americans see "pounds, ounces etc.", most of the rest of the world gets Metric). User pref decided by their browser's preferred locale, with a link option to override this (just like many sites handle language)...

This is how I'd do it if starting over.

In the current codebase, patches would need to support Data migration, to allow upgrading.
This could probably be broken up into pieces but it would still be very messy.

Again this is a lot of work, and I don't see anyone stepping up in the near term. Any motivated coders out there?
The right moment for this might be after D7, CCK Multifield and other new tools all of which might force a rewrite of Recipe anyways.

I have been looking around to find a solution for international recipes but it is not sufficient to just translate and convert units. There are 2 different ways of writing down recipes: Volume based and Weight based.
When e recipe is in volumes, measures like teaspoon, tablespoon and cup are used. When a recipe is weight based, Units like gram, ounce and pound are used. This can only be converted with a a database. A cup of flour does not have the same weight as a cup of sugar.

If all recipes must be convertible, the base has to be an ingredients database and that's not easy since there will be always ingredients missing so, while entering a recipe, users must be able to add new ingredients too. Probably to much to include in one module.

This is true.

It is difficult to automatically convert because of the weight/volume problem.

A cup of rice has a different weight to a cup of water.

The best way I could think of doing this would be to allow the user who enters the recipe an option to add metric or imperial equivalents - then to allow the switch between metric and imperial if all the secondary fields are completed.

But this is a bit clunky.

It's definitely important though - one of the first things I look for on recipe sites, being from Europe.

A good summary of conversions is here: http://www.jsward.com/cooking/conversion.shtml

Thanks, Joe

@#1:
IMO it is not necessary to force submitters to use metric values. What we should have in fact is the internal storage all set to metrics. Actually that would mean we just need the information Probably two db colums per ingredient would be enough: "amount" and "volume_or_mass". Before storing you would just convert the input value to grams or millilitres. You could even break it all down to an internal standard of 1 serving and let all other conversion be done on display, then looking for the closest unit (be it g, kg, t or lb. or oz or whatever). This would, by the way, solve another common problem in recipe systems which is nonsense values like 56000g salt if you convert a recipe from 1 to e.g. 2000 servings, as the module would "think": "56000g is 5 digits and no decimals while 56kg is just two with still no decimals: let's display kgs!" Such a rewrite woud take this module beyond all other systems I am aware of.

Internally, for the salt example, the recipe_node_ingredient table would then look like:

id - nid - ingredient_id - weight - quantity - is_volume - note
123 - 45 - 67 - 3 - 28 - FALSE - (empty)

@#3:
Sorry to say this, but I disagree. Whatever you prepare can (and, for many reasons, should) be measured in masses right BECAUSE volume is no reliable measure while mass is. You can without any problem have 200g milk in a recipe - as long as you own a scales ;)
But this is, however, irrelevant for the topic anyway. You can convert imperial volumes to metric volumes just as you can do with masses. Also I do not see a data problem. Continuing the above thought, you would have a table like

id - unit_abbr - unit_singular - unit_plural - is_imperial - is_volume - conversion_factor
123 - kg - kilogram - kilograms - FALSE - FALSE - 1000
124 - oz - ounce - ounces - TRUE - FALSE - 28.35
125 - fl oz - fluid ounce - fluid ounces - TRUE - TRUE - 28.4131

@all
Taking it to that point, another option comes along: Users could add their own measures to the table and even delete all of them; even if they'd delete all entries, there would still be the internal basic measures "g" (for mass) and "ml" (for volume) which would always serve as a fallback to display any recipe, albeit the result might look a bit strange.

OK, once changing these basics, a third type could be added to "mass" and "volume", which is "descriptive" and would be fine for examples like "water (enough to cover all the rice)". But seriously, no one needs these obsolete granny-style non-measures like "teaspoons" or whatever. Internet users of the 21st century should be really considered able to find *some* nameable mass or volume equivalent for all of these. (Full stop!)

All that said, this would be some fundamental change. While it seems hard to find someone within some years now, I would take it. However this couldn't be done without generally revising some basic logics in the module. But, no effort, no benefit. Probably it would be a good idea to start a 7.x-2.x branch with these changes unless we find a way to transform almost all existing data (that is defining a "teaspoon" with, say, 2ml). Or even if we do. Anyway, sometimes you have to break with obsolete concepts (no offense and, btw, this is what Drupal core does with every major release).

TL; DR: I'll stand by. Just notify.

(I felt free to set this against the latest 7.x tag. Implementing such drastic changes is IMO really not an option for D6 which has almost had its days yet.)

What about the Units API?

https://drupal.org/project/unitsapi

Has that not done a lot of the tricky conversion stuff already? I see they have cups and teaspoons listed.

Thanks, Joe

Units API sounds just perfect. Could one of the maintainers state if there is an interest in patches adding this functionality?

No, don't bother. Development of 7.x-2.x will begin soon. I'll be considering this for inclusion, but a lot will change and there's no point in trying to write patches for the existing code base.

Ok, good to know. Thx. Is there any chance to learn more about your mid-term roadmap?

Issues will be posted for discussion of proposed changes or existing issues, like this one, will have their branch changed to 7.x-2.x. I've considered posting a meta-issue for discussion of the overall upgrade roadmap. I have most of this coming week off from work, so I'll probably create the new branch while I have the free time.

Great. So, risking repetition: If it comes to a point where you need a hand, just say so :)

I'm against requiring the db format to be only metric. I think each site should be able to declare it's native format. Then whether we need an output tool which converts to the other units (like recipe scaling) and an input tool that allows data entry in the alternate units are two other separate issues. There is a lot of goodness in storing exact values rather than always rounding (ie 4.92892 ml showing as 1 tsp).

@#12 while your argument (rounding) is truly valid, I would see more problems in arbitrary units simply because internal handling would become a lot more difficult. At least that's what I guess. If, on the other hand, units API is suitable, this could be no longer a problem.

Either way there will remain another unsolved issue. What about downscaling? Imagine a beer recipe (that's what I deal with). While a single homebrewer may deal with batches of 20l and below, a medium size crafts brewery my have batches some hundred times as big. Thus, a recipe based on 10l, will require e.g. 1200g of a certain malt type, resulting in ridiculous display values like 360000g etc. which should render as (in that cas) 360kgs. (Or vice versa, 50kgs would end up in 0.1556 kgs and so on.)

This is of course not limited to beer at all, but rather applies to any recipe except e.g. cocktails and cakes. TL;DR: Regardless of which internal conversion will be used, a way to deal with this should be included from scratch.

What you say is all true. My design idea would be:

Store native units in the db.
Show native units by default when viewed.
Allow user to scale up/down in view.
Allow user to convert units in view.
Allow user to enter native units on save.
Allow user to enter alternate units which convert to native on save.

I get the point about scaling up/down where you want the measure to change as well as the unit.
And yes I truly believe metrics are way easier to deal with. It is just a complicated issue that needs thinking about:)
I just don't like the idea of taking the actual recipe and messing with it when storing in the database. Funny you should mention beer recipes. That is what I store in my recipe site. Should we add hop calcs and gravity measurements as well:) I didn't see your name: https://drupal.org/profile/profile_interest/brewing%20beer

Well, actually I am not really active anymore, at least at the moment and since a longer time. But still driving a beer site urgently needing for a fundamental Drupal update. But nice to know there are other fellows around here ;-)

Anyway, we will have to wait what the next big recipe changes will bring. In my D6 beer site, I had to do so many code hacks that it wouldn't be a joy to finally upgrade to D7 just for this particular module (although this applies to almost all contrib modules meanwhile...).

Addition, if we have a wishlist anyway ;-)

<wishlist>
Store in native units: fine.
Display in native units: fair. But better would be: Assign default unit systems to user profiles directly or via regional settings and use regional standards as a default.
</wishlist>

I'm not active anymore, but my comment would be:
Allow for input in US format units if the locale is en_us (or Burma, they still use it).
BUT... Store it in Metric.

Standardizing the backend means fewer "units" internally, and smarter recipe scale factors if you want to double the recipe, etc.
Storage standardization also means LESS CODE... plus then there's the oft-requested feature that the module support locales and translation (which it can do with common units and a common database of ingredients)

By default converting 1 of a unit to another type can lead to things like 1.54 of something, but sensible floor() and ceiling() calls can smooth it out.

Drupal's an International project, and besides: All US weights and measures are defined in metric (shocking to some, but Google it).

Interesting caveat: If you store metric units...

If 700 mL is stored in the database for a US facing site.
What are you going to show, 3 cups or 1-1/2 pints?

If you store metric how do you get back the original recipe?

950 mL is even more fun:)

My (long ago) fork of recipe does what jvandervort does: It stores the data in the entry format. The user has a preference for metric/English (SAE?) (or you could use GeoIP to get the country and from that the preferred unit of measure). If they didn't enter the recipe, it is reformatted as best as possible to the other standard. It is not-so-trivial to round metric to reasonable English amounts (and fractions thereof), as well as rounding English amounts to reasonable metric quantities. In fact, it might not be possible to do without knowing more about the type of recipe. For example, for a soup, you might round 33.37oz to a quart, but for making something more precise (maybe a candy syrup), you might round it to 33 oz.

And then there is the mass vs. volume confusion of ounces.

From my experience, for most recipes, it's clear when there has been a conversion. There is a lost of "beauty" in converted recipes. It's better than having to convert in your head, but as a US user, I would not want all my recipes rounded to metric storage and back for display.

Since Drupal 7 is now end-of-life I am closing some old issues for the 7.x branch of this module.