Improve DX of instance translation

I'm having the same problem...
I traced it back to the following code in commerce_price.module (around line 344):

        // Add the actual field value to the array.
        $components['commerce_price_formatted_amount'] = array(
          'title' => check_plain($instance['label']),
          'price' => $item,
          'weight' => $weight + 1,
        );

The $instance['label'] variable contains the original label instead of the translated one

This must have something to do with the field formatter, but can't quite figure out the flow at the moment...

Not sure if that's best practice though. This should probably work with a placeholder or something...

Hmm, it seems $instance['label'] should have been originally wrapped in t()... must be a missing link in the price component API somwhere. :?

I have a same problem. Subscribe.

I post a patch wrapping $instance in t() for ease of referencing from drush makefiles.

The commerce_order_total price field instance was created by calling the commerce_price_create_instance() function in commerce order module. The instance label passed to this field creation function was wrapped in t(). This means that the translation was performed when the field instance was created using the default language at that time and saved as the field instance label. Once the field was created, it is not possible to change the translation anymore.

I think the translation should be done during formatting instead of on field instance creation. This would allow translation to language that hasn't been added when the field instance was created and allow multi languages translations. Of course, the field instance label would then be saved as the default string instead of the translated string.

Yeah, n9353537 nails the problem. The issue is that this is the way fields are supposed to work, and you aren't supposed to wrap variables in t(). I'm not quite sure what the best thing for us to do would be... on the one hand, it might make sense to just employ a t() hack (i.e. use akamus' patch), but on the other it might be better to recommend a field translation module if a sufficient one exists.

Well, the API documentation page on t() says

You should never use t() to translate variables, such as calling

t($text);

, unless the text that the variable holds has been passed through t() elsewhere...

So, I guess it is okay to wrap the instance label with t()?

We removed the automatic translation of field instance label between Drupal 7.0 and 7.2. Now we need to figure out how to best integrate into the i10n module.

Subscribe

Fixed a patch from #6 so now it really gets applied by drush make.

Subscribe
hope it will fixed in RC1
i dont know how to apply patch so far

@witchcraft, just go to sites/all/modules/commerce of your drupal installation and run
patch < /path/to/commerce_order_total_translate.patch

Please apply fix :)

Patch in #6 is working great btw :)
Does anyone experience the problem that fields translations are not shown ? I mean the label translation works, but the content of the field is not shown translated.

Confirming patch #12 works as well...

See #8 / #10 for why I'm not committing this as is. If there's a way to do this through field translation, I'd prefer that. What we're dealing with is apparently a regression caused by Drupal core changes, so we shouldn't have to use t() in this way to translate our label.

We need something like this.

It will only work properly when the Field API will pass the requested language down to the formatter (which is the point of #1178500: hook_field_*() prepare/view have no access to the requested language). Until that core patch lands, it will just use the current interface language.

Subscribing.

subscribe

subscribe

Subscribe

Subscribe

same for the string Billing infromation ;)

waiting for CORE #1178500: hook_field_*() prepare/view have no access to the requested language

subscribe

subscribe

patch #12 looks good.

+++ b/commerce.moduleundefined
@@ -66,6 +66,25 @@ function commerce_info_fields($field_type, $entity_type = NULL) {
+  if (!isset($langcode)) {
+    global $language;
+    $langcode = isset($language->language) ? $language->language : 'en';
+  }

I think $GLOBALS['language_content'] should be used here.
Also 'en' should be changed to LANGUAGE_NONE

Issue (1) make no sense because of (2)
1 - #1178500: hook_field_*() prepare/view have no access to the requested language
2 - #1089174: Prepare view hooks do not receive the language parameter

Hi -

is there a solution yet to translate field labels? Or edit them? :) Need to translate "Order total" and "Shipping information" on the "order" bundle.

I guess this only is a problem if there is no translation when the fields are created, as some of the labels have translated labels.. but that is not always the case.

i18n seems overkill for single language sites (that is non-English).

Thanks :)

Atle

Marked #1463990: Some strings are not translatet as duplicate.

#32: Short update. Tried i18n field translation, and could not get it to work with Commerce. The labels did show up as translateable, but translations are not working when printed. Have not had the time to look into this any further.

I think this patches work for both translation problems.

The first translate "Order total" and the second one the "Shipping Information" and "Billing Information" problem.

It works for me.

New version.

Should also work without l18n.

Here is another patch for shipping and billing that is working. Didn't test this one.

@elmotri There are many ways to translate these strings

Now the order total patch should pass the test.

