Hello,

I'm trying to translate the "Order total" string at the footer of the cart view on the checkout page, and for some strange reason I can't translate it/or the translation is not working.

I have translated a string "Order total" but it seems to have no effect there, it does change the label of the component in the view edit page, but that doesn't really help me.

Any ideas? this is the only string that I can't translate - where is the code originating? maybe there's a missing t() ?

Idan

Files: 
CommentFileSizeAuthor
#108 commerce.jpg42.28 KBFabien Crépin
#107 multilingual settings strings.png102.19 KBArgus
#92 1121722-91.instance-translation-dx.patch10.71 KBbojanz
PASSED: [[SimpleTest]]: [MySQL] 3,557 pass(es). View
#64 1121722-64-instance-field-translation.patch6.01 KBrszrama
PASSED: [[SimpleTest]]: [MySQL] 3,588 pass(es). View
#52 field-translate-1121722-52.patch1.14 KBhelior
PASSED: [[SimpleTest]]: [MySQL] 3,567 pass(es). View
#37 commerce_price-translate-order-total.patch894 bytessunfire-design
PASSED: [[SimpleTest]]: [MySQL] 3,553 pass(es). View
#35 commerce_price-translate-order-total.patch915 bytessunfire-design
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in commerce_price-translate-order-total_0.patch. View
#35 commerce_customer-translate-shipping-billing-information.patch1.04 KBsunfire-design
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch commerce_customer-translate-shipping-billing-information_0.patch. Unable to apply patch. See the log in the details link for more information. View
#33 commerce_price-translate-order-total.patch722 bytessunfire-design
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in commerce_price-translate-order-total.patch. View
#33 commerce_customer-translate-shipping-billing-information.patch829 bytessunfire-design
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in commerce_customer-translate-shipping-billing-information.patch. View
#19 1121722-instance-field-translation.patch6.23 KBDamien Tournoud
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1121722-instance-field-translation.patch. Unable to apply patch. See the log in the details link for more information. View
#12 commerce_order_total_translate.patch662 bytesakamaus
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch commerce_order_total_translate_0.patch. Unable to apply patch. See the log in the details link for more information. View
#6 commerce_order_total_translate.patch666 bytesakamaus
PASSED: [[SimpleTest]]: [MySQL] 3,553 pass(es). View

Comments

svendecabooter’s picture

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...

arbel’s picture

great find! Thanks.

I wrapped a t() around it:

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

and it worked right away with a previous translation.

Idan

svendecabooter’s picture

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

rszrama’s picture

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

v.zhakov’s picture

I have a same problem. Subscribe.

akamaus’s picture

Version: 7.x-1.0-beta2 » 7.x-1.0-beta4
Component: Cart » Price
FileSize
666 bytes
PASSED: [[SimpleTest]]: [MySQL] 3,553 pass(es). View

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

n9352527’s picture

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.

rszrama’s picture

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.

n9352527’s picture

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()?

Damien Tournoud’s picture

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.

khiminrm’s picture

Subscribe

akamaus’s picture

FileSize
662 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch commerce_order_total_translate_0.patch. Unable to apply patch. See the log in the details link for more information. View

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

witchcraft’s picture

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

akamaus’s picture

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

JGO’s picture

Please apply fix :)

JGO’s picture

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.

guillaumev’s picture

Status: Active » Reviewed & tested by the community

Confirming patch #12 works as well...

rszrama’s picture

Status: Reviewed & tested by the community » Active

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.

Damien Tournoud’s picture

Version: 7.x-1.0-beta4 » 7.x-1.x-dev
Status: Active » Needs review
FileSize
6.23 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1121722-instance-field-translation.patch. Unable to apply patch. See the log in the details link for more information. View

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.

tormi’s picture

Subscribing.

ducecc’s picture

subscribe

City-busz’s picture

subscribe

gagoo’s picture

Subscribe

Cookiz’s picture

Subscribe

ytsurk’s picture

same for the string Billing infromation ;)

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

brunorios1’s picture

subscribe

vasike’s picture

subscribe

amfis’s picture

patch #12 looks good.

andypost’s picture

Status: Needs review » Needs work
+++ 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

atlea’s picture

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

mr.baileys’s picture

atlea’s picture

#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.

sunfire-design’s picture

Version: 7.x-1.x-dev » 7.x-1.2
Status: Needs work » Needs review
FileSize
829 bytes
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in commerce_customer-translate-shipping-billing-information.patch. View
722 bytes
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in commerce_price-translate-order-total.patch. View

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.

Status: Needs review » Needs work

The last submitted patch, commerce_customer-translate-shipping-billing-information.patch, failed testing.

sunfire-design’s picture

FileSize
1.04 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch commerce_customer-translate-shipping-billing-information_0.patch. Unable to apply patch. See the log in the details link for more information. View
915 bytes
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in commerce_price-translate-order-total_0.patch. View

New version.

Should also work without l18n.

elmotri’s picture

Status: Needs work » Needs review

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

sunfire-design’s picture

Status: Needs review » Needs work
FileSize
894 bytes
PASSED: [[SimpleTest]]: [MySQL] 3,553 pass(es). View

@elmotri There are many ways to translate these strings

