Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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
Comment | File | Size | Author |
---|---|---|---|
#51 | reference_i18n-1046234-51.patch | 3.24 KB | Anonymous (not verified) |
#46 | reference_i18n-1046234-46.patch | 3.26 KB | Anonymous (not verified) |
#34 | reference_i18n-1046234-34.patch | 3.41 KB | idflood |
#25 | node_reference_correct_multiple_field_and_prepare_translation_by_checking_potential_references_20110716.patch | 3.33 KB | jmones |
#10 | node-reference-issue-with-content-translation--1046234-10-D7.patch | 2.92 KB | cedric |
Comments
Comment #1
fgmI'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 ?
Comment #2
narwhal CreditAttribution: narwhal commentedSorry, 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.
Comment #3
narwhal CreditAttribution: narwhal commentedBesides, there's the error message thing
Comment #4
sahuni CreditAttribution: sahuni commentedPlease, 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.
Comment #5
nils.destoop CreditAttribution: nils.destoop commentedWe had the same problem, but found the solution.
Multilangual select should be enabled from i18n, then everything seems to work.
Comment #6
oxyc CreditAttribution: oxyc commentedI'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.
Comment #7
webflo CreditAttribution: webflo commentedHi had the same problem with Content Translation. Here is a patch which fix the issue. I hope this is okay.
Comment #8
webflo CreditAttribution: webflo commentedComment #9
webflo CreditAttribution: webflo commentedI am sorry. I uploaded the wrong patch.
Comment #10
cedric CreditAttribution: cedric commentedThank 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.
Comment #11
juves CreditAttribution: juves commentedIt works fine without sync enabled.
Comment #12
joostvdl CreditAttribution: joostvdl commentedPatch #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.
Comment #13
cpelham CreditAttribution: cpelham commentedThe 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
Comment #14
cpelham CreditAttribution: cpelham commentedI 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?
Comment #15
idflood CreditAttribution: idflood commentedsubscribing
Comment #16
Cyberwolf CreditAttribution: Cyberwolf commentedSubscribing.
Comment #17
vasikesubscribe.
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.
Comment #18
cpelham CreditAttribution: cpelham commentedSomething 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?
Comment #19
cpelham CreditAttribution: cpelham commentedRolling 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).
Comment #20
cpelham CreditAttribution: cpelham commentedRolling 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?
Comment #21
mordonez CreditAttribution: mordonez commentedsubscribing
Comment #22
gausarts CreditAttribution: gausarts commentedSubscribing. Thanks
Comment #23
cpelham CreditAttribution: cpelham commentedFrom 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
Comment #24
jmones CreditAttribution: jmones commentedThe 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?
Comment #25
jmones CreditAttribution: jmones commentedHello,
I've adapted patch in #10 by @cedric to the behaviour I posted in #24. Namely:
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
Comment #26
palamida CreditAttribution: palamida commentedPatch #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 ?
Comment #27
mordonez CreditAttribution: mordonez commentedsubscribe
Comment #28
tegerson CreditAttribution: tegerson commentedthx for patch in #25 !
Comment #29
nico.knaepen CreditAttribution: nico.knaepen commentedPatch #25 worked for me!
Comment #30
Cyberwolf CreditAttribution: Cyberwolf commentedsubscribing
Comment #31
cpelham CreditAttribution: cpelham commentedDoes 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.
Comment #32
cpelham CreditAttribution: cpelham commentedNevermind...
Comment #33
mlecha CreditAttribution: mlecha commentedI'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!
Comment #34
idflood CreditAttribution: idflood commented#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.
Comment #35
FiNeX CreditAttribution: FiNeX commentedWhat 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.
Comment #36
FiNeX CreditAttribution: FiNeX commentedI 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
Comment #37
FiNeX CreditAttribution: FiNeX commentedI'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.
Comment #38
rv0 CreditAttribution: rv0 commented#34 seems to work here.
one warning: "63: space before tab in indent."
Comment #39
Daniel Wentsch CreditAttribution: Daniel Wentsch commentedPatch #34 still working on References 7.x-2.0.
Thanks!
Comment #40
C. Lee CreditAttribution: C. Lee commentedPosted #1438394: i18n sync does not use translations for references (New i18n contrib module) to i18n with a workaround.
Comment #41
webflo CreditAttribution: webflo commentedTagging with i18n compatibility.
Comment #42
sahuni CreditAttribution: sahuni commentedSorry, 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.
Comment #43
no2e CreditAttribution: no2e commentedThis was marked as a duplicate: #1359778: node_reference_field_prepare_translation needs refactoring (contains a patch)
Comment #44
sensei-master CreditAttribution: sensei-master commentedComment #45
Jose Reyero CreditAttribution: Jose Reyero commentedWould 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):
Comment #46
Anonymous (not verified) CreditAttribution: Anonymous commentedI'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.
Comment #47
Oboklob CreditAttribution: Oboklob commentedsubscribe
Comment #48
azarzag CreditAttribution: azarzag commentedI 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.
Comment #49
rafinskipg CreditAttribution: rafinskipg commented#46: reference_i18n-1046234-46.patch queued for re-testing.
Comment #50
rafinskipg CreditAttribution: rafinskipg commented#46 worked for me.
I have multilingual site, Drupal 7.12, References 7.x-2.0, I18n 7.x-1.4
Comment #51
Anonymous (not verified) CreditAttribution: Anonymous commentedThere 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.
Comment #52
Anonymous (not verified) CreditAttribution: Anonymous commented#51 worked fine for me. Thanks allot!
Comment #53
SweetchuckWhen 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?
Comment #54
alexverb CreditAttribution: alexverb commented#51 works for me too.
Comment #55
nunocostapt CreditAttribution: nunocostapt commentedchrisdolby,
#51 works for me too, thank you!
Comment #56
turbogeek CreditAttribution: turbogeek commented#51 works great - thanks chrisdolby!
Comment #57
czigor CreditAttribution: czigor commented#51 made the notice go away, thanks!
Comment #58
muka CreditAttribution: muka commented#51 works, thank you
Comment #59
Alex Andrascu CreditAttribution: Alex Andrascu commentedI will look into commiting #51 to dev in the next couple of days. Thanks for the patch Chris.
Comment #60
Alex Andrascu CreditAttribution: Alex Andrascu commentedOk #51 commited to dev. Please review after nightly dev build and let's close this.
Thanks
Alex
Comment #62
jramby CreditAttribution: jramby commentedCan I mark this as fixed ? as it is already commited in dev version of the module ?