Translated title_field replaces node->title with translated value

Can you reproduce this on a clean Title + Entity translation install with no additional module?

Just thought about that. The only idea I've got is something like this:

/**
 * Sync back callback for the text field type.
 */
function title_field_text_sync_set($entity_type, $entity, $legacy_field, $info, $langcode) {
  $wrapper = entity_metadata_wrapper($entity_type, $entity);
  $wrapper->language($langcode);
  $wrapper->{$info['field']['field_name']}->set($entity->{$legacy_field});

  // Ensure the value of the original language is in the legacy field.
  if (($handler = entity_translation_get_handler($entity_type, $entity))) {
    $translation = $handler->getTranslations();
    if (!empty($translation->original) && $translation->original != $langcode) {
      $wrapper->language($translation->original);
      $entity->$legacy_field = $wrapper->{$info['field']['field_name']}->value();
    }
  }
}

Just curious if there was any resolution...

Please try the latest dev of Title and ET.

I am having the same probe. Is this resolved? any patches?

Just to note that with drupal 7.15 or newer, this seems to also be a problem with nodes that ARE in the site's default language. I have a site running 7.15 with six languages. A Node created in english and then translated into another language will have no problems until someone EDITS one of the translations. Then the title of the english node will be overwritten with the translated title. Editing the english title atain and saving is the workaround.

Currently the title module only handles this use case if it's used with an entity form.
I tried to tackle this in a generic way:
The new approach deals with this issue also in the case the term is stored programmatically e.g. by a migration.

I've tested the code extensively on our installations and I've extended the tests as well.
However, this desperately needs a review since the whole thing became more complex than I expected from a first look at the issue.

The only downside I see atm. is, that if you want to store the term programmatically, you've to set the form language using the entity translation handler.
Example:

