Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I've found that the labels (Price and Quantity) is not translatable.
I've fixed the problem in the attached patch.
Comment | File | Size | Author |
---|---|---|---|
commerce_price_table.patch | 925 bytes | klavs |
Comments
Comment #1
klavs CreditAttribution: klavs commentedin 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.
Comment #2
klavs CreditAttribution: klavs commentedit 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).
Comment #3
klavs CreditAttribution: klavs commentedI 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']);
Comment #4
rbosscher CreditAttribution: rbosscher commentedPatch worked for me, thanks.
Indeed the solution you propose is better, but it works for now :)
Comment #5
steve.m CreditAttribution: steve.m commentedI made the same patch for my install. It looks like adding t() and using string translation is the answer.