Description of Problem
No matter what I try, I cannot get my Ubercart Catalog Block to change languages when I use the Language Switcher. You can test this behaviour for yourself at:
holistichorsecare.com/zh/products/aromadog-arf-ritis-pain-relief-1oz
Regardless of the language context (English or Chinese, "en" or "zh-hant"), the shopping cart block on the left margin of the page, under all circumstances, displays this text:
Shopping cart
There are no products in your shopping cart.
0 Items Total: HK$ 0.00
Go ahead and give it a try. Load the page and click on English or Chinese as they appear in the page header. The shopping cart block does not change languages- and I'd like it to.
The Localization Files are Installed - I Think...
I've installed the following localization strings packages using the Administration front end and they appeared to be loaded correctly.
- ubercart-6.x-2.13.zh-hant.po
- uc_ajax_cart-6.x-1.0.zh-hant.po
Checking out the Module Code
Looking into:
holistichorsecare.com/www/content/sites/all/modules/ubercart/uc_cart/translations/zh-hant
I see the following entry around line 1926:
msgid "There are no products in your shopping cart." msgstr "ä½ (妳)ç è³¼ç©è»è£¡æ²æä»»ä½åå."
(the garbled text is the multi-byte characters breaking up in my shell)
Looking into
holistichorsecare.com/www/content/sites/all/modules/ubercart/uc_cart/cart.module
I see the following call around line 706:
$output = '<p class="uc-cart-empty">'. t('There are no products in your shopping cart.') .'</p>';
So it appears that there is a call to t() to translate the string, but none is forthcoming from whatever system there is that serves up the alternatives.
Can someone please tell me where I need to go in the administration front end to enable localization/translation for the shopping cart block (ajax cart) in Ubercart?
I'm thinking I just missed a check box somewhere to turn on the translation, or have to tell Drupal/Ubercart that the strings in the Shopping Cart Block are to be translated, but I don't know where to go or how to do this.
P.S.: When I called i18n_get_lang() in troubleshooting code I got the right answer back (i.e. "en" or "zh-hant"), so the system knows what language context it is in.
Thank you.
UPDATE - SUCCESS!
I managed to get this working by importing zh-hant strings into the Built in Interface.
Here's how I did it:
1) I went to Site building » Blocks and confirmed that the Shopping Cart block Language setting was set to All Languages
2) I went to Site configuration » Languages » Configure » Language Negotiation and set the Language negotiation setting to Path prefix with language fallback
3) I went to Site building » Translate interface and selected the Import Tab
4) On the Import tab, I clicked on Choose File button and then selected ubercart-6.x-2.13.zh-hant.po, which holds a bunch of Chinese definitions. I got this definitions file from localize.drupal.org/translate/languages/zh-hant
5) I selected Built-in Interface and Existing strings are kept, only new ones are added
6) I then clicked on IMPORT
Verification
Once the import was complete, I clicked on the Overview tab to check the results:
Chinese, Traditional 4242/9881 (42.93%) 0/19 (0%) 0/16 (0%) 0/49 (0%) 0/37 (0%) 0/15 (0%) 1518/1518 (100%) 2/3 (66.67%)
Apparently, this import loaded 4242 definitions into the Built-in Interface section of the Drupal system. These strings are nowhere near the Store Administration area, which is a bit of a mystery to me, but hey - it worked.
Conclusion
Once I had completed the above steps, the Shopping Cart Block began to display correctly in Chinese or English depending on which language was selected with the Language Switcher.
Final Comment & A Question
On second thought, maybe this is not so counter-intuitive after all. After all, the BLOCK is part of the General Interface of the Drupal System, not specifically a part of the Checkout process.
Maybe I'm wrong about this...can anyone confirm or correct?
The procedure you did is correct, code which calls
t()will create a create a string (usually under theBuilt-in Interfacegroup) and needs to be translated manually by searching for a string, or by importing a.pofile which contains the necessary strings into that group.What makes the behaviour a little more bizarre if you're not familiar with it is that because
t()only creates interface strings at call-time, you must view the content in the desired language first (even though it will be broken / no translations). This allowst()to create the string entries in the database, which allows you to subsequently translate them.I would recommend that you use a module such as l18n_update to keep your interface translations up to date automatically and import strings for any new changes made upstream.