The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.I'm having a small but persistent problem on a bilingual (English/French) Ubercart site. There is one specific string - the line in the cart block that says "Click title to display cart contents" - that always appears in English, no matter what, and resists all attempts to translate it.
That string does not show up in the Translate interface, so I couldn't add a translation there. I installed the Localization Update module and used that to make sure all available French translations were installed - no luck. I then tried Localization Client, which lets you see, and add translations for, all translatable strings that appear on a given page - it didn't appear there either.
So at that point I checked the module code, and found the string in two locations in uc_cart.module, on line 321 and 421. I was expecting to find that someone had neglected to wrap it in the t() function to indicate it as translatable, and that all I would have to do would be to add that, but to my surprise it actually did have t() in both instances.
Line 321: if (variable_get('uc_cart_show_help_text', FALSE) && ($text = variable_get('uc_cart_help_text', t('Click title to display cart contents.')))) {
Line 421: '#default_value' => variable_get('uc_cart_help_text', t('Click title to display cart contents.')),
So now I'm stuck: t() is supposed to make a string translatable, so why isn't it doing its job in this instance? What can I do to make that string translatable?
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 2102989-remove-uc_cart_help_text.patch | 1.3 KB | longwave |
| #3 | 2102989-translate-uc_cart_help_text.patch | 1.56 KB | longwave |
Comments
Comment #1
spidersilk commentedI eventually discovered what the problem was, but I think this is still a bug that should really be fixed at some point. It turned out there was an option to add custom text for that line in the block settings, which would then override the string specified in the module code - and run you right into the problem discussed in various other places in the issues queue about custom text not being translatable.
The custom text field seems to be by default filled with the same string specified in the code - "Click title to display cart contents" - which basically means that even if you don't want to customize the text, it still overrides the default text and makes it untranslatable. I tried just deleting the text from that field on the block configuration page, in hopes that that would make it revert to the translatable string in the code, but no - it just made it not display the text at all (because presumably it interpreted it as a custom string of "").
I would recommend that in a future version of UC, a checkbox be added to the block settings for whether or not you want to customize the help text, and if that box is unchecked, it would not use any custom text, and rely on the default text specified in the module code, which it would hopefully then allow to be translated. Because without that, the help text will only ever appear in a single language regardless of what language the rest of the page is in, or whether or not the user has any desire to customize it.
Also, as a side note, the default text doesn't really make sense unless the block is always shown collapsed by default - it would be better if it said "Click title to show or hide cart contents", so that it would make sense regardless of whether the block was shown collapsed or expanded.
Comment #2
tr commentedDrupal does not have a way to translate user-defined strings. That's a limitation of Drupal, not Ubercart.
What we have been doing recently is to remove the Ubercart UI that allows the user to redefine some Ubercart strings, and instead suggest that the String Overrides module be used for this purpose. That's probably what should be done here - simply remove this configuration and make the user use String Overrides if he/she wants to change the text.
Comment #3
longwaveThe problem with removing this one now is that it would affect sites that have already changed this setting.
Instead we can add it to uc_cart.variable.inc with the attached patch, and you can use the Variable translation module provided with i18n to translate it.
Comment #4
longwaveThis doesn't work as expected on the block settings form.
Maybe we should just remove the setting but leave the variable_get() call for users who have already set it; i18n users who want to change it can delete the variable and use string overrides.
Comment #5
longwaveThis patch removes the field from the UI and any way of saving the variable, but still uses the variable if it is already set. Existing users are not affected, unless they want to change the string - I imagine this is not done very often!
Comment #6
longwaveCommitted #5 with an additional comment next to the only remaining use of uc_cart_help_text noting that it is for backward compatibility only.