Synchronize Entity reference

Same here, having problems with them

I have the same problem.

Hey

I am trying to implement a sub-module for entityreference synchronisation, due we need this feature. Otherwise UX is really bad with translations.

Stay tuuned, will commit when it works, hope someone can help me afterwards with reviewing the code or functionality.

Cheers

Okey

I just had a closer look into the references implementation here, and tried to change everything necessary for the entityreference-field to work.

It looks like it works, but I am not sure in some details. I would love to see someone looking into my code, and help to figure out my marked TODO's in the code.

Especially the translation lookup is using the same as the reference implementation. But it worked out for me.
Nodes, Taxonomy and User Entites were tested successfully until now, please give some feedback how it works for you!

I hope this is fine and I could help here! Here is my patch, any feedback is welcome!
I made a new "sub"-module for this i18n_contrib module!

Cheers Cyclodex

Patch seems to work nicely sync'ing ER fields! Thanks.

I am thinking for a complete solution it would be good to also form_alter when a translation is added so that the translated target_id's are placed in the form instead of the originals.

Nice!

Yes, that was exactly what I needed too! Boring empty or wrong linked ER-Fields when first translation is created.
So I just extended this now, please add the last hook (i18n_entityreference_field_attach_prepare_translation_alter) or apply the patch again to the normal version.

Again, feedback is welcome!

Cyclodex

Awesome...patch works great. Thank-you so much!!!

In looking at the code I noticed you use _field_invoke_get_instance(). I am not a code purist by any means, but I always thought that it was not advised to use the _functions as they were 'private'. Just wondering...thanks again!

Hmm yea, as you can read in the comment part, I took some parts from a sandbox module, and tried to improve it.
So this probably means that I also have to check for a replacement of this function...
Thanks for feedback!
I am also just learning and hope I can help the community/drupal with some effort.

Hmm will have to check if I should use something like that:
http://api.drupal.org/api/drupal/modules!field!field.info.inc/function/field_info_instances/7
not sure yet.

I also think the title should be replaced with some other more meaningful text.
"i18n Support for Entity Reference"?

I am not sure how many code should go in here, and what should be fixed by the module itself... So the language_prepare hook could also be implemented by the entity reference field itself, but this way we can provide a clean module extending this functionality.

Jose: I would like to hear from you, if this would be fine for you, to have such a module in your i18n_contrib or if we should fix that somewhere else!

Any feedback is appreciated

Okey, this seems to be the correct function call.
Using this gives me the same information, so I can even remove some code lines too.

Here is the latest version of this patch.

Would be nice to hear some more feedback also from other people!

Cheers

The synchronization of entity reference field across languages for multilingual content-types works great with the patch applied.

What does not work (but i am not sure if this can be achieved with the patch) is the following.
My test-setup is quit easy... i have two content-types: publication and author.
The publication type is language-independent, since everything is published in english.
The author is language-dependend, since every author's biography should be viewable in multiple languages.
Now i have two entity references... from author to publication and from publication to author. I use the corresponding entity reference module (http://drupal.org/project/cer) to keep the links synchronized.
And to keep the authors synchronized across the different languages i use the patch available here (which works great so far).

But my problem starts here:
If a connect a publication to authors, i have to do that for every language (in fact there are multiple checkboxes available for one author... for one field for every language). I do not believe that this makes sense. I would expect one checkbox for every author (no matter how much languages are available), since the field is synchronized in the author content type. I guess that i could get around the multiple-checkbox issue using a view, but then things don't get synchronized correctly. For example: if i connect publication "pub" to author "a.en" then the publication is not listed for author "a.de" or author "a.it" (which it should since the field is marked to synchronize in the author type).

Could things get fixed in this module to get my setup to work?

Hmm you are not using entity translation for the users ?
The other question would be, if you really need to have linked publication to author and author to publication. Would it not be enough to only have one relation?
It depends for what you are using them but normally I think 1 relation is enough. But perhaps you do this for usability improvement or similar.

Anyway, that you have multiple checkboxes for one author seems also to be a problem, something not configured optimal...
But for further checks I would need a lot more information.
Are you using entity translation on Nodes? Did you check admin/config/regional/i18n/select
Or download the latest entity translation (if you are using it) there are some new settings available in admin/config/regional/entity_translation

Its really hard to find a solution for multilingual stuff, so not sure if I can help you further... Also fighting with a lot of stuff.

By now i use content translation (not entity translation).
In fact the two-way reference is for usability improvements only (so it would be enough to have one translation only, but it is quite complicated to switch to the user and link a just added publication - it would be much better, if the link could be created when adding the publication)

Is "entity translation" somehow preferred to "content translation" now? Are there major differences?
Let me know if you need more information...

Hmm I am not a pro, but using it. I don't think its just "preferred", as said it really depends on your know how and setup of the website.

Did you check your translation settings ? Are the checkboxes enabled for select langauge dependent content ?

I managed to get get my setup to work using the entity translation module.
Thanks for the hint :-)