If you set the status to needs work, the patch won't be tested. See http://drupal.org/node/332678

I don't prefer one patch over another :) as long as it works

#35: commerce_price-translate-order-total.patch queued for re-testing.

@elmotri Thx for the link.

Every time we hit a field translation issue, some form of t($instance['label']) comes up - wrapping a variable in t(). However, as I always point out, that is an inappropriate use of the function. t() should only be used to wrap string literals per the documentation. We can definitely get the i18n support in if this is what we need to do to support it, though I was under the impression that was supposed to just work for some reason. : P

Patch works good, but says there is "trailing whitespace". Thanks!

This is not committable.

The last patches only use the t() function, if i18n isn't installed.

Right, but that's still inappropriate. t() should never be used to wrap variables, only string literals. In other words,

$output = t('Hello world');

is fine, but

$message = 'Hello world';
$output = t($message);

is not, even if it's just as a fallback for an actual solution.

Yes it's a bit quick and dirty, but i couldn't find a better way now.

I think we should look at why the field labels are not translated using i18n rather than "quick and dirty" fixes.

I have just had a chance to look at this briefly, but I seems like I was able to translate the field instance label, but not the field label since the field is locked. That is fine, but I suspec the field label is printed rather than the instance label since everything looks ok in the backend, but the untranslated label is still output to the screen.

A.

There is a fix for the strings "Billing information" and "Shipping information": #1451132: Translation issue "Billing information" + "Shipping information" (patch in #6)

The patch #37 works great for me.

#35: commerce_price-translate-order-total.patch queued for re-testing.

Nothing has changed since this was demoted to "needs work". See my comments above for the reasons why. The issue linked in #48 may provide us with a good solution here.

This should be sufficient.

#52: field-translate-1121722-52.patch queued for re-testing.

#52: field-translate-1121722-52.patch queued for re-testing.

Ahh, the problem was the Version was set to 1.2. : P

#52: field-translate-1121722-52.patch queued for re-testing.

Committing the quick fix here from #52. Worked fine for me translating that field to le français.

It does seem silly to keep adding calls to i18n_field() throughout our code, though, so I'm going to open a follow-up that evaluates replacing strings on an object-by-object basis per Damien's patch in #19. That would entail replacement for all calls to i18n_field() if possible.

Hi,

the problem still persists in commerce 7.x-1.3. Any ideas how to solve it?

Thanks in advance.

Cheers,

Victor

What's the reasoning with not directly committing #19? As far as I see it should have exactly the same effect: we use the current user interface language if we don't have a more specific language we can use.

D'oh, I'm guessing that by the time I circled back around to this I just didn't even notice your comprehensive patch from before. Rerolled and putting it up for testing.

