Will the new language aware edit form (branch ml_edit_form) work with taxonomy autocomplete fields? What language will fuel the automplete field for a tagging vocabulary?
The i18n localize functionality (closest to entity translation imho) always shows the default language as does the master branch of entity_translation.
There are several options that would work for autocompleting and saving new terms.

  • autocomplete only terms from the user selected language
  • autocomplete terms from the user selected language and terms in default language if no translation is available
  • autocomplete all terms in all languages
  • save new terms in default language and translate them manually later
  • save new terms in default language and user language and translate the default language terms manually later
  • no creation of new terms

Option 3 for autocomplete and option 1 for saving seams as the safest bet and for a vacabularies without the possibility to create new terms would be so much more better then anything else that is available right now for drupal.
Autocomplete for localized terms in i18n wasn't implemented because the saving process is cumbersome and creates a lot of work. But without this feature assigning tags to content with autocomplete is very contraintuitive.
Will anything of the above be possible with the new interface?

Members fund testing for the Drupal project. Drupal Association Learn more


e_log’s picture

Issue summary: View changes

third option for saving

e_log’s picture

Priority: Major » Minor

If creating new terms is not desired, using a list instead of an autocomplete widget realizes option 2 for display and option 3 for saving atleast if the i18n module is used. Is this possible with entity_translation?

plach’s picture

Priority: Minor » Normal

Term field integration is desired and will be fully supported if possible. I'll have a deeper a look to this issue when starting to work on this feature. Patches welcome meanwhile.

hyperborea’s picture

Any news on that one? Using entity translation and localized taxonomy, the autocomplete field is not showing terms in different languages than the original.

weri’s picture