Now the order total patch should pass the test.

elmotri’s picture

Status: Needs work » Needs review

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

sunfire-design’s picture

sunfire-design’s picture

@elmotri Thx for the link.

rszrama’s picture

Status: Needs review » Needs work

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

TipiT’s picture

Status: Needs work » Reviewed & tested by the community

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

bojanz’s picture

Status: Reviewed & tested by the community » Needs work

This is not committable.

sunfire-design’s picture

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

rszrama’s picture

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.

sunfire-design’s picture

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

atlea’s picture

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.

no2e’s picture

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

tregismoreira’s picture

The patch #37 works great for me.

samuel.pismel’s picture

Status: Needs work » Needs review
rszrama’s picture

Status: Needs review » Needs work

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.

helior’s picture

Status: Needs work » Needs review
FileSize
1.14 KB
PASSED: [[SimpleTest]]: [MySQL] 3,567 pass(es). View

This should be sufficient.

Status: Needs review » Needs work

The last submitted patch, field-translate-1121722-52.patch, failed testing.

helior’s picture

Status: Needs work » Needs review

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

Status: Needs review » Needs work

The last submitted patch, field-translate-1121722-52.patch, failed testing.

rszrama’s picture

Status: Needs work » Needs review

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

Status: Needs review » Needs work

The last submitted patch, field-translate-1121722-52.patch, failed testing.

rszrama’s picture

Version: 7.x-1.2 » 7.x-1.x-dev
Status: Needs work » Needs review

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

rszrama’s picture

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

rszrama’s picture

Status: Needs review » Fixed

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.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

dornea.nu’s picture

Version: 7.x-1.x-dev » 7.x-1.3

Hi,

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

Thanks in advance.

Cheers,

Victor

Damien Tournoud’s picture

Status: Closed (fixed) » Needs review

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.

rszrama’s picture

Title: Can't translate string "Order total" » Translate all field instances on an entity at once through i18n_object_wrapper::translate()
Version: 7.x-1.3 » 7.x-1.x-dev
Component: Price » Internationalization
FileSize
6.01 KB
PASSED: [[SimpleTest]]: [MySQL] 3,588 pass(es). View

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.

vasike’s picture

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?

rszrama’s picture

Category: bug » feature
Status: Needs review » Needs work

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.

garegin1987’s picture

#64 patch not work

hamuchen’s picture

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

Damien Tournoud’s picture

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.

SaxxIng’s picture

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).

akamaus’s picture

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?

odizle’s picture

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

brunorios1’s picture

@odizle, try:

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

odizle’s picture

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

ram4nd’s picture

#6 Translated Order Total for me.

rszrama’s picture

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.

Raphael Apard’s picture

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

gynekolog’s picture

Raphael Apard: solution #6 work fine

Raphael Apard’s picture

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);
}
geemark’s picture

Status: Needs work » Needs review
star26bsd’s picture

I'm lost. #6 is considered wrong, got it. #64 is considered unfinished ("we'd need to update the patch to remove all those calls to i18n_field"). #79 doesn't work for me. Can someone provide a clue stick to those who need to put a multilingual shop into production and can't use English as a source language, please?

Thanks a lot!

Summit’s picture

laraz’s picture

solution #6 work for me. THANKS.

a.milkovsky’s picture

Prague man’s picture

Why this is not in stable downloaded module?

giuvax’s picture

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.

ShaneOnABike’s picture

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??

gianfrasoft’s picture

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

giuvax’s picture

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

gianfrasoft’s picture

@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!

bojanz’s picture

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.

bojanz’s picture

Title: Translate all field instances on an entity at once through i18n_object_wrapper::translate() » Improve DX of instance translation
Category: feature » task
FileSize
10.71 KB
PASSED: [[SimpleTest]]: [MySQL] 3,557 pass(es). View

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']?

Clauce’s picture

Version: 7.x-1.x-dev » 7.x-1.5

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...

rszrama’s picture

Version: 7.x-1.5 » 7.x-1.x-dev

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.

Clauce’s picture

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 !

webdrips’s picture

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?

bojanz’s picture

#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.

rszrama’s picture

Status: Needs review » Fixed

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.

Fabien Crépin’s picture

Hi,

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

rszrama’s picture

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.

Fabien Crépin’s picture

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".

rszrama’s picture

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?

Fabien Crépin’s picture

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.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Argus’s picture

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.
Fabien Crépin’s picture

@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").

Argus’s picture

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

admin/config/regional/i18n/strings

multiligual settings strings

Fabien Crépin’s picture

FileSize
42.28 KB

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 ?

Argus’s picture

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.

toufichalwani’s picture

solution #6 work for me. THANKS.

maxplus’s picture

Hi Thanks,

#6 also solved my problem

ssoulless’s picture

Issue summary: View changes

#6 wrok for me too!!

that solved my problem

Paul89’s picture

#6 solved issue.

a.milkovsky’s picture

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']);
  }
}
4kant’s picture

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

maxplus’s picture

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!

maragones’s picture

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

psf_’s picture

Solution #114 worj fine, thx...

rolok’s picture

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 :)

rolok’s picture

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

marco.falconi’s picture

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