Term reference field on node edit fails to show translated taxonomy terms when Taxonomy term selected as a Translatable Entity

I think this is a duplicate of #1506054: Taxonomy term reference: language-aware widget and autocomplete.

reevaluated the issue as a problem with Entity Translation

I had same problem and struggled with it for a while until I came across this post: http://drupal.stackexchange.com/questions/29673/limit-taxonomy-display-i... which suggests some possible workarounds.

First, here's the scenario in which my problem occurs:

- vocab with term title replaced as an entity;
- ability to add terms in specific language;
- ability to translate those terms into a different language;
- term reference field added to content type;
- field set to be translatable;
- but all terms, irrespective of current language, displayed on /node/add forms;

In the end I used https://drupal.org/project/term_reference_tree and did as follows:

- created a "translated entity aware" view (add relationship "(node) Content: Entity translation: translations" and filter to "(Translations) Entity translation: Language (= Current user's language)");
- set my term reference field to use term_reference_tree widget;
- set some (newly available from the widget) options, such as which view to use, by editing the field;

Now when I go to /node/add the language I am in is considered the language to offer terms in (where they exist). This does have some limitations, but for my purposes its good enough :)

@ippy
I tried all other scenarios and seems yours is the best solution at this moment

however

I am getting to a point were I have the view display correctly translated terms for each language
but when the widget presents it in the node/edit the translations they are not displayed at all
only the original terms when viewing the souce language are displayed

if it makes any difference the LABEL of the vocabulary is untranslated even though I have it translated

a little more light on how you created the view might help

I crated a term reference view with relationship: Taxonomy term: Entity translation: translations
with term id include as term reference tree widget wants and at the level of the view seems to work...

@ippy @everyone
anyone still looking for a solution
http://drupal.org/project/entityreference
lets you choose term references and it allows you to do so with the use of a view
worked great

I ran into the same problem, think it is caused by the Multilingual select (i18n_select) module and might have a solution. This is our situation:

• We use the Taxonomy translation (i18n_taxonomy), Entity translation and Title modules to translate taxonomy terms.
• For our taxonomy vocabulary the i18n setting is Localize. Terms are common for all languages, but their name and description may be localized. The taxonomy_vocabulary db table tells us the vocabulary's language is UND and i18n_mode is 1.
• We created terms in Dutch (NL) and translated them to English (EN). The taxonomy_term_data db table tells us the terms' languages are Dutch.
• We use Drupal's default term reference field on one of our entity types.

When we create / edit a node in the term's language (NL), all terms show up in the term reference field, but when creating / editing a node in a different language (EN), the field shows an empty list though the terms are translated.

After some digging around I found out this was caused by a condition in the db query that retrieves the taxonomy tree. This condition checks whether the term's language is the current language or UND. Since we use localized terms for this vocabulary, we do not want this restriction.

I think the problem lies within Multilingual select's i18n_select_check_query() Entity translation getting along with Multilingual select:

1. On the node edit form the options for the taxonomy reference list are defined by i18n_taxonomy_allowed_values() which calls taxonomy_get_tree().
2. taxonomy_get_tree() adds the term_access tag to the db query when generating the taxonomy tree that it returns.
3. i18n_select_query_term_access_alter() uses this tag to add the language condition to the query, but asks i18n_select_check_query() for permission.
4. i18n_select_check_query() does not check the vocabulary's i18n_mode.

It wouldn't be that hard to write a patch to fix this, but since I am not sure whether I am on the right track or not, I wrote a workaround that removes the condition from the query if necessary. This workaround works great for us so far and could possibly be used as a base for a patch.

If you guys can confirm whether this seems to be the problem, we should create an issue for the Multilingual select module and close this issue.

/**
 * Implements hook_query_TAG_alter().
 *
 * Problem: "Term reference field on node edit fails to show translated taxonomy
 * terms when Taxonomy term selected as a Translatable Entity".
 * See https://drupal.org/node/2028225
 *
 * About working with the query object, see https://drupal.org/node/310077.
 */
