the messages in checkout and completion of order configured in
admin/store/settings/checkout/edit/messages

get an entry and can be translated in
admin/build/translate/search

but the language specific messages never get displayed.
Always the default english messages get displayed

some t() calls are missing from
sites/all/modules/ubercart/uc_cart/uc_cart.pages.inc
and
sites/all/modules/ubercart/uc_cart/uc_cart.module

this patch hopefully fixes this issue

WARNING: patch not thoroughly tested for all messages, please test and report back

CommentFileSizeAuthor
uc_checkout_messages_translation.patch3.05 KBgiorgosk

Comments

univate’s picture

Having t() around variable_get() doesn't seem right to me and reminds me of this issue #540716: Overuse of variables table

rszrama’s picture

Status: Needs review » Closed (duplicate)

@GiorgosK, have you used the i18n module and/or Lyle's recently committed patch to add support to that for multi-lingual variables in Ubercart? t() actually isn't supposed to use anything for the first argument besides a string literal, so we can't put a function call in there.

rszrama’s picture

giorgosk’s picture

I did not know I was not supposed to use t() like this
I am going to try the latest dev version and see if it fixes this issue

Militopedia’s picture

Hello Giorgios,

Were you ever able to solve this? I am having the same problem, but don't know what to do.

Regards
Roger

giorgosk’s picture

I have used the

$conf['i18n_variables'] = array(
 'site_name',
 'site_slogan',
 'site_mission',
 'site_footer',

 'anonymous',
 'menu_primary_menu',
 'menu_secondary_menu',

  'contact_form_information',
  'site_frontpage',
  'page_title_front',

  'uc_teaser_add_to_cart_text',
  'uc_product_add_to_cart_text',
  'uc_cod_policy',
  'uc_alpha_deltapay_method_title',
  'uc_checkout_review_instructions',
  'uc_checkout_instructions',
  'uc_msg_order_submit',
  'uc_msg_order_logged_in',
  'uc_msg_order_existing_user',
  'uc_msg_order_new_user',
  'uc_msg_continue_shopping',

);

In my settings.php

To include more variables you will have to inspect the id of the textarea that they occupy (take away the edit)
edit-uc-msg-order-submit becomes uc_msg_order_submit

After that the description of the textarea should read This is a multilingual variable.
and you can translate the textarea by viewing the page in the second language

en/admin/store/settings/checkout/edit/messages
to
es/admin/store/settings/checkout/edit/messages

Militopedia’s picture

Hello Giorgios,

Thanks a lot for your help and for taking the time to reply!! That solved the problem :-D

Cheers,
Roger

hosais’s picture

Thank you very much, GiorgosK. This works for me perfectly.

hosais

heyyo’s picture

Version: 6.x-2.0-rc6 » 6.x-2.4

Doesn't work anymore in 6.x-2.4, even if it is written multilingual variable, only the last translation posted is kept.
It was working correctly in 6.x-2.2. Is it handled differently ?

heyyo’s picture

Status: Closed (duplicate) » Active
YK85’s picture

subscribing

heyyo’s picture

I don't have this bug anymore with internationalization 6.x-1.6 http://drupal.org/node/902742

tr’s picture

Status: Active » Closed (fixed)
janton’s picture

Status: Closed (fixed) » Active

i still have this problem.. i have i18n 6.x-1.8..

But i think i caused the problem but i don't know how to fix it or how it works.
For example i changed something in /admin/store/settings/checkout/edit/messages

Checkout review instructions:
Your order is almost complete. Please review the details below and click 'Submit order' if all the information is correct. You may use the 'Back' button to make changes to your order if necessary. HEEEEEREEEEE SOME EXTRA TEXT

i added 1 line there.. now i went to
admin/build/translate/refresh/
Refreshed all:
Select text groups:
Blocks
CCK
Content type
Menu
Profile
Terms of Use
Taxonomy

Then i went to:
/admin/build/translate/edit/
searched for: Your order is almost complete.

Now i only see the old Checkout review instructions without the extra text?
I translated that one to see if i get any results... but the text is not translated when i should see that massage!
Also i tried to change it back, so i deleted the new text and only kept the old text, but still no translation?

What am i doing wrong? it looks like Refresh does not refresh Ubercard checkout message? and now it even won't translate the old message...

longwave’s picture

Status: Active » Closed (fixed)

You don't translate these messages at /admin/build/translate/edit

Instead, switch the language directly on the /admin/store/settings/checkout/edit/messages page and save changes there for each language.

janton’s picture

Yes thx i found this out after a few weeks... pff.. took me long time to find that answer. Yes I now understand when it says: "This is a multilingual variable." below the text box, it means i need to change the language from the site (with the language dropdown for example) and just enter the text in the same box...

