At the moment Ubercart does not support the ability to translate a country name, so the CIF files have English country names but you cannot provide locale alternatives.

For example, United Kingdom needs to be Royaume-Uni for a French website. Impossible to do this.

I will upload a patch shortly to resolve this issue.

CommentFileSizeAuthor
#17 782960_translate_countries.patch8.5 KBIsland Usurper
#13 782960-translate-countries.patch10.3 KBlongwave
#1 782960-uc_translate_countries.patch938 bytesgreg.harvey
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

greg.harvey’s picture

greg.harvey
Primary language English
CreditAttribution: greg.harvey commented
Status: Active » Needs review
FileSize
782960-uc_translate_countries.patch938 bytes

And here is the patch. Tested on www.weeride.fr, seems to work fine.

Pomliane’s picture

Pomliane CreditAttribution: Pomliane commented

Hi,
Any news on this just-can't-believe-it issue ?
By the way is this really just a 'feature request' ?
Cheers,

greg.harvey’s picture

greg.harvey
Primary language English
CreditAttribution: greg.harvey commented
Priority: Normal » Major

Bumping this up to major, as it's a tiny patch and is a big problem for multilingual Ubercart sites.

TR’s picture

TR CreditAttribution: TR commented
Status: Needs review » Needs work

It's a problem, but the fix is just wrong. Please read http://api.drupal.org/api/function/t/6

greg.harvey’s picture

greg.harvey
Primary language English
CreditAttribution: greg.harvey commented

Hmm, Ryan intimated that might be an issue. It does work, but I appreciate it can have its own issues. Ok, so this is going to require a lot more thought.

Right now the only place these country names are strings in code is in the CIF files. Unfortunately, these are often contributed and look like this:


<?php
// $Id: antigua_barbuda_28_1.cif,v 1.1.4.2 2009/01/16 22:12:39 rszrama Exp $

function antigua_barbuda_install() {
  db_query("INSERT INTO {uc_countries} VALUES (28, 'Antigua and Barbuda', 'AG', 'ATG', 1)");

  db_query("INSERT INTO {uc_zones} VALUES "
          ."(%d, 28, 'GE', 'St. George'),"
          ."(%d, 28, 'JO', 'St. John'),"
          ."(%d, 28, 'MA', 'St. Mary'),"
          ."(%d, 28, 'PA', 'St. Paul'),"
          ."(%d, 28, 'PE', 'St. Peter'),"
          ."(%d, 28, 'BB', 'Barbuda'),"
          ."(%d, 28, 'RD', 'Redonda'),"
          ."(%d, 28, 'PH', 'St. Philip')", uc_get_zone_ids(8));

  uc_set_address_format(28, "!company\r\n!first_name !last_name\r\n!street1\r\n!street2\r\n!city, !zone_code !postal_code\r\n!country_name_if");
}

Since the country name is inserted directly in to the database, all these would need to change. But if we were to do something like this:

// $Id: antigua_barbuda_28_1.cif,v 1.1.4.2 2009/01/16 22:12:39 rszrama Exp $

function antigua_barbuda_install() {
  $country_name = t('Antigua and Barbuda');
  db_query("INSERT INTO {uc_countries} VALUES (28, $country_name, 'AG', 'ATG', 1)");

  db_query("INSERT INTO {uc_zones} VALUES "
          ."(%d, 28, 'GE', 'St. George'),"
          ."(%d, 28, 'JO', 'St. John'),"
          ."(%d, 28, 'MA', 'St. Mary'),"
          ."(%d, 28, 'PA', 'St. Paul'),"
          ."(%d, 28, 'PE', 'St. Peter'),"
          ."(%d, 28, 'BB', 'Barbuda'),"
          ."(%d, 28, 'RD', 'Redonda'),"
          ."(%d, 28, 'PH', 'St. Philip')", uc_get_zone_ids(8));

  uc_set_address_format(28, "!company\r\n!first_name !last_name\r\n!street1\r\n!street2\r\n!city, !zone_code !postal_code\r\n!country_name_if");
}

Then we could provide translations for country names in the translations for uc_store.module.

Would that work do you think?

TR’s picture

TR CreditAttribution: TR commented

Think about the way translations work. The translation template extractor parses the module code looking for strings wrapped in t(). The extractor uses the argument of the t() function to build a list of words and phrases that need to be translated. If you use a variable as the argument, there's no word or phrase to put in that list because the value of the variable is unknown and can be anything at run time (even if you personally know that the variable will only have certain values, the program has no way of determining that).