function YOURMODULE_query_term_access_alter(QueryAlterableInterface $query) {
  // If the query has been altered by the Multilingual select module.
  if ($query->hasTag('i18n_select')) {
    // Get reference to array with query conditions.
    $conditions = &$query->conditions();

    // Iterate through query conditions.
    foreach ($conditions as $key => $condition) {
      // Check if condition is an array with a correct field and value.
      if (is_array($condition) && isset($condition['field']) && is_string($condition['field']) && isset($condition['value'])) {
        // Get field name without db prefix.
        if (strpos($condition['field'], '.') === FALSE) {
          $field = $condition['field'];
        }
        else {
          list($table, $field) = explode('.', $condition['field']);
        }

        // If vocabulary condition, load vocabulary so we can check it's i18n
        // setting.
        if ($field == 'vid' && is_numeric($condition['value'])) {
          $vocabulary = taxonomy_vocabulary_load($condition['value']);
        }
        // If language condition, get key to condition so we can optionally
        // easily remove the condition.
        elseif ($field == 'language') {
          $language_condition_key = $key;
        }
      }
    }

    // If the language condition key and vocabulary's i18n_mode are set and
    // the i18n_mode is set to none or localize. Other options are
    // I18N_MODE_TRANSLATE, I18N_MODE_MULTIPLE and I18N_MODE_LANGUAGE (see
    // i18n_translations module), but I do not know whether to add them.
    if (isset($language_condition_key) && isset($vocabulary->i18n_mode) && 
      in_array($vocabulary->i18n_mode, array(I18N_MODE_NONE, I18N_MODE_LOCALIZE))) {
      // Remove language condition.
      unset($conditions[$language_condition_key]);
    }
  }

  // dpm((string) $query);
  // dpm($query->conditions());
  // dpm($query->arguments());
}

In the issue queue for i18n I found #1868418: Taxonomy terms dont work as expected in multilingual environment which refers to i18n's Compatibility with contributed modules which states:

Entity Translation
Internationalization and Entity Translation are compatible, though for each content type you will need to select one or the other, with one exception:
Multilingual select (i18n submodule) is not compatible with Entity Translation enabled nodes, they will be filtered out randomly from pages and menus.

Though I could not find any elaboration on this, I think our problem is not Entity Translation related per se. Another similar (unsolved) issue is #946100: "Localize terms" vocabulary selectable only for nodes in default or original language for D6 from 2010.

I just tried a clean install with the Taxonomy translation module instead of Entity translation to find the differences in db storage. Independently of the site's default language and i18n's string source language at admin/config/regional/i18n/strings, terms always seem to be stored in the db with an "und" value for the language field where the Entity translation module stores langcodes. So I think it is up to Entity translation to play nice with Multilingual select (i18n_select).

Two solutions:

1. The best solution might be to alter the query as done in my previous post, since it does this accordingly to the individual vocabulary i18n settings.
2. Another way of avoiding empty term reference lists when using Entity translation for terms might be to uncheck the "Select taxonomy terms by language" checkbox at admin/config/regional/i18n/select. I have not tried this thoroughly yet, but it seems a great quick fix when not using Entity translation on one vocabulary and Content translation (i18n) on another.

Running into the same problem. Found this: http://drupal.stackexchange.com/a/64666

It may be that this solution is too heavy since it involves loading each term to find the translation, or perhaps that is offset by caching somewhere.

We also faced the same issue and came up with a working solution.
Inside our custom module , we implemented hook_form_alter and re-created the taxonomy input fields once again.
Here my modules's name is "mymodule", the content type having taxonomy term reference fields (field_myfield1', 'field_myfield2', 'field_myfield3' and so on) is "my_content_type".
Here follows the working example.

<?php
/* 
 * For fixing wrong translation of in node edit form.
 */
function mymodule_form_alter(&$form, &$form_state, $form_id){
  if($form_id == 'my_content_type_node_form') {
    // Fields with wrong translation in node edit form.
    $taxonomy_fields = array('field_myfield1','field_myfield2', 'field_myfield3'); 

    foreach($taxonomy_fields as $taxonomy_field){
      foreach($form[$taxonomy_field]['und']['#options'] as $key => $value){
        if($key != '_none'){
            $term = taxonomy_term_load($key);
            $form[$taxonomy_field]['und']['#options'][$key] = $term->name;
        }
      }
    }
  }
}
?>

#7 2. is an incomplete solution since the list always comes up in SOURCE language regardless of the interface language even though admin/config/regional/entity_translation "default language" is set to "current language" (but this might be an irrelevant setting)

modified #9 to accommodate for hierarchy within the vocabulary

this is just a workaround until entity_translation properly supports taxonomy terms select

/*
 * For fixing wrong translation of in node edit form.
 */
