General Description:
Node reference doesn't recognizes the referenced node language. It also shows a error when trying to translate a node with references.

What I tried:
I created two content types:

  • Father (Multiligual support enabled, with translation)
  • Child (Multiligual support enabled, with translation)
    • with a field "son_of" as a node reference to Father.

I added a father "John" (lang.: English), and a child "Michael" (lang: English), "son_of" John
Then I translated John to Spanish (no problem)
Finally I tried to translate Michael to Spanish. The following error appears:

  • Notice: Undefined index: nid in node_reference_field_prepare_translation() (line 742 of /var/www/drupal7/sites/all/modules/references/node_reference/node_reference.module).
  • Notice: Trying to get property of non-object in node_reference_field_prepare_translation() (line 746 of /var/www/drupal7/sites/all/modules/references/node_reference/node_reference.module).

Problems found
besides the error message shown I found that:

  • Name of father appears in both languages
  • Father with wrong language can be selected
  • Otherwise seems to work: if you choose the correct node, everything seems fine despite the error message
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

fgm’s picture

I'm not sure we have clearly defined what should happen in such a case: when Parent/en, with Child/en is translated to Parent/es, should the translation Parent/es automatically inherit Child/en as a child, although these are different nodes and in different languages. Or should the newly create translated child node be created without inheriting any of its parent's node references ?

narwhal’s picture

Sorry, I don't think I fully understand your comment. Parent have no reference to Child, it's the other way around isn't it?
Anyway, when I translate a node to, say, Spanish, what I expect to find in the reference select list are nodes in Spanish, and not in every possible language on the site (isn't that obvious? maybe there is some user-case I didn't think of?)
And it's not just because it is "nicer" or "easier", it just doesn't work otherwise. One example:
Say your site is Spanish/Italian. Then probably the name of half of the nodes would be equal, and it would be impossible for you to know which node of the list corresponds to your current language, resulting in incorrect assignations.

narwhal’s picture

Besides, there's the error message thing

sahuni’s picture

Please, make this new module works with i18n.
The d6 cck noderef could not be used in a multilingual website.
If I have nodes in French and German, for content type A and content type B, when showing a node of type B with noderef towards nodes of type A, I must keep language coherence.
node B1, fr ==> node A1, fr
node B1, de ==> node A1, fr
node B2, de ==> node A2, default language if A2 not yet translated.

nils.destoop’s picture

We had the same problem, but found the solution.
Multilangual select should be enabled from i18n, then everything seems to work.

oxyc’s picture

I'm having the same issue and the multilingual select solution isn't working for me.

I played around a bit with the node_reference_field_prepare_translation() function but without luck (I'm no module developer). There are some weird stuff going on there though; for example there's a reference to a $node variable that doesn't exist.
After some tweaking and using $langcode instead of $node->language and $reference[0]['nid'] instead of $reference['nid'] I got it to return a proper array with the correct nids but my luck stopped there...

I'm assuming it needs updating because of the @todo but I'm way too tired to read up on it now. I'll see if I can get it solved later on.

webflo’s picture

Status: Needs review » Active
FileSize
1.92 KB

Hi had the same problem with Content Translation. Here is a patch which fix the issue. I hope this is okay.

webflo’s picture

Status: Active » Needs review
webflo’s picture

Status: Active » Needs review
FileSize
2.29 KB

I am sorry. I uploaded the wrong patch.

cedric’s picture

Thank you webflo, the patch in #9 worked..
I had many PHP warnings though, so I made a cleaner patch based on your work.

Please note that there is another potential problem related to the i18n sync module: If you enable i18n synchronization on a node ref module, the i18n sync module will override the values back to the original in the source translation when you create a translation and every time you save..

There was some talk on how to potentially fix this in D6:
http://drupal.org/node/478104

Seems like until i18n sync is fixed, you should not enable synchronization for node references and do the maintenance manually. I will see if I can fix this problem later on, as it causes a problem in my current project.

juves’s picture

It works fine without sync enabled.

joostvdl’s picture

Patch #10 is working. I have no syncing enabled on the reference field.

It would be nice to have a message set that the old node references is removed, so an editor will be alerted to the change.

cpelham’s picture

The patch works for me but I get the following error message when I translate a node with a reference:

Notice: Undefined index: und in ctools_entity_from_field_context() (line 173 of C:\xampp\htdocs\sandboxsite2\sites\all\modules\ctools\plugins\relationships\entity_from_field.inc).

I have cross-posted this in the ctools queue:

http://drupal.org/node/1172084

cpelham’s picture

I don't get that error on every page though so I'll have to look at the fields. Maybe some pages have an empty field that is causing problems? or isn't translated yet?

idflood’s picture

subscribing

Cyberwolf’s picture

Subscribing.

vasike’s picture

subscribe.
what about using Translations Ids (tnid) instead of Nodes Id's (nid), and display the current language (or default if there's no translation for the current) referenced node.

cpelham’s picture