However, should we also get this to work using node translations? I guess that this isn't the expected behaviour if the entity reference field is synchronized across different languages.

Since i fixed my problem things lost priority (at least to me), but i guess that it is always good to meet user expectation.

As I said I am not sure how your settings are, I can only reproduce the issue when disabling the language selection for nodes...

Just take care due ET could lead to some other problems, like the search or similar. But for me it does also a great job. :)

Cheers

First of all thanks Cyclodex for the work you've already put into this. With a 1st glance at the source, your solution seems simple and effective!

However, I seem to have run into a situation where I still get some troubles. I'm not sure if it is within the scope of this module, or if I should try something else, but if you have any thoughts on how I could fix the problem, it'd be greatly appreciated!

The situation is as follows:

- I've got a node_type 'course', which can reference one or more nodes of type 'course_chapter'.
- I've got another node_type 'course_chapter', which can reference one node of type 'course'.
- The entityreference fields are synced using the "(Entity)Reference Field Synchronization" module.
- Translation of the reference fields are synchronized for both node_types.
- Translation is enabled for both entityreference fields.

- I've got a node A1 of type 'course', written in english.
- I've also got a node A1t, which is a translation A1 of, written in dutch.
- My interface language is set to English.
- My language settings are such that the content language should follow that of the interface

- I create a new node B1 of content_type 'course_chapter', and reference it to node A1 of node_type 'course'.
- I open the translation type of node B1 and choose to make a translation in dutch (lets call it B1t).
- The form to make B1t shows the english node A1 in the reference, but not the dutch A1t.
- I write translation B1t and choose to reference it to A1 (the only available option, right node, wrong translation).

The end result is now:
- A1 has a reference to B1
- A1t has two references to B1t
- B1 has a reference to A1
- B1t has a reference to A1t

So i guess my questions would be:
- Do you have any idea why a double reference to B1t might be generated? Is it anything I can fix within the module you prepared?
- Do I have any flaws in my configuration causing this problem?
- Is there a way to show dutch entities in the entityreference field when writing a dutch translation, regardless of the interface language?

Hey, I tried to follow you and made a similar example to check the behaviour you described.
For me, it worked finally without any issues - so it looks.

But to get to the point which is sure a problem, that your referenced nodes are not in the same language as your creating or translating node!
Let's check your setup now, perhaps we will find the problem this way.

What do you have here: admin/config/regional/i18n/select
Is "Select nodes by language" enabled?

Otherwise not sure what the problem could be :(

Note: You are looking for A > B , B > A references, there is this "cer" module which I never tried out.

Cheers!

The patch in #9 works like a charm! Thanks very much Cyclodex and i hope it could be included in the release.

@Cyclodex,

I was using content_translation at the time. I'm pretty sure "admin/config/regional/i18n/select" > "Select nodes by language" was enabled, but I can't be 100% sure.

I think the problem I had was related to content_translation, possibly in combination with some other wrong configuration settings for language fallbacks and content language detection...

Either way, I have switched to entity translation now, and all my translation synchronization issues have completely disappeared. Now I can just specify for particular fields to be untranslatable, which solves many, many problems.

Thanx for taking the time to try and reproduce the problem!

Changing therefor the status, I also hope someone can take this into the next version/release...

The module looks good overall, though it has one important issue: It will just work for node references atm, not for other types of entities.
I see you commented it in the code :-)

+    // TODO: Not sure if translation_node_get_translations is the correct one, is there a special one for entities ?
+    if (($reference_trans = translation_node_get_translations($reference_node->tnid)) && isset($reference_trans[$langcode])) {
+      return $reference_trans[$langcode]->nid;
+    }

So before adding the module we should:
1. Add proper translations per entity type. I don't think we have a generic API for that but we could consider it as an adition for i18n_translation module, at least for know entities (node, taxonomy...)
2. Skip it for 'unknown' entity types.

Optionally you can add it into the module name or description (the fact that it only translates node entity references), but still we'd need (2) for not causing major bugs.

@Cyclodex,
I've added you as a module maintainer for i18n_contrib, for you to be able to commit (and maintain) this module when it's ready.

Thanks for your feedback Jose!

OK, I finally found some time to go forward with that. And I tried different configuration set-ups to check what I already support and what does not work.

What I have seen so far is, that there is only node & taxonomy entity types which can have different id's over translations. So both seems now to work with my implementation.

• Node using the "basic" content translation mode
• Taxonomy using Translate-mode

I am not sure but the user entity type is not able to have translations over different id's, am I correct? (at least I don't know it). I assume that the only way to have translation on User entity type is entity translation.