i can confirm that all field instances could be translated both with or without the last patch (#64).
So the question is this patch it's really needed?
As i know the i18n Field translation should be able to do it for all type of fields, if the fields are defined right, no matter of entity type.

Maybe the solution search should related with Damien Tournoud #10 comment.
imho it's about how the LOCKED Commerce fields could be localized in a non-multilingual drupal, in other language than english.
could be this a Drupal core field locale issue?

I guess the idea behind the patch in #64 (which I'm reclassifying as a feature request since the bugs themselves have been fixed) is that we could translate a product earlier in the call stack so we don't have to put all these calls to i18n_field throughout our code. If we were going to go with this, though, I suppose we'd need to update the patch to remove all those calls to i18n_field and then test to make sure translation was still possible. I haven't actually reviewed the patch, just put it through test bot.

#64 patch not work

I had the same issue all the way. And i have found the solution for translating "field:commerce_order_total:commerce_order:label".

It's a bad config for your localization:

• Goto /admin/config/regional/i18n/strings
• Choose english as source language
• Save
• Translate the field once again
• Be happy

I hope this will help you all.

btw: I have #64 installed.

Greetings
hamu

We still do need #64. What happens is that i18n_fields automatically translate field and instance data (label, description, allowed values, etc.), but can only do so in context it controls. When we use this data in other contexts (like the ones targeted by this patch: error messages, etc.), we do need to perform the translation manually.

hamuchen (#68) you're right, but after that (translate the field once again) I have to restore the source language on my native site language (not english) and so translated labels doesn't work anymore!
This trick works only if I could mantain language source english "forever" (but obviosuly on many sites this is just not possible).

In the past I used #6 as a workaround. Can someone explain the current situation? Do I need to enable i18n to translate 'Order total' into russian?

Thanks for working on this guys.
i am not a programer but i have tried the patch in #64 using mac osx terminal and get this error:

can't find file to patch at input line 49
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/modules/customer/includes/commerce_customer.checkout_pane.inc b/modules/customer/includes/commerce_customer.checkout_pane.inc
|index eebdcc0..9c34c9e 100644
|--- a/modules/customer/includes/commerce_customer.checkout_pane.inc
|+++ b/modules/customer/includes/commerce_customer.checkout_pane.inc

anyone can help with this?
any updates at all for this issue?

Thanks

@odizle, try:

patch -p1 < 1121722-64-instance-field-translation.patch

thanks @brunorios1,and sorry for the late reply. I think I did manage to apply the patch using the command you have written, but after uploading the patched module to the server, the site did not i got an error :
Fatal error: Cannot redeclare commerce_object_translate() (previously declared in /home/evelon/domains/evelon.co.il/public_html/sites/all/modules/commerce 3/commerce.module:117) in /home/evelon/domains/evelon.co.il/public_html/sites/all/modules/commerce 3/commerce.module on line 147

#6 Translated Order Total for me.

Thanks for the feedback, but as I've mentioned at least a half dozen times above, we can only use t() to wrap string literals. You can feel free to use that patch on your own site if you want, just remember to re-apply it when you update versions of Commerce.

Is there a solution to use commerce in only one language (not english) without enable i18n modules ?

Raphael Apard: solution #6 work fine

thx. I'm currently using this code :

/**
 *  Implements hook_themet_commerce_price_formatteed_components().
 *  Fix Order total for drupal commerce.
 */
function MY_THEME_commerce_price_formatted_components($vars) {
  $vars['components']['commerce_price_formatted_amount']['title'] = t('Order total');
  return theme_commerce_price_formatted_components($vars);
}

#35: commerce_customer-translate-shipping-billing-information.patch queued for re-testing.

Hi, http://drupal.org/node/1451132#comment-5984944 maybe?
greetings, Martijn

solution #6 work for me. THANKS.

http://drupal.org/node/1121722#comment-4593864

helped me

Why this is not in stable downloaded module?

I did it. Brutally.
What gives the label to the Order total in Cart is the field label: the label of 'Order total' field in the Order settings (config/order/fields). I changed the label of Shipping Information and Billing information and I got them translated on Cart, but I couldn't since Order total field is locked by default.
So, I went to the db. I unlocked the field (changing 1 to 0 in the right field in the drup_field_config table). I came back to that admin page and I could edit the field. I change the label and then I LOCKED BACK AGAIN the field (1 -> 0).

I do not recommend to anyone who doesn't know what he's doing. But I solved while I'm waiting a clean solution.

Okay it's been like over a year and this seems to be the only item that isn't translated can we roll this into the next release PLEASE with sugar on top??

My suggestion is: take a look to the views those have been installed by commerce module!

Nope. All the words in any View doesn't apply. I tried translating in any View.

@rszrama, I think you should add this code to your patch:

http://drupal.org/node/1776644#comment-7372464

Infact, your patch doesn't translate "Order total" label in order's page. Thank you!

Order total is translatable right now (make sure you have i18n_string and i18n_field installed, you won't get anywhere in D7 translating without them).
This issue is just about code cleanup (and I will be rerolling the patch ASAP).

EDIT: Patch needed quite a bit of work. Posting it tomorrow.

Retitling for clarity.
Everything changed since the previous patch was written, I had to start from scratch.
This follows the i18n pattern of returning the translation from the function, instead of modifying the object that's being translated by reference.

I am unsure about this part:

     $checkout_panes['customer_profile_' . $type] = array(
-      'title' => !empty($instance['label']) ? $instance['label'] : $profile_type['name'],
+      'title' => !empty($instance['label']) ? $translated_instance['label'] : $profile_type['name'],

Isn't $instance['label'] always non-empty? Can we just replace that whole line with $translated_instance['label']?

Have applied patch #92, no error, but still getting "Order total" in my french site... but I'm still at 7.x-1.5 version, so that may be the cause...

Then you might need to update. : )

Leaving this at 7.x-1.x-dev; the test bot needs to know wish version we're working with in case there are future updates to the patch.

Sorry !! i didn't realise I've changed the status of the post...
Thanks for your patience, I'am a newbie when it comes to posting replies in issues, but now I understand !

Hope this the correct thread since a bunch of other threads point to this one.

I have a couple content types that use the price field.

#92 applies cleanly against 7.x-1.7, but my translated price field label translation isn't working for node add/edit form.
The translations are working for the node view. The rest of my site is translated properly.

Also anyone know how to translate currency codes?

#2015797: [meta] Make Commerce fully translatable is the place for generic questions like those.
For instance, it lists the i18n patch you need in order to translate the price label on the node add / edit form.

Honestly, my hunch is that we don't need that tertiary operator there, but amateescu added it on purpose when it first went in, so I can only imagine he encountered a scenario where the label was not set for some reason. If not, it's harmless cruft.

Committing #92 as is; sorry it took me so long to get to.

fwiw, I was able to translate the price field as expected, and you probably shouldn't be translating currency codes. If you really need to, you can create your own language specific currency info cache.

Hi,

it is marked as fixed, but still doesn't work with last dev version. Is there some patch to apply on ?

It works - I've tested it. : D

Please describe what it is you can't actually accomplish. Remember that you need to clear your cache and refresh your strings to see the new interface text translation possibilities.

What do you mean by "refresh your strings" ?

I've updated the module to dev version, clear caches, translated "Order total" to "Total de la commande" (which appears correctly in Views UI), but still on checkout rendering I can read "Order total".

I had no issue translating it, so I'm not sure. Perhaps you have other configuration to do? Is the language being detected properly, for example?

Well every other string are translated correctly. But this one, I've never succeeded in translating it.

I'll try on a fresh install and report the result.

This is a confusing subject if you run in to it the first time, so I'll add a little explanation. Please correct if needed.

1. Download and install the Internationalization module. If you use Commerce Kickstart you don't have to, it's already added to the distribution
2. Enable the Variable translation and String translation sub-modules.
3. Set Commerce Order Message as translatable at admin/config/regional/i18n/strings. Set the source language to English (is this needed?)
4. Update Interface translation at the Refresh Strings tab of the Interface translation (admin/config/regional/translate/i18n_string). Make sure to select Drupal Commerce as Textgroup.
5. Clear the cache
6. Now you can go to the translate tab (admin/config/regional/translate/translate) and find the Order total text. You should now be able to translate it.

@Argus, can you check the list you give :

• admin/config/regional/i18n/strings doesn't list translatable strings
• admin/config/regional/translate/i18n_string does list "Drupal Commerce" translatable strings group

I've followed what you've said, and now "Order total" is translated as "Adresse de Facturation" (which is the translation of "Shipping address").

@tahiticlic: Here is an image of what I was pointing at. Did you use that?

admin/config/regional/i18n/strings

Nope, what I can see is the attached screen.

What versions do you use ? I've downloaded the last dev version of Commerce(7.x-1.8+1-dev) and the last version of Internationalization (7.x-1.9)

[Edit] my question is maybe silly, but why is this so complicated to translate those strings ? Why don't we use the standard 't' function process ?

I'm using the versions in Commerce Kickstart, which are Commerce 7.x-1.8 and Internationalization 7.x-1.9.

Perhaps you have to manually add Commerce Order Message as a text format? Go to "admin/config/content/formats". I cannot find where this text format is applied to the Order Total though. Perhaps you could try to select all text formats in that screen (admin/config/regional/i18n/strings).

These are not normal strings but variables used in the code, that's why they cannot be translated easily. Read the above discussion to learn more about it.

solution #6 work for me. THANKS.

Hi Thanks,

#6 also solved my problem

#6 wrok for me too!!

that solved my problem

#6 solved issue.

Workaround without patching:

/**
 * Implements hook_commerce_price_formatted_components_alter().
 */
function MYMODULE_commerce_price_formatted_components_alter(&$components, $price, $entity) {
  foreach ($components as &$component) {
    $component['title'] = t($component['title']);
  }
}

Thanks to a.milkovsky (#114). I always should install this module from the start together with commerce ;-)

Thanks a.milkovsky (#114),

easy fix and works great for me too and now I don't always have to patch de core Commerce files again!

Solution #86 works for me (for the label "Order total")
Thanks.

Solution #114 worj fine, thx...

Hi all,
sorry about the dumb question...but where should i place the code (Solution #114)?

you main to writing a new module and add this code?

Thanks :)

OK, never mind
i based on solution #6 with a little bit changes :)
now its working
thanks

i replaced the row: 'title' => check_plain($translated_instance['label']),
(this row is little bit different from the one in #6 probably because the different versions)

with this: 'title' => check_plain(t($instance['label'])),

works for me

#114 worked for me (after translating the text with the tranlation interface), but i don't know if it is the best solutuion.
Regards