Something has happened and the nod reference auto-complete is no long recognizing any non-English node title or nid. I think I updated i18n a few days ago. maybe that was the cause? Has anyone else experienced this?

cpelham’s picture

Status: Needs review » Needs work

Rolling back to i18n beta6 fixes my problem. so it appears that the patch in #10 above is broken by i18n beta7 (and is also broken in i18n beta8).

cpelham’s picture

Priority: Normal » Major

Rolling back i18n to beta6 on a live site causes other problems, so I am stuck uploading beta6 just to edit nodes with references to non-English nodes, and then immediately uploading beta8 again. This is not a good way at all. :)

Has anyone else run into this new problem or found a fix?

mordonez’s picture

subscribing

gausarts’s picture

Subscribing. Thanks

cpelham’s picture

From Jose, from the i18n issue queue, I got this solution:
Try disabling 'Multilingual select' module or disabling it for node edit paths:
node/add
node/*/edit

For me it worked to simply add those to node paths at:
admin/config/regional/i18n/select

jmones’s picture

The patch in #10 works but doesn't behave in the best way with i18n_select. If i have i18n_select installed and referenced content is not translated to the destination language, original node reference is left, but it fails to save it because it's not a valid reference.

The best solution I can think of would be to:
1.- Find a translated referenced content
2.- Get node_reference_potential_references() data
3.- Check if translated referenced content is one of the nodes in 2. If yes we have finished. Set an informational message to warn the user.
4.- Check if non-translated referenced content (original) is a member of the nodes in 2. If yes we have finished.
5.- Clear reference. Set an informational message to warn the user.

If done like this it should also play nice with any view used to filter referenceable content.

What do you think?

jmones’s picture

Hello,

I've adapted patch in #10 by @cedric to the behaviour I posted in #24. Namely:

i18n_select
enabled disabled
translation exists translation translation
doesn't exist empty original

Table above is ugly but at least understandable! ;)

I've used node_reference_potential_references() using parameter with 'nids' for original and translated content. This would allow for applying wierd fieltering schemes using reference views. In the case both contents are acceptable, the function chooses the translated one.

Regards

palamida’s picture

Patch #10 worked fine for me except for one thing...

I have A content type that references multiple B content type nodes
Translating the A content type node shows the translated B content type nodes (with selected references)
...so far so good.

The problem is when node A is set as "Language neutral" then I cannot chose from the list of all B content type nodes but just from the "Default language B content type nodes"...

Just like when creating new nodes of content type A... only the default language nodes of content type B are shown...

any suggestion ?

mordonez’s picture

subscribe

tegerson’s picture

thx for patch in #25 !

nico.knaepen’s picture

Patch #25 worked for me!

Cyberwolf’s picture

subscribing

cpelham’s picture

Does this still work? It was all working fine for me but it suddenly stopped working (after updating to latest Views dev?) so I updated to the latest References dev and re-applied the patch but now Japanese titles are not being recognized.

cpelham’s picture

Nevermind...

mlecha’s picture

I've tried patch #25 applied to references module 7.x-2.0-beta3 and 7.x-2.x-dev with no success.

A page with node references in English appear fine.

But in French the translated node references do not appear.
(The rest of the content on the page appears fine in French)

That is the situation that this patch corrects, yes?

I've tried i18n_select module enabled and disabled (using i18n 7.x-1.0).
- with i18n_select enabled node references are blank on the French page
- with i18n_select disabled node references appear in English on the French page.

Any thoughts would be much appreciated.

Any one using this patch with i18n 7.x-1.0 successfully?

Thanks!

idflood’s picture

#26: I think the problem you have is that the references available when creating/editing a node are dependent of the language you are accessing the form. Maybe you can try to add a language switcher block and then change the language. By doing that I was able to select references in french or english.

#33: Are you using the i18n "Synchronize translation" thing on your reference field? Or does it happen when you translate a page?

The patch in #25 is working fine but had a couple of spacing errors. The patch posted above should only fix the spacing issue.

I've found 3 related problems. The issues are described by #26 and #33 I think.
- Nodes displayed in the reference field are dependent of the site language, not the language field. A little ajax update of the reference field would be great.
- When translating a node, references with translation are not selected.
- The i18n "Synchronize translation" doesn't work on reference field.

So, the patch successfully removed the error message, and for what I have tested, basic functionality is working. So it may be better to only fix the error message and create 3 specific followup issues. The title of this issue looks a bit too broad for me.

FiNeX’s picture

What about adding a feature like the "translate and reference" provided by noderelationships in D6?

When you translate a node and the referenced one is not translated the user should be allowed to create on the fly the translation and fill the nodereference field with the just created node.

FiNeX’s picture

I confirm that the referenced node list show only the current language nodes, instead it should returns the nodes of the translated node.

I agree with idflood: when a node is translated and if it exists a translated reference, the translated referenced node should be used.

I didn't applied the patch on #25 which should suggest an existing translation of the referenced node when available... I'll make some more tests.

Thanks

FiNeX’s picture

I've created two test content type:
- Item
- List (with a node reference field which allows to add 0..n Item nodes with the autocompletition widget, but it is the same with a 0..1 / 1..1 field with other widgets)

The D7.8 test site is configured with three languages: EN, DE, IT, and field sync is not enabled. I'm using Node Reference 7.x-2.x-dev and Internationalization 7.x-1.1.

I've created an EN Item node (nid=1) and I've associated to a List node (nid=2), unfortunatly the "language" field on the database is "und" instead of "en". So the patch #25 / #34 cannot work because the "foreach" try to loop on the language code but the $references[] array contains only "und" values:

foreach ($references[$source_language] as $key => $reference) {

Thanks for the attention.

rv0’s picture

#34 seems to work here.

one warning: "63: space before tab in indent."

Daniel Wentsch’s picture

Patch #34 still working on References 7.x-2.0.
Thanks!

C. Lee’s picture

webflo’s picture

Issue tags: +i18n compatibility

Tagging with i18n compatibility.

sahuni’s picture

Sorry, but I have a complex case (i18n 7.1.4)

Content type A is not a multilingual content type and contains a noderef field towards content type B. This content type (A) is showing in all languages.
Content type B is multilingual.

When I display content type A, and I'm in default language, all links to content B link to default language node : OK
When I display content type A, and I'm in second language, node displays no link (just not yet translated content type B nodes). I would like to see all links too, and that these links give the second language type B node.

Is there a solution for such a case?
For me, if it's not possible inside the node but possible with a View (View module), it's acceptable. But for now, I don't succeed.

no2e’s picture

This was marked as a duplicate: #1359778: node_reference_field_prepare_translation needs refactoring (contains a patch)

sensei-master’s picture

Jose Reyero’s picture

Would it be possible to decouple the part to find the translation for a given field value so we can reuse it from other modules?
See #1438394: i18n sync does not use translations for references (New i18n contrib module)

We'd need some API function that looks like this (currently in i18n_sync but to be removed from there):

function i18n_sync_node_translation_reference_field(&$reference_node, $default_value, $langcode) {
  if (isset($reference_node->tnid) && translation_supported_type($reference_node->type)) {
    // This content type has translations, find the one.
    if (($reference_trans = translation_node_get_translations($reference_node->tnid)) && isset($reference_trans[$langcode])) {
      return $reference_trans[$langcode]->nid;
    }
    else {
      // No requested language found, just copy the field.
      return $default_value;
    }
  }
  else {
    // Content type without language, just copy the field.
    return $default_value;
  }
}

Anonymous’s picture

Status: Needs work » Needs review
FileSize
3.26 KB

I've rolled a patch that I'd like some others to have a look at. I've fixed an issue with the patch in #34, as that assumed the language of the source entity would match the language of its referenced nodes (which isn't always the case with this module, as you can have an untranslated node linked to one that's been translated and vice versa).

I've taken some hints from #1359778: node_reference_field_prepare_translation needs refactoring comment #1, and also (cheekily) added an API call to hopefully do what Jose wants to do with i18n sync, mainly because new i18n versions are a good thing in the long term.

Oboklob’s picture

subscribe

azarzag’s picture

I was having the same issue as the the original post since i forgot to check "Switch interface for translating". Once i checked this option all the warnings went away.

rafinskipg’s picture

#46: reference_i18n-1046234-46.patch queued for re-testing.

rafinskipg’s picture

#46 worked for me.
I have multilingual site, Drupal 7.12, References 7.x-2.0, I18n 7.x-1.4

Anonymous’s picture

There were a couple of bugs on my previous patch - the $langcode wasn't being interpreted correctly and the nid value was being nested inside an array with the key 'nid'. Sorry.

Here's a new patch that addresses the above issues.

Anonymous’s picture

#51 worked fine for me. Thanks allot!

Sweetchuck’s picture

When will be added this entry to the "*_field_info" array, in the hook_field_ino() ()node_reference_field_info()) ?
'i18n_sync_callback' => 'node_reference_field_prepare_translation',
Do this modification the i18n module for us?

alexverb’s picture

#51 works for me too.

nunocostapt’s picture

chrisdolby,
#51 works for me too, thank you!

turbogeek’s picture

#51 works great - thanks chrisdolby!

czigor’s picture

Status: Needs review » Reviewed & tested by the community

#51 made the notice go away, thanks!

muka’s picture

#51 works, thank you

Alex Andrascu’s picture

I will look into commiting #51 to dev in the next couple of days. Thanks for the patch Chris.

Alex Andrascu’s picture

Ok #51 commited to dev. Please review after nightly dev build and let's close this.
Thanks
Alex

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 51: reference_i18n-1046234-51.patch, failed testing.

jramby’s picture

Status: Needs work » Fixed

Can I mark this as fixed ? as it is already commited in dev version of the module ?

Status: Fixed » Closed (fixed)

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