Seem to be unable to translate attributes the appear on the add to cart forms. Including the Attribute title, it's help text and it's values.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

rszrama’s picture

Status: Active » Closed (works as designed)

That's because these values are coming from data stored in the database, not string literals in modules. This is a long standing issue without a direct fix available to us at the moment.

mrfelton’s picture

damn. What a pain... impossible to run a multi language site then. Wish I knew that before I built one!

rszrama’s picture

Not impossible, you just have to get creative. Other people are working on the issue, though. Look for solutions to things like multi-lingual menu items and taxonomy terms and you should find a solution by way of analogy.

mikejoconnor’s picture

FileSize
1.32 KB

Here's a patch to add support for attribute translation. Please review and provide feedback.

rszrama’s picture

Well, remember, we can only wrap string literals in t(). I think other modules provide ways to translate non-literal strings that we'd have to tap into.

patchak’s picture

Is there any activity around this issue? We need to translate options and attributes as well, so really interested in this. We are willing to work on this, if someone would point us to the right direction??

Thanks

joostvdl’s picture

Version: 6.x-2.0-beta6 » 6.x-2.x-dev
Status: Closed (works as designed) » Needs review

I installed the patch from #4. I tested it Successfuly.

longwave’s picture

Status: Needs review » Needs work

As noted in #5, you are not allowed to use t() to translate user-defined data like that, so #4 won't be committed as-is.

TR’s picture

daamy’s picture

thanks mikejoconnor for the patch.
I didn't run the patch but modified the code manually.
it worked for me.

Anonymous’s picture

Status: Needs work » Patch (to be ported)
FileSize
5.19 KB

Hi !

Here’s a patch that brings internationalization to UC Attribute module by the means of String translation module (i18nstrings). As recommended, it does not use t() function for the translation.

I’ve also tried to make it work with UC Dependent Attributes and UC Ajax Attribute Calculations (seems to also work :-) ).

IMPORTANT : It seems to work at first glance but needs some deeper review to be sure it does not break anything elsewhere, so don’t use it on a production site !

If someone could make some tests…

TR’s picture

Status: Patch (to be ported) » Needs review

Wrong status - should be "needs review". Let's give the testbot a shot at it ...

Status: Needs review » Needs work

The last submitted patch, uc_attribute.module.diff, failed testing.

Anonymous’s picture

Which format of patch should I use ?

longwave’s picture

Title: Unable to translate attribute name/help text/values » Allow translation of attribute name/help text/values
Category: bug » feature

The easiest way to create patches is with "git diff" from the main Ubercart directory.

Also retitling this issue, as technically it is not a bug; translation was never supported in the first place.

hachreak’s picture

+1

This feature is very necessary in my projects... there are some news on how to allow translation? :)

What is the problem to intregrate last patch?
I try to create this patch with "git diff". Someone can tell me if it works? :)

Best,
hachreak

longwave’s picture

Status: Needs work » Needs review
TR’s picture

Status: Needs review » Needs work

Lots of coding standards and documentation standards issues.

hachreak’s picture

I have fix the patch because there is a dot that broke the code... :-P

hachreak’s picture

Someone can help me? I have not much experience in "coding standards and documentation standards" issues.. :)
What should I do?

Thanks
hachreak.

longwave’s picture

You can use the Coder module to ensure your changes follow standards: http://drupal.org/project/coder - see also http://drupal.org/coding-standards/ for full details of the Drupal standards.

As an example:

if(!function_exists('i18nstrings_update')) return FALSE;

should be

 if (!function_exists('i18nstrings_update')) {
  return FALSE;
} 

(ie. a space between if and (, and we always use { } braces in statements even if there is only one line)

hachreak’s picture

Ok, I fixed all the things that coder module return back (I update only code relative to my patch, not to complicate things and maybe add bug.. :-P).
Now what can I do?

longwave’s picture

Status: Needs work » Needs review

Wait for someone to review and test it!

longwave’s picture

I updated and simplified the patch from #22, works for me on product pages, cart and checkout at least but untested with other modules.

@hachreak: Are you able to test this?

longwave’s picture

Wrong patch, use this one.

hachreak’s picture

Hi Longwave,
thank you for your patch! :D
I try it and it seems to work for me... XD
I'm not using special ubercart modules, so I don't know if it works with them, but I don't think there are big problems.. :-P

Best,
hachreak

longwave’s picture

Version: 6.x-2.x-dev » 7.x-3.x-dev
Status: Needs review » Patch (to be ported)

Committed #25, needs porting to 7.x.

hachreak’s picture

Yeah! Thanks... :D

When can I download the new release of ubercart with this patch? :)