Is this issue not related to the title module (http://drupal.org/project/title)?

plach’s picture

Yes, somehow it is. We need proper integration for the autocomplete widget.

Merlineus’s picture

I don't know if my issue is related to this. Maybe I should create a new one?

I want to keep 2 separate tags set. One for russian language and one for ukrainian. So tags vocabulary is set to "Translate" mode. Tags reference field widget is set to autocomplete. All works fine - widget shows only tags for translation being added. The only issue is when word is same for both languages. For example "флот" (eng: "fleet"). When I try to add a ukrainian translation for node and write the same word as in russian there is no new term created with ukrainian language, instead it adds referense to the russian one.

@plach could you point me in the right direction of solving this? Thank you.

Merlineus’s picture

Well, I've found very dirty hardcoded fix right now.

This topic http://drupal.org/node/1682714 is pointed me to the isseue roots.
taxonomy_autocomplete_validate() in taxonomy.module didn't respect the term language when checking it for existance.

So this fix is working for my situation right now, but I don't know drupal core and I think it may break taxonomy behavior in any other configuration at all:

<       if ($possibilities = taxonomy_term_load_multiple(array(), array('name' => trim($typed_term), 'vid' => array_keys($vocabularies)))) {
>       if ($possibilities = taxonomy_term_load_multiple(array(), array('name' => trim($typed_term), 'vid' => array_keys($vocabularies), 'language' => $element['#language']))) {
plach’s picture

Title: Language aware edit form and autocomplete » Taxonomy term reference: language-aware widget and autocomplete
valssi’s picture

I have language neutral nodes that have an image field and other fields that don't need to be translated, but I need the term reference field to show the terms even if they are translated.

I think that one option could be showing the terms in the original language if the node is not translatable.

Johnny vd Laar’s picture

I have added a patch to the title module issue queue to fix this for the dropdown until this patch #1944246: taxonomy_allowed_values should use entity_label is added to drupal core.

Owen Barton’s picture

2.16 KB
PASSED: [[SimpleTest]]: [MySQL] 721 pass(es). View

This patch is a rough start at improving the "save" aspect of autocomplete taxonomy - it doesn't do anything with listing.

With this patch, when you create a new term via the taxonomy autocomplete widget, instead of terms getting created in whatever default they are set to, they are created with the language of the parent entity you are editing.

This patch is pretty naive though, and seems likely to have incorrect effects in some configurations. It does work for me in a typical node form though, even when the taxonomy field is inside a field collection.

Owen Barton’s picture

Status: Active » Needs review
Owen Barton’s picture

Issue summary: View changes

saving "new" terms, for better clarification

MXT’s picture

#11 solves my problems (thank you Owen) BUT:

Logically field tag should not setted as "translatable" but this has the (bad) consequence that my editors, after they had inserted their terms, have then to go trough another admin "interface" (taxonomy) to translates all occurrences of new inserted terms. This is unacceptable in my situation (I can't give all "manage taxonomy" permission to my editors)

A workaround is to accept "duplications" of terms in my vocabulary and make the tags field translatable: in this way my editors simply have to reinsert translated terms in node translation page, but at least they do it all in one single "node" interface. (patch in #11 is useful also in this case)

Thank you very much

BarisW’s picture

I tried the patch in #11, but it didn't work for me. I have multilingual options of my vocabulary set to 'Localize. Terms are common for all languages, but their name and description may be localized.'

When I create a spanish node, I get this error

Notice: Undefined index: es in EntityTranslationDefaultHandler->setOriginalLanguage() (line 857 of /var/www/CLIENT/htdocs/sites/all/modules/contrib/entity_translation/includes/translation.handler.inc).

The term is created, but the 'Translate' tab is gone.

Any thoughts?

plach’s picture

candelas’s picture


Since this issue is a blocker for Entity Translation 1.0 https://www.drupal.org/node/1624830 and now plach is working on this, please, test. Also, Entity Translation is asking for a coo-maintainer. I wish I had the knowledge to apply since it is a great opportunity to learn from a senior developer...

Steps to test:

  • In a new demo Commerce Kickstart 7.x-2.37 installation:
    • I have applied the patch in https://www.drupal.org/node/1661348
    • Apply patch #11.
    • Enable Title and Entity Translations modules (There is not the internationalization module installed). The locale module was enabled because of being required.
    • Import Catalan language.
    • Make Blog content type translatable.
    • Make Taxonomy Tags translatable.
    • In Entity Translation settings, set for both (content and taxonomy):
      • the Default language to English.
      • Hide language selector. (if you have previous post that were language undefined (und), you have to assign a language or you will be not able to translate them because there will be not translation tab next to the edit node).
      • Exclude Language neutral from the available languages.
      • Hide shared elements on translation forms.
    • In the blog "manage fields" content type, edit tags and make it translatable
    • Edit/Create and translate one post. Assign new tags in each language
    • Edit/Create and translate one post. Test that previous tags are available.
    • The tags are assigned to English language (the default) in both languages and are accesible in both translations, so it is the same as if they were und.
betoscopio’s picture

Hi, I've upgraded to entity_translation-1.0-beta6 wish includes the patch of the issue #1661348: I18n Taxonomy integration (of the comment above).
After execute the update script it changed some taxonomies (the ones with translated fields) from the "Localize" option to "Field translation".
I don't have the module i18n_select enabled.
When I edit a node with a "Term reference" field with a "Select list" widget independently of the node language it always shows the terms on the list with the name in their original language. (I don't have any term with 'undefined language').

The previous activity seems older, is there any workaround with the current conditions of the module?
Should I post a new issue specific for the entity_translation-1.0-beta6 version?

Status: Needs review » Needs work

The last submitted patch, 11: 1506054-autocomplete-create-inherit-language.patch, failed testing. View results

steinmb’s picture

Status: Needs work » Needs review
Issue tags: +Needs reroll
Parent issue: » #1624830: Plan for Entity Translation 7.x-1.0 release
plach’s picture

Assigned: Unassigned » plach

Working on this

Mikhail K.’s picture

Status: Needs review » Needs work
plach’s picture

I have a mostly working branch in my local environment, I will post a patch for this soon.

stefanos.petrakis’s picture

Great! I could put some work on the tests for this, I didn't see any so far in the branches.

plach’s picture

20.34 KB


You're welcome to work on tests, thanks!

Here's what I have so far, it still needs some tweaks but it should be more or less complete. It's implementing a solution discussed with @yoroy in Vienna. We have two modes, that can be configured in the field settings page: you can either create÷Select terms in the current form language or you can enable in-place translation, in which case on translation forms you get a text field for every term entered in the original language form. If Title is enabled and configured you can then translate every term name from there.

steinmb’s picture

Status: Needs work » Needs review
Issue tags: -Needs reroll
plach’s picture

Status: Needs review » Needs work
Issue tags: +Needs tests
22.2 KB
6.98 KB

A few more tweaks, now we should be missing only test coverage.