mgifford’s picture

Version: 6.x-2.4 » 7.x-3.x-dev
Status: Closed (fixed) » Active

Same issue seems to be happening with D7 so re-opening it. We've got to have references here to http://drupal.org/project/variable though as $conf['i18n_variables'] is so D6.

tr’s picture

Status: Active » Postponed (maintainer needs more info)

What "same issue" are you talking about? There're 16 posts ahead of yours, and to summarize what I read above, there is no outstanding issue here. I'm not sure what the Variable module has to do with the i18n module - they have separate ways of dealing with multi-lingual variables, and we have chosen to support i18n because it provides internationalization support for more than just variables.

mgifford’s picture

Title: checkout messages not using the translated text » Checkout messages not available as multi-lingual values
Version: 7.x-3.x-dev » 7.x-3.0

1) Go to en/admin/store/settings/checkout/edit/messages in a D7 install with 118n (7.x-1.4) enabled edit any of the values in the "Completion messages"
2) Go to fr/admin/store/settings/checkout/edit/messages and the change in the English value is there. Modify it to a french value.
3) Go back to en/admin/store/settings/checkout/edit/messages and see the French value overwritten on the English.

We've tried to address this with StringOverrides & Strongarm, but these are values not wrapped in a t() so they aren't working either.

Hope this clarifies things a bit. As you know I also posted #1533286: Add support for Variable module but still uncertain how D7 is dealing with user defined multi-lingual variables. I18n doesn't seem to support it on it's own.

aacraig’s picture

I've run into this issue myself, and I think the problem lies in the basic implementation of how the strings are retrieved.

The basic strings are stored as variables with variable_set/variable_get. This is fine as long as the site will only be in one language, whether that language is English or another language.

Once the site is truly multilingual -- that is, displaying information in a number of languages -- this system causes confusion at the UI level.

Drupal translation is already complex, and hopefully will be simplified in D8, but in the meantime, this sort of double storing of data should be avoided. I'll explain.

The use of t() implies that the strings will be saved in a table as translated strings, however, the use of t() also implies that the same string (in one language only) will also be stored in the variable table.

This creates confusion, because the most obvious place to search for a string to translate is in the i18n provided form under admin/config/regional/translate/translate.

In fact, searching for a string like "Your order is almost complete." returns a couple of hits, one of which is "Please review the details below and click 'Submit order' if all the information is correct. You may use the 'Back' button to make changes to your order if necessary." which appears in the checkout workflow.

Translation of this string has no effect, however, if the string has also been inserted in the cart configuration form, because it exists at that point in the variable table, which will override any translation of that string.

Even if a user empties the form field with the string and saves (one could understand them thinking they've "deleted" the string at that point) the translation still has no effect. You must actually variable_del(string_id) in order to have the translation show up.

This means there are two ways to translate the same string, only one of which will work depending on mechanisms which are completely hidden from the user -- not the best way of guaranteeing an easy user experience.

To make translation easier, I suggest completely removing variable_get/set from the picture, and using i18n_string() to save these strings. This will allow users to always translate in one place (something I desperately hope D8 will impose) instead of the current system of translation happening in various parts.

I suggest getting rid of the wonky variable translation system provided by i18n which requires that I copy and paste a list of variables into my settings.php file. I don't believe that in today's modern world such a mechanism should be considered acceptable, especially since i18n_string() allows module developers to create strings which can then be translated in the standard Drupal form.

mgifford’s picture

Just for clarification, I don't think that we need to be adding anything to settings.php in Drupal 7:

http://evolvingweb.ca/story/drupal-7-multilingual-whats-new-i18n

That being said, I still don't have a non-core example of this:
#1533206: Module Developers: Please declare your variables. -- More Docs Needed

aacraig’s picture

I stand corrected on the copy and paste issue. You don't need to do that anymore in D7.

However, the overall problem still stands, that you can translate the variable text in two places and only one of them will work.

mgifford’s picture

I'm still struggling to find which one works. And to clarify, you aren't using the Variable module, right?

aymanar’s picture

Did anyone here find a solution to this problem? It's driving me nuts

longwave’s picture

Status: Postponed (maintainer needs more info) » Closed (duplicate)

In 7.x these variables can be translated with a patch and the use of i18n_variable module.

A proof of concept patch is available at #1533286-6: Add support for Variable module, if you test this and it works (or doesn't) please let me know in that issue.

drsnuggles’s picture

Version: 7.x-3.0 » 7.x-3.x-dev

Still having this problem using the latest Ubercart version.

GiorgosK and mgifford solutions do not work (anymore). Anyone a solution?
Edit: aha, this should work: http://evolvingweb.ca/story/drupal-7-multilingual-whats-new-i18n. Thanks mgifford, for your last reply!