I've found that the labels (Price and Quantity) is not translatable.

I've fixed the problem in the attached patch.

CommentFileSizeAuthor
commerce_price_table.patch925 bytesklavs
Members fund testing for the Drupal project. Drupal Association Learn more

Comments

klavs’s picture

in drupal 6, translation of user entered strings was handled with the tt() function, but I don't know what one is suppose to do in drupal 7 (yet :)

using t() as I've done in the patch, will mean that every time the user changes the label - it will result in a new string, which then will need to be retranslated - and the old string will be left in the database.

the tt() module did the right thing - as you assigned a label to the string - like $modulename::pricelabel - it would ensure the above problems were solved.

klavs’s picture

it seems using the i18n submodule - "strings translation" is how it should be done.

unfortunately it's not possible (AFAIK) to remove the settings::quantity_label (or price_label) field - which means the original (and translatable through t()) text 'Quantity' will never actually be used.

Here's how it's supposed to be done in Drupal 7 it seems.
http://drupal.org/node/1114010

I'm uncertain if those labels should be registered as Multilingual variables or if how it should be done, if it's just a "strings translation"..

will see if I can find an example of a module using it. It looks a lot more difficult to do, than it ought to be (if not using variables module).

klavs’s picture

I took at look at how custom_search had done it.. they've created an entire submodule for i18n. Seems a bit excessive :(

I was thinking the call could be something like:
if (function_exists(i18n_string_translate)
i18n_string_translate('commerce_price_table:label:price:',$display['settings']['quantity_label'], t('Quantity'))
else
..

And then there needs to be called an update for the string, if the value is changed. I can't seem to find any function responsible for handling updates - so it is appearently handled by core/commerce ?

I suppose there's a function one can implement to handle the saving of the variable - and in that, do:
if (function_exists(i18n_string_update)
i18n_string_update('commerce_price_table:label:price', $form_state['values']['price_table_price_label']);

rbosscher’s picture

Patch worked for me, thanks.
Indeed the solution you propose is better, but it works for now :)

steve.m’s picture

I made the same patch for my install. It looks like adding t() and using string translation is the answer.