It is currently not possible to translate the title and/or display title of the added flat rate shipping services. Ideally this is done with i18n string since this is dynamic data.

Comments

Status:Active» Needs review
StatusFileSize
new2.88 KB

Here's a first attempt that works for my current project.

I first tried to integrate this directly in commerce_shipping but that module expects the titles of the services to be translated within hook_commerce_shipping_service_info() since some module use t() to translate their title, eg. the shipping service example module.

This means that each module that uses dynamic strings for titles should implement its own i18n integration.

The patch allows the title and display_title to be translated.

The patch commerce_flat_rate_i18n.patch on #1 is perfect worked. But you need reload the shipping services flat rat page on Chinese version.

Category:feature» bug
Priority:Normal» Critical

After applying the patch I had an error, preventing it to use i18n.
A little change to the patch is required, adding a title to the object info

<?php
function commerce_flat_rate_i18n_object_info() {
 
$info['commerce_flat_rate'] = array(
   
'title' => t('Commerce flat rate'),
    ...
    ),
  );
  return
$info;
}
?>

The #3 worked perfectly. But I would extend it by the description-field:

<?php
function commerce_flat_rate_i18n_object_info() {
 
$info['commerce_flat_rate'] = array(
   
'title' => t('Commerce flat rate'),
   
'key' => 'name',
   
'class' => 'i18n_string_object_wrapper',
   
'string translation' => array(
     
'textgroup' => 'commerce_flat_rate',
     
'type' => 'name',
     
'properties' => array(
       
'title' => t('Title'),
       
'display_title' => t('Display title'),
       
'description' => t('Description'),
      ),
    ),
  );
  return
$info;
}
?>

Hope to see this in beta2 !!!

I took the patch from #1 and implemented the following changes on top:

- implement the two suggestions from #3 and #4 to add a title and to make the description translatable
- add a guard so translation only happens if i18n_string is active (I got a fatal error when i18n_string was not there, the existing guard (in the saving function) did not catch the case when the shipping data was *used*)
- add context to display title (disambiguation, there was a translation error on the German version of the edit form)
- implement hook_i18n_string_objects so refreshing of strings will work
(admin/config/regional/translate/i18n_string); before it would just report that the strings could not be refreshed.
- make sure the edit mode only uses the untranslated strings; this is important if you are using the shipping method edit form in a non-default language. Saving the translated values would overwrite your original ones.

Category:bug» feature
Priority:Critical» Normal

StatusFileSize
new2.73 KB
new5.32 KB

Here's a revised patch and interdiff.

+++ b/commerce_flat_rate.i18n.incundefined
@@ -12,7 +13,8 @@ function commerce_flat_rate_i18n_object_info() {
-        'display_title' => t('Display title'),
+        'display_title' => t('Display title', array(), array('context' => 'title for display purposes')),

I'm not sure why the context was added here. Can you explain, @cspitzlay? I've left this for now.

Summary of changes:

  1. commerce_flat_rate.i18n.inc: Added @file docblock and newline at EOF.
  2. Updated capitalization to "Commerce Flat Rate" where appropriate.
  3. Updated the description of the textgroup to indicate that it now contains description strings.
  4. Cleaned up the call to i18n_string_object_update() in commerce_flat_rate_service_form_submit(). I don't see the need for creating a new object here, and now the string will only get updated if the flat rate service saved successfully. The string update still lags a bit here (same as the patch from #5), it seems like you either need to save the shipping service twice or manually refresh the strings to get the new values. Haven't had a chance to debug that yet.

I'm not quite happy with the whole untranslated_strings bit that fixes the admin UI bug, but I'm not sure how else to implement that unless there's an i18n function we can use to get the untranslated string.

I added the context so this string can be translated independently from other uses of that source string.

"Display title" can either mean "to display a title" or "the title to be displayed".
In German, for example, these two would translate to "Titel anzeigen" and "Anzeige-Titel", respectively.
The former is Drupal's standard translation (the German one, at least), the latter meaning is what we need here.

@cspitzlay - Thanks.

See http://drupal.org/node/1534468 for more information about why the double encoding is happening. Internationalization's i18n_string() API changed in i18n 1.5.

Patch in #7 works fine. Thanks!

Status:Needs review» Reviewed & tested by the community

I have applied the patch in #7 and it appears to do what is required regarding translating the flat rate displayed title.

I think it should be committed.

StatusFileSize
new2.68 KB

#7 + fix for Notice: Undefined index: untranslated_strings

StatusFileSize
new5.78 KB

Sorry this one will work

Hi,

thanks for patch #14, it works for me.

I had to edit and save every shipping method to get the strings available at admin/config/regional/translate/translate

Thanks for the patch #14. This one works for me.

Thanks! This should be updated to dev version.

Issue summary:View changes

#14 worked for me too.