// Ensure the import language is set.
$handler = entity_translation_get_handler('taxonomy_term', $entity, TRUE)) {
$handler->setFormLanguage('de');

I think I'm running into this as well. We have a migration that runs and updates existing nodes. In the migration I'm attempting to update the title_field values for both English and Chinese, but after title_entity_presave() runs the title_field value that I specifically set gets reset to whatever is in $node->title which is completely unexpected. Is this bug what this issue would cover?

Yes, it seems we are currently addressing field language in the proper way only in title_field_attach_form(), whereas we would need to do the same (only) in the save phase.

I'm having the same problem. I have a node - original language EN, translated to FR. When a rule fires updating the entity for the FR version, it overwrites the title of the EN version. However, if the same rule fires on the EN version, FR doesn't get overwritten.. Tried the patch in #9 - didn't seem to work.

I discovered this bug on 7.x-1.0-alpha4 in combination with panelizer:

* You need a panelized nodetype.
* You need 2 languages.
* Set your interface/page language to the non-default language.

When you edit the panelized node (no matter if you are using ipe or the panelizer tab), the title in the default node-version will be set to the value of the translation.

After updating to 7.x-1.x-dev I am still able to reproduce the bug.

Unfortunately I was not able to apply the patch from #9 to the newest dev! Can someone please reroll it agains the current dev-version?

(Set to major because this bug can destroy the whole integrity of the website)

Maybe related (7.x-1.0-beta2) version: if I perform a bulk operation via Views Bulk Operations module via translated UI, the original title_field changes is populated by the translated value.

The attached simplistic patch title-sync-original-values-back-to-property-1269076-17.patch (created against alpha5!) seems so solve the problem at least when occuring with panelizer as described by axe312 in #15. Can anybody see whether/what side effects may be introduced?

I finally found some time to work on this. I think that attached patch is quite solid and should fix this issue without breaking too much stuff out there. The basic idea is that when saving an entity we should sync back the values from the legacy field to the replacing fields, but only when the active language, i.e. the language originally used to load the values into the legacy fields, matches the entity language. Otherwise we should perform the opposite process and restore the original values into the legacy fields.

The patch also introduces the concept of active language, which previously was hardcoded to the current content language. Now this is just a default that can be changed in any moment. The new test shows how the active language can be used in combination with entity_load() in programmatic workflows. Basically it's just matter of adding a line like the following to switch the language of the values synced into the legacy fields:

<?php
module_invoke('title', 'active_language', $langcode);
entity_load('entity_type', array($id));
?>

Tests pass locally.

Fixed a couple of typos.

+++ b/tests/title.test
@@ -252,19 +254,105 @@ class TitleTranslationTestCase extends DrupalWebTestCase {
+  public function atestFormTranslationWorkflow() {

Hm

+++ b/title.module
@@ -140,7 +140,38 @@ function title_entity_label($entity, $type, $langcode = NULL) {
+  // override the legacy field value with original one, taken form the replacing
+  // field.

Other typos :(

I gave this a visual review. Looks really nice!
I guess the essential stuff was to deal with title_entity_presave(),title_field_attach_presave() and especially title_field_attach_update() to maintain the consistency.
And it's awesome that we've a test case of the programmatic translation workflow now.

The only "concern" I've is that the title module has a weight of 100 - which likely makes the hook title_field_attach_update() the one that's triggered last.
So there's an "inconsistency" for modules that implement hook_field_attach_update() too and are triggered before the title module. And according to the comment in title_update_7001() we can't use a lower weight.
However, I think this is a reasonable risk we can take.

Summary: RTBC

Thanks for the review, peter!

To answer your concern, Title implements hook_module_implements_alter and actually sets things up so that every hook besides a few ones is actually executed first, incuding title_field_attach_update(). See:

http://drupalcode.org/project/title.git/blob/refs/heads/7.x-1.x:/title.m...

That said, before committing this I'd like to have confirmation from people here (ideally all) that the patch fixes their issues.

+++ b/tests/title.test
@@ -252,19 +254,105 @@ class TitleTranslationTestCase extends DrupalWebTestCase {
+    $this->assertTrue($this->checkFieldValues($term, $original_values, LANGUAGE_NONE), 'Term original language correctly changed to the former translation language.');

Wrong assert message

+++ b/title.module
@@ -140,7 +140,38 @@ function title_entity_label($entity, $type, $langcode = NULL) {
+  // need to act on both to ensure the legacy fields are propely handled.

Typo

+++ b/title.module
@@ -140,7 +140,38 @@ function title_entity_label($entity, $type, $langcode = NULL) {
+  // holds a value corresponding to the current content language, as it were

Should be "Current active language"

I realized we were missing field_attach_presave in hook_module_implements_alter...

After some more extensive testing I realized the former approach was not correct as it didn't cover the case of legacy field translations being manipulated on presave. Moreover I found that title_tokens_alter() was calling title_field_sync_get() and thus it was altering the values of the legacy fields potentially during a presave hook execution. I fixed this to just retireve the needed values.

Tests are green here.

None of the tests are being ran by the testbot?

We have issues with the testbots, it seems tests are not recognized: #1900282: Tests fail with "Failed to run tests: run-tests.sh reported no tests were found".

Nope, #27 works perfectly for me.
Do you confirm the exact steps to reproduce your issue in the OP? Just the modules cited there?

patch #27 seems to work here.

Title: 7.x-1.0-alpha5
Entity Translation: 7.x-1.0-beta2
Drupal: 7.20

Found a very annoying bug, but can't track down where/why.
To replicate:

1. install minimal drupal (7.21)
2. install some other modules:
   

   Title (title) - 7.x-1.0-alpha5       
   Entity Translation (entity_translation) - 7.x-1.0-beta2        
   Entity API (entity) - 7.x-1.0              
   Entity tokens (entity_token) - 7.x-1.0              
   Rules (rules) - 7.x-2.2              
   Rules UI (rules_admin) - 7.x-2.2              
   

3. Create a user role "test"
4. Create a Rule: Trigger "on user login" - Condition: "user has role: test"
5. Save

Now, apply the patch, and step number 5 will give you a fatal error.

The attached patch fixes the issue reported in #34, thanks.

Tests still green.

@renat:

I carefully followed the steps you described (btw, I almost always do my manual tests with nodes created in a non-default language) and I cannot find any problem. I think the behavior you are describing in #33 is the desired one: Title should store the original value in the legacy field storage, for instance in {node.title}, and the translations only in the field storage. When loading an entity the translation corresponding to the active language (by default the current content language) is written in the legacy field so that code accessing for instance $node->title can find the translated value.
The goal of this patch is ensuring that the original value is always stored in the legacy storage and that any modification performed to the legacy field is propagated to the corresponding field translation when saving the entity.

The reason probably is that drush uses the default language as current (-> active) language and thus you will always find the value of the corresponding translation in the legacy field. I think the current patch should be able to deal with that just fine.

I will create a last alpha in a few days and then I'll commit #35 if I receive no complaints before.

Last chance to review: I'm going to commit #35 this afternoon.

Committed and pushed #35.

Tentatively marking fixed.

Hello,
Did the patch resolve this issue?
I still have this issue. I had alpha7 installed. And upgraded to the last dev, but still the title is being changed post saving a translation.
I'm using the title token to set a node alias and would like to have the original language alias for all languages.
e.g.: example.com/[node:title] and example.com/es/[node:title]
Currently when adding translation the token [node:title] being changed, I thought only [node:title_field] should change.
Thanks, Yael

hate opening this when:
1. it is closed
2. problem doesnt seem to exist on a vanilla site

but... ughh.,. i have exact same issue as reported here; sadly lots of other modules. i have disabled all the custom coded ones and most of the ones related to translation; but still problem persists.

- site was originally set up for node translation
- switched over to ET and enabled Title module
- edit english (default) version of node and set Title
- edit danish and set title

English title has now synced with the Danish title. I can set EN title back but any time i edit any other language; the EN title gets replaced.

should have been a 10 min task switching this over to ET.. been at this for hours now.. ughhh!!

any hints as to where i could but a breakpoint to see what is changing the title of the wrong field.

started with a backup of site db from this morning and did a less aggressive approach to switching over to ET. simply enabled ET, Title and disabled i18n Sync. and started again, my original node i was testing with seems to be corrupted now; but i created a new node and it seems to be translating fine.

there is some odd issue where the first time i create a new node and pick English; it still gets saved as neutral; then i edit again and set to english again and this time it works.

pretty sure still issues with ET/Title; but possibly cleaner on fresh installs than trying to switcho ver from node to field translation.

Got the issue after upgrading to latest dev version too. Was fixed by applying patch from https://www.drupal.org/node/2098097#comment-9416315.

+++ b/title.module
@@ -642,17 +726,19 @@ function title_tokens_alter(array &$replacements, array $context) {
-      $langcode = NULL;
-      if (isset($options['language'])) {
-        $langcode = $options['language']->language;
-      }
+      // Since Title tokens are mostly used in storage contexts we default to
+      // the current working language, that is the entity language. Modules
+      // using Title tokens in display contexts need to specify the current
+      // display language.
+      $langcode = isset($options['language']) ? $options['language']->language : entity_language($entity_type, $entity);

Commit caused another problem. If you render title using panels everywhere - it is always in default language.
Title is rendered in my panels with ctools_set_page_token()

created a follow up issue https://www.drupal.org/node/2505311

I updated today to the latest -dev version of this module because I faced the problem that the titles got not translated to another language if I used them as field in a view.

Although I updated the problem seems still to persist.

Some people above told to make a clean install. But I can't really start at the very beginning with my site. So is there a trick to get translation of the title field working with views module?

UPDATE

Okay I used the wrong field. In views only the field "Entity Translation: Title" contains the translated node title. But "Content: Title" contains always the title in node's original language. That's a different behavior then with the other fields of a content type which always display in site's current language.

Since we have entity_language() in core we don't need so complex synchronization of the translation values.

Please correct me if I am wrong.

See https://www.drupal.org/node/2542826

A related issue: #2617194: Compatibility with last Title dev code

Another related issue happening when entitycache, entity_translation and panelizer is used: #2768857: Overwritten titles when using entitycache, panelizer and entity_translation modules.

I am facing this issue in my drupal 7 installation any idea how to fix this?

Thanks,
Unnikrishnan B.

@unnikrishnan: Start with updating your Title module to the latest -dev release.

This is still not fixed.

The module is trying to sync between the language that is being saved and the 'active language', which is the language the user is seeing the site in.

Why use language in

title_active_language()

which is the content language (in my case 'en') when I want to save the content in a different language, say 'jp'?

I think the faulty code is in title_entity_presave() now.

@victor.priceutu: Please open a new issue so this can be worked on.

Looks like there are 2 open already, just noticed them:

https://www.drupal.org/node/2844496
https://www.drupal.org/node/1991988