Drupal 7 has vastly improved support for making dynamically-defined data translatable. I'm opening this as a meta-issue to coordinate the steps needed to make this happen. Specifically, this issue is about translating strings which cannot be translated by t(). Any string literals which are not properly wrapped in t() should be reported in a separate issue. Any system variables which have not been properly declared as i18n variables should be reported in a separate issue. But any place where you're tempted to solve a translation problem by coding something like t($string_variable) should be added to the discussion here.

This issue is NOT about translating node content, like product names and descriptions. This issue is NOT about translating taxonomy terms and vocabulary names. Translation issues for parts of Drupal other than Ubercart are best handled outside this issue queue. Lastly, this issue is not about translation in the Drupal 6 version of Ubercart - this issue is for Drupal 7 / Ubercart 3.x only.

The changes needed to make custom data translatable are outlined in http://drupal.org/node/304002. First, though, we need to identify all the places where user-defined or custom data is used in Ubercart. I'm posting my initial list as a reply so I will be able to edit it as we work on the issue.

When I have some confidence that the below list covers most things we need to worry about, I will post an initial patch. This process will only work if I can get some people who actually need to use translation to TEST this patch and provide feedback, so if this is something you're interested in please subscribe to this issue and let me know you're willing to test.

CommentFileSizeAuthor
#11 uc_store.countries.inc_.txt2.02 KBlongwave
#3 1066364.patch7.01 KBTR
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

TR’s picture

TR CreditAttribution: TR commented
Status: Postponed » Active

User defined data in Ubercart consists of:

1) Country and region names #782960: Support translation of country names to native spellings (& related issue #1062548: Unify CIFs between versions)
2) Attribute labels and option labels #436684: Allow translation of attribute name/help text/values
3) Flat rate and Weight quote method labels #835566: Multilingual Shipping Quote Label
4) Tax method labels #883600: Some interface message and Tax name not translated in multilangage site and #689246: uc taxes titles not localizable
5) Order status strings #993360: Make order status strings translatable
6) File description for file downloads
7) Order comment/log message #789852: Non translatable strings found in uc_order.admin.inc. Should be passed through t().

Please add to this list if I missed something...

TR’s picture

TR CreditAttribution: TR commented

Added "(& related issue #1062548: Unify CIFs between versions)" to 1)

Added 6)

TR’s picture

TR CreditAttribution: TR commented
FileSize
1066364.patch7.01 KB

And my first attempt at identifying all the database fields that need to be marked "translatable" as per http://drupal.org/node/304002

longwave’s picture

longwave
he/him
Primary language English
Location UK
CreditAttribution: longwave commented

What about order comments/log messages produced by modules? We would need to store the original translatable string and any parameters needed to format it, the same way watchdog() does.

TR’s picture

TR CreditAttribution: TR commented

Added 7) with a link to an issue where I said just that :-)

It's not clear to me how the translation system gets a list of all the watchdog messages to add to the translation template.

longwave’s picture

longwave
he/him
Primary language English
Location UK
CreditAttribution: longwave commented

@TR: http://drupal.org/project/potx module scans module code for t() and watchdog() calls. Not sure whether it is possible to extend this to look for other functions, so 7) may not actually be feasible.

TR’s picture

TR CreditAttribution: TR commented

Ah, that's what I guessed was happening. Right, that means we can't do it exactly the same way. However, marking the table column as translatable and modifying the queries that read those tables as shown in http://drupal.org/node/304002 should do the trick just as well. We will want to preserve the placeholder arguments in the translatable message string, so we probably have to add another column to hold a serialized array of the the variable replacements, as is done with the watchdog table.

sylvain_a’s picture

sylvain_a CreditAttribution: sylvain_a commented

Suscribe

longwave’s picture

longwave
he/him
Primary language English
Location UK
CreditAttribution: longwave commented

Posting to note I will likely be working on most of these items in 6.x at some time in the near(ish) future, so if TR or anyone is working on this it would be good to discuss implementations first so 6->7 upgrades with this feature in place go smoothly.

TR’s picture

TR CreditAttribution: TR commented
Status: Active » Postponed

Given the information in http://drupal.org/node/1084354, I don't see a way forward on this issue until the promised DDT contribution materializes.

longwave’s picture

longwave
he/him
Primary language English
Location UK
CreditAttribution: longwave commented
FileSize
uc_store.countries.inc_.txt2.02 KB

Tested an idea out with http://drupal.org/project/potx for 6.x. I saved the attached file as uc_store/uc_store.countries.inc and created a translation template; the resulting file contains all the country names ready for translation, even though it is never directly included. Helpfully, many country names have already been translated on localize.drupal.org as they are used by various other modules - for example see http://localize.drupal.org/translate/languages/fr/translate?search=New+Z...

I think this means if this file is included in the next release and we use t($country_name) in the code - which we can do here because the set of strings will be limited to the ones listed in the file - then translations of the next release will automatically handle country names.

The attachment is for the 6.x branch but building a similar file for 7.x is trivial. Presumably we can do the same for zone names as well, although I imagine most of these will not have been translated yet.

TR’s picture

TR CreditAttribution: TR commented

Actually, if you're talking about Drupal 7 only and about country names only, you don't have to do any of this - the country names are already defined as part of core Drupal (in includes/iso.inc). Any translation of Drupal ought to already have the country names in it, in which case wrapping t() around uses of $country_name is a valid way to allow Ubercart to access these translations.

The only glitch is that Ubercart 7.x-3.x has a 100% up-to-date ISO 3166-1 compliant list of country names, while Drupal 7.0 does not. Drupal has a few names missing and a few countries named different than the ISO names. I opened an issue last month to try to get this fixed in core (#1068840: core/includes/standard.inc contains inaccurate country data). For the other 240+ countries, this should just work.

TR’s picture

TR CreditAttribution: TR commented
Status: Active » Postponed

Added #689246: uc taxes titles not localizable to the list of issues being tracked.

mortician’s picture

mortician CreditAttribution: mortician commented
Version: 7.x-3.x-dev » 7.x-3.1

Does exist tested patch to translate uc_attribute and uc_taxes in Ubercart 7.x-3.1?