Terms won't translate

ominds: did you managed the taxonomy terms to be translated? Becouse I can't.
I have:
Drupal: 7.7
taxonomy_menu: 7.x-1.2
i18n: 7.x-1.1

First of all, here is what I did to have taxonomy terms translated.
1. Added i18n module to my site with one language (FR) at the beginning. Site language is chosen by url - subdomain.
2. Added next language (EN), french as default as it was.
3. I wen to my taxonomy used in menu and saw options:

• (this was checked) No multilingual options for terms. Only the vocabulary will be translatable.
• (changed to this one) Localize. Terms are common for all languages, but their name and description may be localized.
• Translate. Different terms will be allowed for each language and they can be translated.
• Fixed Language. Terms will have a global language and they will only show up for pages in that language.

4. Now, happy that my terms will be translated and I don't need to create new taxonomy terms I translated several to test it. I've edited term, saw that there is button "Save and translate", so click it. Then drupal hold me on this page and asked to fill section: Relation -> Parents. It was empty. Weird, I thought, becouse it should be just translation of term, not new term with parent setup. But I chosed same level and saved, on the next page added translation of term.
5. When I refreshed frontend there was no changes at all. Still menu was in french and my translated earlier term was not translated.

I can't pick other options becouse user can't have 3 fields-each-in-different-language-and-bunch-of-categories-to-pick. It can't be one HUUUGE field with all categories in 3 languages. It must be translated. And I have no idea how to do it.

I can provide more infos if anybody would like to.

I even don't know where I should look for it. In wich module: taxonomy_menu, taxonomy_translation, i18n, string translation...? Please help.

I've the same problem, term are well translated in the backend but they still display in english (default language) in the frontend.

Subscribe. I have the same problem. The translated terms are only shown in the website default language, this applies to the front-end, the tags autocomplete and views. This is very disturbing.

Thanks!

We've also experienced the same problem.
At first, we had set-up our taxonomy vocabulary without any multilingual configuration and then added some terms. It seemed that when enabling the i18n Taxonomy translation module and setting up the multilingual settings per vocabulary to 'Localize' it wasn't possible to translate the terms that where already added before the enabling of the module.
The exact problem was that the tables i18n_string and locales_source did not contain the records of the already existing terms. After adding these records, it was possible to translate the terms.

I cannot confirm the solution by #6.
Also terms that where created after enabling the module and where translated did not show.

The only non-optimal solution is change the Taxonomy translation setting to Translate in stead of Localize.

Option "Translate" works as expected, however "Localize" would suit my needs better.

Same Issue here. Can't get translated terms to show up in the term view with term translation being set to "Localize"

If making these kind of changes, try 'Translate interface', 'Strings' tab and refresh the taxonomy text group.

issue still exist...tried #9 but no changes

I can translate the terms but when I use them they won't show the translations.....anyone else some ideas?

term translation being set to "Localize"

Same problem here. I am using the 7.x-1.4 version. Translated taxonomy terms are only displayed in the back-end, in the front-end the default language is used. Tried #6 and #9, none of them worked for me.

I have the same issue, but also after enable the localize option in the Vocabulary the configuration is not recognized and the traslation tab in the terms doesn't diplay. After some debugging the reason is related to the i18n_mode when retrieved by i18n_taxonomy_vocabulary_mode function taxonomy_vocabulary_load doesn't add in the entity_load query the field '18n_mode'. So here is a proof calling only that function in a D 7.12 installation with the last i18n dev release:

/flamenco/www (master): drush eval "var_dump(taxonomy_vocabulary_load(3));"
object(stdClass)#247 (8) {
  ["vid"]=>
  string(1) "3"
  ["name"]=>
  string(6) "Cities"
  ["machine_name"]=>
  string(6) "cities"
  ["description"]=>
  string(35) "Main cities to classify the venues."
  ["hierarchy"]=>
  string(1) "0"
  ["module"]=>
  string(8) "taxonomy"
  ["weight"]=>
  string(1) "0"
  ["rdf_mapping"]=>
  array(3) {
    ["rdftype"]=>
    array(1) {
      [0]=>
      string(18) "skos:ConceptScheme"
    }
    ["name"]=>
    array(1) {
      ["predicates"]=>
      array(1) {
        [0]=>
        string(8) "dc:title"
      }
    }
    ["description"]=>
    array(1) {
      ["predicates"]=>
      array(1) {
        [0]=>
        string(12) "rdfs:comment"
      }
    }
  }
}
 

The field 'i18n_mode' is not retrieved so I add it explicit with query alter:

function i18n_taxonomy_query_taxonomy_vocabulary_load_multiple_alter($query) {
  $query->addField('base', 'i18n_mode');
}

Then reset the cache and execute the function again:

drush eval "var_dump(taxonomy_vocabulary_load(3));"

object(stdClass)#273 (9) {
  ["vid"]=>
  string(1) "3"
  ["name"]=>
  string(6) "Cities"
  ["machine_name"]=>
  string(6) "cities"
  ["description"]=>
  string(35) "Main cities to classify the venues."
  ["hierarchy"]=>
  string(1) "0"
  ["module"]=>
  string(8) "taxonomy"
  ["weight"]=>
  string(1) "0"
  ["i18n_mode"]=>
  string(1) "1"
  ["rdf_mapping"]=>
  array(3) {
    ["rdftype"]=>
    array(1) {
      [0]=>
      string(18) "skos:ConceptScheme"
    }
    ["name"]=>
    array(1) {
      ["predicates"]=>
      array(1) {
        [0]=>
        string(8) "dc:title"
      }
    }
    ["description"]=>
    array(1) {
      ["predicates"]=>
      array(1) {
        [0]=>
        string(12) "rdfs:comment"
      }
    }
  }
}

This resolve the issue of lost the translation tabs and localize configuration but still I don't see the terms translated in the front end. Probably could be that I'm displaying the terms with a terms view and that could be not supported yet? I need to show a block with a list of cities that are terms so I'm creating a View with that terms but doesn't localize when I switch language.

Here I provide a patch to resolve the i18n_mode field issue that could be a reason to won't be able to translate terms. For all the developers that are trying to see the terms translated in a view I alert you that the i18n_taxonomy doesn't support this and you will need to install http://drupal.org/project/i18nviews and change all your views that display terms entities to use the special handlers (translate) for field name and description. Not sure if this could work with other fields because there are only few views fields handlers that are implemented in i18nviews:

• i18nviews_handler_field_taxonomy_term_description.inc
• i18nviews_handler_field_taxonomy_term_language.inc
• i18nviews_handler_field_taxonomy_term_name.inc
• i18nviews_handler_field_term_node_tid.inc

Probably if you have other fields you will need to create a new field handler.

@citlacom: Thanks a lot for mentioning i18nviews. It saved my day ;-)

@citlacom,

I don't understand how that field can be missing because it is added to the schema by i18n_taxonomy.

Question: Are you using latest Drupal core?

@Jose Reyero Yes I'm using the latest Drupal core 7.12 and I accept that is weird but it happened. I had been debugging with Xdebug and the problem is that every time the schema is cached it doesn't add altered fields as this case. I never get an explanation of why it doesn't cache correctly the schema. Probably could be a conflict with other contrib module so let's see if other people have the same issue in that case my patch could resolve the problem adding the field explicit to the entity_load query.

Warm regards.

After looking at the code I think the only chance this may happen is some other module hacking around the schema, and either calling drupal_get_schema() really (really) early in the bootstrap or using drupal_alter('schema'..) too early too.

See http://api.drupal.org/api/drupal/includes!bootstrap.inc/function/drupal_...

(All install files are included. Though Drupal core way of handling this, when we not having module.inc yet I'd call it a bug too)

So please would you take a look a your module list..?

Closing, no follow up.