So user, and every other custom entity type seems to have only one ID, which should work too with this "Synchronize entity reference"-module I just (commited).
This seems also be true for entities without translation enabled. I mean you could reference also an entity which is not translatable.

Support/Testing/Feedback

But because it is very difficult to check each use case and there are a lot, this really needs more testing and feedback from others! I really hope I could help out here but it was not easy for me.
I also hope the commit to the module was all correct, because it was my 5th commit to drupal projects :)

Hi

I have this little issue:

This new submodule works excelent for me, just a little problem: Lets say I have 2 content types: Athlete and Sport, both with multilanguage support (content translation), Athlete is entity reference related to Sport (no back reference). I first created Athlete1 and Sport1 and reference Sport1 to Athlete1, then when I translate Athlete1 to Spanish (new node: Athlete1ES) obviously Sport field doesn't change because Sport1 has not been translated yet. However after saving new node Athlete1ES, I decide to translate Sport1 to Sport1ES, when I edit Athlete1ES, I would expect Athlete Sport field with "Sport1" to change to "Sport1ES", but it doesn't.

Thanks for your feedback!

I see what you mean, but I have a question. Did you try this also with references field (the other one not the entity ref one) too? How is it doing there, I think this will be the same case?!

I think this case would be more of a further feature, to update all nodes which do have a link to this node which now has a new translation. Not sure so, but I see your point.

Any other suggestions? And as I already mentioned, how is references module handling this case ?

After fighting a wile, I found that it was my entity reference field synchronization that was outputting this error:

PDOException : SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'field_thema_target_id' cannot be null: INSERT INTO {field_data_field_thema} (entity_type, entity_id, revision_id, bundle, delta, language, field_thema_target_id) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6), (:db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13); Array ( [:db_insert_placeholder_0] => node [:db_insert_placeholder_1] => 54 [:db_insert_placeholder_2] => 54 [:db_insert_placeholder_3] => page [:db_insert_placeholder_4] => 0 [:db_insert_placeholder_5] => ru [:db_insert_placeholder_6] => [:db_insert_placeholder_7] => node [:db_insert_placeholder_8] => 54 [:db_insert_placeholder_9] => 54 [:db_insert_placeholder_10] => page [:db_insert_placeholder_11] => 1 [:db_insert_placeholder_12] => ru [:db_insert_placeholder_13] => ) in field_sql_storage_field_storage_write() (line 451 in /modules/field/modules/field_sql_storage/field_sql_storage.module).

disable it, made the error vanish.

Did that happen to the 7.x-1.x-dev or 7.x-1.0-alpha1 ?
If it is a general bug and not related to the dev changes, please open a new issue.
Also please report a complete/correct issue, when does it happen , how to reproduce etc.
Perhaps try to re-install and check again.
With your provided information we have no chance to check this, thanks.

Hello,
this post mentions "Version 7.x-1.x-dev" but it's true better mention it to be sure ;-)
But voilà, on my module listing page it says 7.x-1.0-alpha1+1-dev :-)
Enough for the (bad) joke.

Sorry not to have been more precise. I did retry just now, and ... it works.

I've made also some changes this morning, so it's maybe more related to this module. I say that because I had to change it for this module and after that synchronization on my field did work.

I also thought that maybe it didn't work because of a custom field I've develop. But this one I manage to take it off the cycle of synchronization, thanks to the hooks (hook_i18n_sync_options_alter() and hook_i18n_sync_translation())

All of this is a bit presumptuous and only thoughts on what may have caused my PDO, because I'm in plain development of the website and I change module, patches, code and all, very often trying to solve different issues.

Finally, everything's ok (for) now concerning entity reference synchronization, not to say that it works also for translations.

Thank you for your time and module.
Have a nice day.

Hello, It's me again :-)
I talked to fast. Here's my configuration:

• D7.22
• i18n 7.x-1.8
• i18n_contrib 7.x-1.0-alpha1+1-dev

and all modules up-to-date

and 2 languages (+english): French and Russian. French is the default language, English is disabled.

The thing is: NodeFR and NodeRU are translations. If I edit NodeRU, everything goes well, if I edit NodeFR, I got the PDOError mentioned before... So that's the way to reproduce the error I think. Trying to modify the node in the default language. For info, my entity reference field references taxonomy terms.

The strange thing is that I've just uninstalled i18n_entityreference module and everything is fine and synchronizing in both languages... The answer is maybe in what you say in i18n_entityrefernece.module: * Entity types in general do not have different id's as they normally use entity translation (if enabled) and I have entity translation enabled for this field.

(I've attach the PDOError for info)

thanks again.

Okey so I the problem appears on entity translation enabled fields and i18n_entityreference is enabled and you modify the node in default language. I will need to check this, thanks for the feedback!