i18n: Translate measures

We don't translate variables or user entered data with t(). This patch need to wait for the big review patch...

Agreed, we don't translate database data with t(). You could, of course, just change the recipe_unit table to your language of choice by editing it directly, but it won't help you if you are looking for a multilingual site.

I think it would be good to mplement the feature, but in a differen way... Maybe with the unit module...

Not familiar with that one. Who's the author?

Also, there really isn't a translation interface for content.

http://drupal.org/taxonomy/term/97

Show's the extent of the problem. Everyone wants it, but there is no cohesive api for module developers.

recipe_unit names are stored in the database.. but does this fact turn them into "content", or is it really part of the software still?

I think we can do something more translation friendly than we do now. My thought was to:

1) move recipe_units.name into an array() held in an include file. Example:

$unit_names = array("Slice", "Unit", "Clove", "Pinch", "Package", ...);
$unit_abbreviation = array("sli", "", "clv", "pn", "pk", ...);

2) The array index would perfectly match recipe_units.id, like so:
| 1 | Slice | sli | 0 | Unit |
| 2 | Unit | | 0 | Unit |
| 3 | Clove | clv | 0 | Unit |
| 4 | Pinch | pn | 0 | Unit |
| 5 | Package | pk | 0 | Unit |
| 6 | Can | cn | 0 | Unit |
| 7 | Drop | dr | 0 | Unit |
| 8 | Bunch | bn | 0 | Unit |
| 9 | Dash
...

we could retain the recipe_units table, but really all we'd need from it is id, 'metric', and 'type'...

Is there any difficulty in this approach, or are there other ideas that might be less work?

@tzoscott, "but does this fact turn them into "content"?

Sort of yes. People can change them at their own will. Maybe a better word for it is user-entered data?
Can't count on it to _not_ change. Just like Drupal taxonomy.

The module itself is already treating units in the indirect fashion it needs to... as an id in table 'recipe'.
The module does not care what container "recipe name" and "recipe abbreviation" has been stored in.
The module treats names and abbreviations as strings, just like any other "fixed" strings in the software... except these particular strings are stored in the database.

I see a lot of Drupal contributions from people who can't code PHP, but who can generate .po files for other languages. Many of these contributors write translations for modules they never use, just for translation's sake.

I don't think any translation tools work against the database and if that is true, we make their l10n task more difficult or incomplete.
I want to make any translator's job less difficult, if there is something we can do for that...

Hass's profile marks him as a contributor of translations, so I would like to hear his viewpoint on this... as well as that of any other Drupal translator who feels like chiming in on how storing these strings in the database might affect a translation effort.

(But please cite any relevant Drupal documentation on the matter, since neither myself nor John contribute translations. A few URLs will help us understand the process better). Thanks.

http://drupal.org/project/units or http://drupal.org/project/unitsapi if i remember correctly. Uebercart also use it if i remember correcly.

The big benefit is a user could enter inches and you can calculate metric values and so on... This is not translation only - it requires calculation with factors. I have only implemented such calculations with currencies in past. Never implemented something else myself yet, but it cannot be solved In the right way by simply translating strings.

OK Hass but let's be clear.. I think those 2 links for for unit conversions right? We could look at something like these modules in another issue. What I'm trying to understand is if our storing the unit strings is somehow making life more difficult for the translators who contribute .po files.

Because .po files target line numbers in actual code files, I suspect the .po can never translate a database-contained string like our existing units..

Yes, POTX cannot extract strings from the database. Otherwise adding them into dummy code functions like date_timezone module does with the time zone names is really only a dirty workaround, but is no real good solution for the units in recipe as this is user entered data and we normally do not translate user entered data with t().

OK thanks.

It seems the most i18n compatible approach is to store unit names and unit abbreviations in an .include file. We don't have that many names, and I do not foresee any technical problem as a result of this. This would not be for 1.0 as that is just about ready for release.

For post 1.0, I'll also take a look at Units Module. I'm not sure that will work as a translation API or data store. It would be NICE if it were, to automatically gain translated unit names for all languages. Not sure about any of that...