function mymodule_form_alter(&$form, &$form_state, $form_id){
  if($form_id == 'my_content_type_node_form') {
    // Fields with wrong translation in node edit form.
    $taxonomy_fields = array('field_myfield1','field_myfield2', 'field_myfield3');
    foreach($taxonomy_fields as $taxonomy_field){
      foreach($form[$taxonomy_field]['und']['#options'] as $key => $value){
        if($key != '_none'){
            $term = taxonomy_term_load($key);
            $ancestors = count(taxonomy_get_parents_all($term->tid))-1;
            $prefix = "";
            for($i=0;$i<$ancestors;$i++)
              $prefix .="-";
            $form[$taxonomy_field]['und']['#options'][$key] = $prefix ." ".  $term->name;
        }
      }
    }
  }
}

solution above does not seem to work

This module helps resolve this problem
https://www.drupal.org/project/translated_entityreference
but not with select list (only autocomplete widget)

EDIT:
to use above mentioned module properly
I think you need to disable
"Select taxonomy terms by language"
in admin/config/regional/i18n/select

I don't know about other translation methods, but using title's dev version which includes fixes #1920096: Title incompatibility with the entity reference widget, term names are properly translated (using entity translation, I haven't tested for 18n)

so this is possibly a related issue

I am able to pay some hundred Euros to someone able to fix this.
This is at least major since entity translation is literally ruining my sites.

Hundreds of doc pages and issues saying different things, dev versions trying to work together, trials & errors on the site that are never easy and will cause the need to recreate all references or translations when changing a module or configuration between i18n and ET.. this is a nightmare.

I can't stand it anymore, please fix this.

Well, I also had this issue and I tackled it down as well as I could, which let me to post this:

#2418629: Make taxonomy_get_tree load entities by default

If you don't want to read it all, skip to the last 3 paragraphs, where the 'fix' is proposed. It's basically a matter of changing a default parameter to TRUE in the taxonomy_get_tree() module in core's taxonomy module. Sadly, this being a v7 core issue related to internationalization and adding a bit of overhead, I don't expect it to be implemented.

I also had this issue, I resolved it by updating the contrib title module to the 7.x-1.x-dev version instead of using 7.x-1.0-alpha7.

Hope this helps!

@Fons Vandamme: really, only updating title module safed the issue with terms showing in original language on the node/add node/edit forms? Nothing else?

thanks,
slowflyer

@Fons Vandamme and @slowflyer no its not working only by updating module. While using latest version of module it still shows original values of terms in node/add or node.edit forms. Any solution you guys found ?

Thanks!

Yep! Use Entity Reference Field

Sorry, the comment I wrote wasn't meant to be posted on this issue.

I can confirm having the same problem.
One solution is to disable $query->addTag('term_access'); in function _term_reference_tree_get_children, that will not run i18n's language control.

But won't run any other term access hooks as well. Warned.

My temporary workaround:

/**
 * Implements hook_query_alter().
 */
function MYMODULE_query_alter(SelectQuery $query) {
  if ($query->hasTag('term_access')) {
    $conditions =& $query->conditions();
    foreach($conditions as $k => $condition) {
      if (isset($condition['field']) && $condition['field'] == 't.language') {
        unset($conditions[$k]);
      }
    }
  }
}

This will remove the i18n language check from term_access tag.

I would suggest that the module also add some specific tag to the query, so at least we could add that to the conditions as well.

#7 solution 2 is now letting me sleep well in the nights. Thank you @lmeurs.

It is not the perfect solution, but at least I can save the translated content without lose the original values for non-translatable fields.

It is solution:
https://www.drupal.org/project/term_reference_tree

Altering a form and fixing filed by field is not scalable. A better way is to fix the widget everywhere is used. Let me show you an example on how to overcome this problem on a Entity reference field targeting Taxonomy terms and using a BUTTONS SELECT widget. This solution requires i18n module:

/**
 * Implements hook_field_widget_OPTIONS_BUTTONS_form_alter().
 * Passes all entityreference to taxonomy terms option labels thorugh i18n translation function.
 */
function MYMODULE_field_widget_options_buttons_form_alter(&$element, &$form_state, $context) {
  $field = &$context['field'];
  $is_entity_reference = ($field['type'] == 'entityreference');
  $is_taxonomy_term = ($field['settings']['target_type'] == 'taxonomy_term');

  if(!($is_entity_reference && $is_taxonomy_term)) return;

  $options = $element['#options'];

  if ($options['_none']) unset($options['_none']);

  foreach ($options as $tid => &$name) {
    $label_location = 'taxonomy:term:' . $tid . ':name';
    $element['#options'][$tid] = i18n_string_translate($label_location, $name);
  }
}

More info on this hook:
https://api.drupal.org/api/drupal/modules%21field%21field.api.php/functi...