Support translatable Shipping labels for methods / services

Ahh, didn't realize you posted the same thing in the Shipping Flat Rate queue. Let's close that one as a duplicate and try to find a solution here. For reference, this was my comment there:

We're always open to solutions that don't abuse the API. I know there are modules out there for handling this sort of thing, but I don't have any experience with them. If you research them and recommend a solution, that will go a long way toward resolving the issue for everyone. : )

My hunch is there's some i18n module we can integrate with to solve this, but I don't have any experience with it.

Running t function on a variable is a no go.

One solution could be to use variable_get/set since you can translate those.

I wonder if http://drupal.org/project/variable might offer a solution, too. : ?

Storing it in a variable and using the variable module for translations is a viable solution.

I prefer using http://drupal.org/project/stringoverrides for its simplicity. All it does is add an UI for the $custom_strings variable that is used by t() (and has locale support). We can mimic what t() does and reuse this variable..

I don't have 1.x installed and headed for bed, so I'll just try to wing this one.. it would be something like:

  global $language;
  static $custom_strings;

  $langcode = (isset($language->language) ? $language->language : 'en');

  if (!isset($custom_strings[$langcode])) {
    $custom_strings[$langcode] = variable_get('locale_custom_strings_' . $langcode, array());
  }
  
  $shipping_label = $action->settings['shipping_method']['shipping_label'];
  if (isset($custom_strings[$langcode][''][$shipping_label])) {
    $shipping_label = $custom_strings[$langcode][''][$shipping_label];
  }
  $shipping_method['shipping_label'] = $shipping_label;

This would also work for sites without the locale module enabled... or even in settings.php. ;)

waddayathink? :)

Atle

Waiting for #1422996: localization and i18n integration in a stable release of Rules.

We can actually solve this issue now.

Hi, I would love to see this committed. Where do I need to set the code in http://drupal.org/node/1369696#comment-5382990 for the shortterm solution?
And any progress on this stable solution please?
greetings, Martijn

@googletorp: I am trying to find the place to fix this without success. Where could this be done?

I'm guessing this needs to be handled in the rules integration code. I don't really know what's needed since I haven't done this before and never got around to look at it.

Just fixed it in another module:

/**
 * Allows modules to alter the price component types defined by other modules.
 *
 * @param $component_types
 *   The array of price component types defined by enabled modules.
 */
function hook_commerce_price_component_type_info_alter(&$component_types) {
  $component_types['flat_rate_default_shipping_service']['display_title'] = t('Shipping');
}

Not really clean... But hey, it works :)

The issue here is the label when it's configured. So the idea is that you can enter your custom label in the rules interface but have it be translatable.

So this was not solved by #1422996: localization and i18n integration? Is this a rules issue?

Strange that something this basic is so hard to do.

I ended up solving it like this:

• Create one shipping method for each language
• Go to configure component and add the following condition for each one
  
  Data Comparison: Parameter: Data to compare: [site:current-page:language], Data value: *LANGUAGE*

Not sure if this is a proper way to do this, but it works and you don't have to make any code changes, so seems ok to me :)

I am confused why we can't actually run the labels through a proper i18n function. The rules bug that was apparently blocking this is closed?

I guess it would require defining the proper i18n info hook and each time a new shipping type was setup it would need to be added.

https://groups.drupal.org/node/152929

Thanks for working on this guys
I had to get this working for a client and used the following. Its a bit of a hack but the client is happy so it will do for now.

<?php
/**
 * Implementation of hook_form_alter().
 */
function MyModule_form_alter(&$form, &$form_state, $form_id) {
  if ($form_id == 'commerce_checkout_form_checkout') {
    // Hack the shipping rates so they are translatable.
    $shipping_rates = $form['commerce_shipping']['shipping_rates']['#value'];
    foreach ($shipping_rates as $key => $shipping_rate) {
      $form['commerce_shipping']['shipping_service']['#options'][$key] =  t($form['commerce_shipping']['shipping_service']['#options'][$key]);
    }
  }
}
?> 

the problem with the above is it only solves the issue on the selection form so in places like the shopping cart view it will show none translated shipping.
The code below solves this and is a better approach (although no replacement to sorting this issue)

<?php
/**
 * Implements hook_commerce_shipping_service_info_alter().
 *
 * This should be removed once https://drupal.org/node/1369696 is resolved.
 */
function mymodule_commerce_shipping_service_info_alter(&$shipping_services) {
  // Use t() to translate the shipping service display.
  foreach ($shipping_services as $name => &$shipping_service) {
   $shipping_service['display_title'] = t($shipping_service['display_title']);
  }
}
?>

#18 worked for me. Thank you.

#18 worked for me too ;) The patch doesn't apply to the actual dev version.

#18 worked for me.

You really shouldn't be calling the t() function on a $variable, especially when the value in that variable is a user entered one such as this. See the API docs for more info: https://api.drupal.org/api/drupal/includes%21bootstrap.inc/function/t/7

Hi @stella you are correct and that's why I described it as a hack. However I think that the security issue is mitigated by the fact that the user that has entered the text is an admin.
But yes +1 me for needs work :)

I recently tried to apply the solution in #18 but it never gets called in a custom module which is odd

For anyone needing this for drupal 8 and stumbling on this issue, the corresponding issue for d8 is https://www.drupal.org/project/commerce_shipping/issues/2934142