Also do not forget that numbers and dates need to be formatted in different ways in different languages :-). In british english you often have a periods between thousands, where you don't have them in German. Values are also often written with comma and sometimes with periods e.g. EN: 12.5g - German 12,5g... this is also part of unit formatting :-). As said - it's not that easy... dates are much more funny...

Subscribing to this interesting topic
Alan

Found this thread as my son wants to use the recipe module and I am a little experienced with multilingual sites and translations.
We have to distinguish translation and units. The unit names must be translatable through the user interface, but units itself must be recalculated. I think, that's what the units module does (will have a look on it, later).
Unit names are similar to taxonomy terms. And if that infrastructure would have been used they could have been translated in the same manner (why not user taxonomy terms and a database table to enrich the taxonomy terms with additional attributes?).
To translate a unit's name you should be able to change e.g. "cup" into "Tasse", but not into "Löffel". The meaning of the underlying unit must be preserved. It means volume units must not be named into weight or pieces units and so on.

Just my two cents!

Sorry for posting this multiple. Hit save only once, but hit preview multiple. Don't know, what happened :(

Sorry again :((

I had todo something like this to get it work where people submit with for example "10,50" (comma)

First a hook form alter

   $form['#validate'][]='my_recipes_convert_form_submit_euro_values';

and then

function my_recipes_convert_form_submit_euro_values($form, &$form_state) {
  $id = 0;
  while( $form['ingredients'][$id] ) {
    // clean off the , (comma) because the DB wont like it, change it to a decimal point. (this assumes a lot!)
    $clean_value = str_replace(',', '.', $form['#post']['ingredients'][$id]['quantity']);
    form_set_value($form['ingredients'][$id]['quantity'], $clean_value, $form_state);
    $id++;
  }
}

hope it saves someone some time!

I am running a German site with Recipe. Since the site is monolingual, I simply altered the measures in the database, that's not my concern.
However, like dgtlmoon i need users to be able to enter measures with decimal commas.

Unfortunately his exact code doesn't work for me (Drupal 6.26 / Recipe 6.x-1.5+13-dev).
After some testing it seemed that the reason was only that the $form variable had a different structure in my case.
So I changed it, but it still doesn't work.

I am new to hook form alter, so it might just be a newbie mistake somewhere else, any help would be appreciated.

I made my own module and activated it.
The module source is a slight modification of dgtlmoon's version:

// $Id: recipe_addon.module

/**
* @file
* Custom functions for this site.
*/

$form['node-form']['#validate'][]='recipe_addon_form_alter';

function recipe_addon_form_alter($form, &$form_state) {
  $id = 0;
  while( $form['ingredients'][$id] )
  {
    // clean off the , (comma) because the DB wont like it, change it to a decimal point. (this assumes a lot!)
    $clean_value = str_replace(',', '.', $form['ingredients'][$id]['quantity']['#default_value']);
    form_set_value($form['ingredients'][$id]['quantity']['#default_value'], $clean_value, $form_state);
    $id++;
  }
}

$form['ingredients'][$id]['quantity']['#default_value'] contains the measures. I confirmed that with echo $clean_value
at some point (which also proved the module was executed).
However, the server simply doesn't respond after I submit the recipe as soon as I add the form_set_value() line.

I am a bit confused about the function names. dgtlmoon did not add _form_alter. And I read in some tutorials not to do that,
since it would "confuse" drupal.
If I rename my function though, it does not get executed at all (or so it seems).

Does anybody have an explanation?
Thank you in advance.

Closing old 6.x issues.

Has it fixed?

It's been fixed for D8, yes. Units are stored in configuration files so that they are both configurable and translatable.

Really? Numbers should not translated. They only need to be formatted. See #10 and around, please.

I'm talking about the unit strings, not numeric values.

That is the same like numbers. Units may be more fun as you may need to caculate pound (non-metric) to gramm (metric) and inces to cm and other stuff. This can be done easily with factors and makes it easy to have both and US site and a German time based on same data.

Re-closing this. The original subject of this issue was about unit translation, not unit conversion. Translation was solved in 8.x-2.x. There is another, older issue dealing with unit conversion, #365094: metric to non-metric conversion?.