The reason your fix "works" is because you've manually translated the few country names you use in your store, which adds those countries to the list. But if a new country were loaded, that name would not appear translated until you manually added a translation for it.

The reason just adding t() into the .cif file won't work is because the .cif files are not parsed as part of the template extraction process. There's probably a way to fool the extractor by using something like (in pseudo-code ...) if (FALSE) module_load_include('<all .cif files>') in the .module. That would allow the extractor to parse the .cif files and see the country names wrapped in t() but would never load the .cif files when the module is run normally.

Someone is going to have to do the research to figure out if there's an established way of translating module data like this in Drupal (I have not encountered one) or if Ubercart has to make up its own mechanism to ensure the data is translatable. And if Ubercart has to invent a solution, what should that solution be.

greg.harvey’s picture

greg.harvey
Primary language English
CreditAttribution: greg.harvey commented

The reason your fix "works" is because you've manually translated the few country names you use in your store, which adds those countries to the list. But if a new country were loaded, that name would not appear translated until you manually added a translation for it.

Yup, which is fine for my purposes (it stopped my client chewing on my arm) but as you say, it isn't a correct long-term fix.

Thanks for the suggestions/ideas to follow up on. I'll see if I can do a little research when I get back from my holidays. Hopefully some other interested parties will join in. I'll tweet it and see if any traction is gained.

PROMES’s picture

PROMES
Primary language Dutch
CreditAttribution: PROMES commented

The patch in #1 does work, but the resulting table still is sorted the original way. We have to add a sort.
Part of the original patch:

   $options = array();
   while ($country = db_fetch_array($result)) {
-    $options[$country['country_id']] = $country[$order_by];
+    $options[$country['country_id']] = t($country[$order_by]);
   }
   if (count($options) == 0) {
     $options[] = t('No countries found.');
   }

after the shown code should be added:

+  else {
+    natcasesort($options);
+  }

Anyone who needs a translation .po file:
use the .pot file from project: countries_api.

longwave’s picture

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

Marked #801436: Allow translate zone name in uc_zone_select (uc_store) as a duplicate.

Bartezz’s picture

Bartezz CreditAttribution: Bartezz commented

As mentioned in the duplicate issue, same goes for zone names.

Cheers

TR’s picture

TR CreditAttribution: TR commented

See also #1066364: META: Make custom data translatable.

longwave’s picture

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

See #1066364-11: META: Make custom data translatable for a possible approach to this.

longwave’s picture

longwave
he/him
Primary language English
Location UK
CreditAttribution: longwave commented
Status: Needs work » Needs review
FileSize
782960-translate-countries.patch10.3 KB

Patch attached. This lets you run a multilingual Ubercart installation that has translated country names in the dropdowns at checkout and the various admin pages that show country names, sorted alphabetically where needed.

Country names are stored in English in the database and then t() is wrapped around $country_name where appropriate - this is not usually recommended, but in this instance it is okay as the variable will always come from a fixed set of strings. uc_store.countries.inc will ensure these strings are extracted by potx when translation source files are generated; this file is never included but in testing potx will pick it up anyway.

Until this is committed and a new 6.x release is made, localize.drupal.org will not include translations of country names in Ubercart .po downloads. You can work around this by adding translations manually, or importing a .po file from another project that includes translated countries.

This patch was sponsored by Opsview.

longwave’s picture

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

Planning to commit this to 6.x soon, as it has been working well in testing here. Comments or reviews still welcome, however.

TR’s picture

TR CreditAttribution: TR commented
Status: Needs review » Reviewed & tested by the community

I didn't try to use a translation, but I inspected and tested the patch with a clean install in English and everything behaved as it should without any errors. The approach is sound and addresses all the concerns above and in related issues. As mentioned in http://drupal.org/node/1066364#comment-4231434, the addition of uc_store.countries.inc won't be necessary for the D7 port.

longwave’s picture

longwave
he/him
Primary language English
Location UK
CreditAttribution: longwave commented
Version: 6.x-2.x-dev » 7.x-3.x-dev
Status: Reviewed & tested by the community » Patch (to be ported)

Committed to 6.x. Needs porting to 7.x without uc_store.countries.inc, as noted by TR.

Island Usurper’s picture

Island Usurper CreditAttribution: Island Usurper commented
Status: Patch (to be ported) » Needs review
FileSize
782960_translate_countries.patch8.5 KB

Here 'tis. Haven't tested it yet, but I'll install a language I can halfway read before too long.

longwave’s picture

longwave
he/him
Primary language English
Location UK
CreditAttribution: longwave commented
Status: Needs review » Fixed

Tested and committed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.