longwave’s picture

It will be included in 6.x-2.x-dev tomorrow, or wait for 6.x-2.10 - but there is no set release date.

Ken Hawkins’s picture

Wanted to add a foot note here that while this patch largely works for me, I'm having some sort of error where the language codes were flipped.

It's a dual language site and the German text was showing on the English products, though the other translations worked fine.

I just went through a rough site move so it could be related to that. In a perfect world I'd have the time to setup a test site and try again.

Adding this comment in case someone else should encounter the same issue.

TR’s picture

Committed coding standards fixes to address #18, see commit 030c644b1c545e001650e. Please ensure the 7.x-3.x patch takes these into account.

betz’s picture

Status: Patch (to be ported) » Needs review
FileSize
3.03 KB

And a drupal 7 patch...

betz’s picture

And with coding standard fixed :)

Status: Needs review » Needs work

The last submitted patch, uc_attribute_locale_d7-436684-32.patch, failed testing.

longwave’s picture

Status: Needs work » Needs review
betz’s picture

don't get it, everything passed, but on #34 we get the message the patch failed?

longwave’s picture

#34 failed in the credit card tests, which this patch does not touch. There is an occasional random failure in those tests but I have not yet figured out exactly what causes it.

longwave’s picture

Status: Needs review » Needs work

Thanks for the patch, but #33 doesn't work for me.

After enabling i18n_string I can translate the attribute and option strings at /admin/config/regional/translate/translate but then the translations don't show up on the product pages or in the cart; they're just shown in the original language.

betz’s picture

Weird.

Are you sure that you are seeing the ubercart attributes strings?
Have a look at http://www.evernote.com/shard/s88/sh/e032f484-a41f-4394-96a8-8b3205352d0...

Also, refresh the strings at en/admin/config/regional/translate/i18n_string

betz’s picture

Also, are you using the default product contenttype? Or a product class?

longwave’s picture

I am seeing the Ubercart attribute strings, I can see and translate them in the screen from your screenshot, but the translations never show up on the front end. I have the attribute attached to two products, one is the default product content type and the other is a new class I created for testing, though I am not sure why this should make a difference. I also wasn't running the latest i18n module either, but I have upgraded to that and it still isn't working.

longwave’s picture

Status: Needs work » Needs review

Configuration error on my part, sorry! I forgot I had been messing with the settings at /admin/config/regional/language/configure and switched off URL detection for user interface translation, which is the method I was using to switch language (it was still on for content, but these strings are considered UI).

betz’s picture

So you got it to work then?

longwave’s picture

Status: Needs review » Fixed

Yes it works for me, after some more testing everything seems fine, so I committed it with some minor changes to keep the comments in line with 6.x-2.x. Thanks for your work on the patch!

Status: Fixed » Closed (fixed)

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

betz’s picture

Status: Closed (fixed) » Needs review
FileSize
1.33 KB

Ok, so I was missing the attributes and options that are attached to the product.
I only had the general attributes and options refreshed.
Attached patch fixes this.

Status: Needs review » Needs work

The last submitted patch, uc_attribute_locale_d7-436684-46.patch, failed testing.

longwave’s picture

Status: Needs work » Needs review
longwave’s picture

+  $product_attributes = db_query("SELECT nid, aid, label FROM {uc_product_attributes}");
+  foreach ($product_attributes as $product_attribute) {
+    i18n_string_update('uc_attribute:attribute:' . $product_attribute->aid . ':label', $product_attribute->label);
+  }

Shouldn't we add $nid to the key somehow here, and anywhere else product attribute translations are used? It seems like we would be using duplicate keys in the case where you have two different labels on the different products that share the same $aid.

betz’s picture

My first code was like that, but i thought when the text is the same, it ignores that key?

longwave’s picture

I am not sure; maybe this needs handling in uc_attribute_translate() as well? Not entirely sure how we would do it at first glance, though. I guess this needs testing to see if it's an actual problem or not.

pcorbett’s picture

markdc’s picture

Issue summary: View changes

I have translation working, but the correct translation isn't always displayed for the current user language; it’s 50/50. Has anyone else experienced this symptom? Could it be a caching problem?