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
Support from Acquia helps fund testing for Drupal Acquia logo

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.