Taxonomy terms are not translated in content create/edit form

+1 -- if you need users who don't speak your site default language to contribute, choosing the right taxonomy is essential, and only possible if they can actually understand the terms. Languages are too easy to misinterpret.

subscribing, also in v7.x-1.1

I found why!

Method field_sync_field_status (in modules/field/field.module) (which is executed on clear cache/cron) clears informations about module for translated taxonomy fields.

It execute SQL query:
UPDATE field_config SET module='taxonomy', active='1' WHERE (type = 'taxonomy_term_reference')

In my opinion this query should be:
UPDATE field_config SET module='i18n_taxonomy', active='1' WHERE (type = 'taxonomy_term_reference')

Would be great to see this in the next release/dev!

+1 subscribing

I have also this problem.
Can you help me?

+1

Just found out why this is happening with the help of this issue: http://drupal.org/node/1159912

Based on my trial and error, there are two things you need to ensure to get Localized working properly:

1) The i18n modules (I only tested with all of them enabled) must be enabled BEFORE you create your vocabularies. If this isn't the case, you need to either delete your vocabularies and re-create them, or you can figure out what exactly is going on in the database when creating new vocabularies while i18n is enabled, and then try to emulate that on your current vocabularies.

2) After having enabled your languages, you must enable the URL detection method at /admin/config/regional/language/configure. Localize may still work for other methods, but URL is the one I got working.

Essentially, if you started a site from scratch, you would do the following to get Localized taxonomies working (this assumes D7.8 and i18n 7.x-1.1):
- Enable ALL i18n modules
- Add your extra languages
(optional) - Enable Localization update and run Update translations at /admin/config/regional/translate/update
- Enable URL detection method at /admin/config/regional/language/configure
(optional) - Throw that Language Switcher block into a visible section of your site
- Add your Localized vocabularies and translate them
- Add your terms and translate them
- Edit the content types you want term references to appear in and Enable Multilingual Support (with translation) in Publication Options vertical tab
(recommended) - In the Synchronize Translations vertical tab check the first two checkboxes of the Extended language options. That is: "Set current language as default for new content" and "Require language (Do not allow Language Neutral)"
- Add term reference fields to the content types you want

That's it! Everything regarding taxonomy translations should now work properly.

As I did not want to recreate all my vocabularies (as in #12), nor want to fall in the trap as described by #5, I started looking for a way to modify field config and field instance config data after being read from the database.

Managing to do so will assure that:
- Existing fields will be handled by i18n_taxonomy as well.
- Cron won't undo the work of i18n_taxonomy_field_info_alter().
- Taxonomy term reference fields will continue to keep working if i18n_taxonomy gets disabled and uninstalled.

Diving in the code I found hook_field_read_field() and hook_field_read_instance(). But they won't let you change the field/instance info. So I came upon hook_field_storage_details_alter() which gets passed in the storage details but also the field (by reference). By adding an implemention of this hook to i18n_taxonomy I was able to solve this problem fro my site:

/**
 * Implements hook_field_storage_details_alter().
 *
 * We don't alter the storage details but the stored details of the field itself...
 *
 * @param array $field
 *   The field record just read from the database.
 */
function i18n_taxonomy_field_storage_details_alter($details, &$field, $instance) {
  if ($field['type'] === 'taxonomy_term_reference') {
    // We also take over existing taxonomy_term_reference fields.
    $field['module'] = 'i18n_taxonomy';
  }
}

Notes:
- You have to clear all the caches, perhaps twice, once to get the hook registered, once to get the field info correctly into the cache.
- I placed this function just below function i18n_taxonomy_field_info_alter() as it kind of completes the work done there.

Advantages:
- See the listing above.

Disadvantages:
- It is the "wrong" hook but at the correct time, so it might look a bit counter-intuitive. Good documentation can prevent people getting confused.

and as a patch

and now with Views support (and some white space removal), which means implementing a few Views hooks and forwarding them to the correct function in views/modules/ taxonomy.views.inc of the Views module.

Applied and tested #14. Works for me. I think this is actually a quite elegant solution.

Yes, looks good. Applied the patch in #14

About #15, we don't want any views integration here, try i18n_views module.

Linked issue #1172116: Missing filter: taxonomy fields of i18nviews to this issue.

Same problem in Drupal 6. Not even vocabulary name is translated on the EDIT form. Is there any chance of getting this fixed in Drupal 6? Any hints about what code snippets should be added or modified? Thanks.