Closed (duplicate)
Project:
Ubercart
Version:
7.x-3.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
19 Sep 2009 at 10:19 UTC
Updated:
7 Jun 2013 at 14:08 UTC
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
| Comment | File | Size | Author |
|---|---|---|---|
| uc_checkout_messages_translation.patch | 3.05 KB | giorgosk |
Comments
Comment #1
univate commentedHaving t() around variable_get() doesn't seem right to me and reminds me of this issue #540716: Overuse of variables table
Comment #2
rszrama commented@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.
Comment #3
rszrama commentedSee #466014: uc_get_field_name() breaks translation.
Comment #4
giorgoskI did not know I was not supposed to use
t()like thisI am going to try the latest dev version and see if it fixes this issue
Comment #5
Militopedia commentedHello Giorgios,
Were you ever able to solve this? I am having the same problem, but don't know what to do.
Regards
Roger
Comment #6
giorgoskI have used the
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-submitbecomesuc_msg_order_submitAfter 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
Comment #7
Militopedia commentedHello Giorgios,
Thanks a lot for your help and for taking the time to reply!! That solved the problem :-D
Cheers,
Roger
Comment #8
hosais commentedThank you very much, GiorgosK. This works for me perfectly.
hosais
Comment #9
heyyo commentedDoesn'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 ?
Comment #10
heyyo commentedComment #11
YK85 commentedsubscribing
Comment #12
heyyo commentedI don't have this bug anymore with internationalization 6.x-1.6 http://drupal.org/node/902742
Comment #13
tr commentedComment #14
janton commentedi 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...
Comment #15
longwaveYou 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.
Comment #16
janton commentedYes 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...
Comment #17
mgiffordSame 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.
Comment #18
tr commentedWhat "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.
Comment #19
mgifford1) 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.
Comment #20
aacraig commentedI'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.
Comment #21
mgiffordJust 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
Comment #22
aacraig commentedI 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.
Comment #23
mgiffordI'm still struggling to find which one works. And to clarify, you aren't using the Variable module, right?
Comment #24
aymanar commentedDid anyone here find a solution to this problem? It's driving me nuts
Comment #25
longwaveIn 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.
Comment #26
drsnuggles commentedStill 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!