Hi,

This might be caused by my perhaps non-standard setup, so if this is a bad idea in other use cases, let me know.
But what i've basically done so far:
* Add extra fields to my product entity, and make them translatable through http://drupal.org/project/entity_translation (i.e. translation per field)
* Configured my product display to use i18n content translation (i.e. a node per language)

The problems that I encounter with this are in 2 areas:
- On the node view: when viewing an NL node an English context (for example /en/node/1, where node 1 has been assigned NL as language).
The result here is that the body and title is in NL (since it's an NL node), but the inherited product entity fields are in EN. This is kind of a weird sight.
Granted, it's a strange situation to be looking at an NL node in an EN website context, but I do think it makes sense for the node object itself to be consistent and show NL information, regardless of the surrounding context.

- In the search results: this is a bigger issue for sure. The main reason I opted to have a different node display item per language (apart from possible non-product entity fields), is to able to have a distinct entry in the search index, that indexes the node in the language that has been assigned to it, and all fields of the node in the same way. Experimenting with entity_translation (one product display with field translations) didn't allow this at all, because only the EN text gets indexed, no matter what I try.
Using 3 different nodes gets me onto the right track, except that by default the product entity fields are shown in the current language of the website. Now it appears that cron is always using the EN context when indexing the nodes, so all data in the search index is in EN :(
With the small patch i created that will pass on the entity language when loading the field view, this problem seems fixed (need to test some more).

I know translation with commerce is still a WIP, and maybe this should be seen in a bigger picture. Feel free to give me any pointers as to where this would be handled best (unless it's a "won't fix" obviously).
Also, if you can think of alternative approaches to what i'm trying to achieve, that can surround this issue, feel free to let me know!

Thanks for your feedback.

Comments

svendecabooter’s picture

JGO’s picture

What does it suppose to fix? I see the correct language on the product itself. But still not when referenced in a node.
My nodes have language neutral. I changed the node language to dutch, but still the English term is showing up on the node ...

BTW I have this problem with fields I added, like of type "List (text)". So your fix is probably only for entities ?
What about your fields ?

svendecabooter’s picture

What it's supposed to fix:

If a product display node has a Product Reference to a particular product entity which has fields translated through entity translation - i.e. field level translation, not entity level translation), the fields of the product entity are implicitely inherited.
So if you have a product entity with 10 fields, and you create a product display node which has only one field (the product reference), you will be able to see all 10 fields when viewing the product display node.

In my case though, my node has a language assigned to it. So for example: my NL product node links to a language-neutral product entity.
A translatable field on that product entity will currently be shown in the current language of the user, not in the language of the product node.

Hope that clears things up for you...

Reminds me though:
Perhaps we need to add a check, to see if $entity->language != LANGUAGE_NONE. Unless in that case it will fall back to the users current language, in which case it's unnecessary. I'll have to investigate that...

JGO’s picture

So to display translations on a node of the fields added to a product (for example a select list), I need to install the entity translation module ? Is this what I'm probably missing atm ?

svendecabooter’s picture

Haven't tested yet with lists, but for regular text fields etc... entity translation allows you to have one canonical product entity, and translate its fields to multiple languages. So you should probably give that a try...

JGO’s picture

hmm I did the following:

1) Installed the http://drupal.org/project/entity_translation
2) Created a product in language neutral
3) Added a field to the product from type Long text
4) Created a node in language neutral with the product from 2) referenced and added some text for the field
5) Did a search via the translate interface search, but did not find back the text

Am I missing a step?

damien tournoud’s picture

There are likely other places to fix. We discussed with Ryan the add-to-cart form. We need to make sure to pass the display language down that path too.

svendecabooter’s picture

@ JGO:
I've set it up as following:
In step 2 you should assign a language to the product (and fill in the fields according to that language probably). Afterwards you will see a "Translate" tab, where you can translate any fields that have been marked as translatable upon creation of the field. This allows you to translate all fields, but still have only 1 product with a single ID.
From then on forward, step 5 should just be to create a product display node in each language, and reference the same product entity ID.
Perhaps you can try some variations on that depending on your needs...

@ Damien: do you have plans to work this out in more detail? i.e. where this should be added as well?
I'll check if there are other relating issues that can be merged together...

svendecabooter’s picture

Status: Active » Needs review
czigor’s picture

For me patch #1 works, thanks!

One remark: You have to set the product type entity_translateable on the product type edit page AND at admin/config/regional/entity_translation as well. Then you can translate field labels.

damien tournoud’s picture

Status: Needs review » Fixed

Committed a slight variant: we use the $langcode the entity was rendered in instead of $entity->language that might not exist on every entity type.

Status: Fixed » Closed (fixed)

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