Posted by tracerhand on January 27, 2009 at 6:22pm
Jump to:
| Project: | Recipe |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
This was discussed three years ago and the conversation never went anywhere.
I see the conversion button residing in the summary table, just after the Yield row. The left column would say "Measuring system" and the right column would contain a submit button whose text said either "Convert to Metric" or "Convert to Imperial", depending on the current state of the module. The ingredients list would change much as it does now when the Yield table is used.
A lingering problem, however, would be that the temperature most often resides as plaintext in the Instructions field.
Comments
#1
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.
#2