Localize terms show always the default language

Try the most current version -- either 'i18n 7.x-1.0-beta1' or the most current dev!

In your sample above you refer to fixed term vocabularies, I guess (not freetagging)? Free tagging should work anyway & even without i18n -- the last time I checked the database tables, I saw that the terms/tids are bound to individual nodes/nids.

I have exactly the same problem. I have the "Localize terms" option selected in my vocabulary and translated all the strings. They show up in the translated strings list, but on taxonomy pages, nodes or in views the terms and their descriptions are consistently shown in the default language instead. Tried updating drupal to the latest dev release, tried updating i18n to the 7.x-1.x-dev release, tried removing the vocabulary and reproducing it from scratch, nothing helps.

Absolutely clueless here.

... please make sure you uninstall/reinstall 'i18n' properly. See #1070690: PDOException: SQLSTATE[42S22]: Column not found: [...] 'base.language' [...] -- especially my tutorial on http://drupal.org/node/1070690#comment-4158684 !

A lot of things here are related to the non-available upgrade path in alpha & dev versions.

Don't forget to inform us/me in a detailed manner about your progress.

... BTW, is there a reason to use 'Per language terms' instead of 'Localize terms' on 'admin/structure/taxonomy/foo_vocab/edit'? Maybe if you try to find out your motives, this might help you!

Just for completeness: reinstalling i28n doesn't help me at least. The translated strings ARE there, I can see them in the admin/config/regional/translate/translate interface. I checked DB integrity with Schema. But translations are not retrieved on node/taxonomy pages or in views, neither the term name, nor the description. Translated nodes are no problem, both on standard pages and in views.

I noticed that the Translation Sets table is empty. Is this normal?

... I meant it the other way round in comment#4, obviously ('Localize terms', 'Per language terms').

@phm#5: Translation Sets don't seem to work at the moment (lacking operations tab in the admin backend on 'admin/config/regional/i18n_translation').

BTW, below the 'readme.txt' from the 'i18n_translation' subfolder:

Drupal module: Translation set API
==================================
This is a generic API to handle translation sets. It is being used for now for path translation and taxonomy term translation inside i18n package.

Translation sets can hold a collection of entities or other objects. A translation set is itself an Entity thus leveraging all the power of the Entity API.

It also provides some basic storage for translation sets and a generator of new translation set id. However, each module is responsible for storing which objects belong to which translation set for which it needs to verride some methods of the base i18n_translation_set class.

- load_translations()
- save_translations()
- clean_translations()
- delete_translations()

Once these are implemented, to get the objects belonging to a translation set, indexed by language code, you can invoke this method on a translation set object:

- get_translations()

To define a new type of translation set, a module must implement hook_i18n_translation_set_info() as in this example:

/**
* Implements hook_i18n_translation_set_info().
*/
function i18n_path_i18n_translation_set_info() {
return array(
'path' => array(
'title' => t('Paths'),
'class' => 'i18n_path_translation_set',
)
);
}

See examples of overriding and extending this API:
- i18n_path/i18n_path.inc
- i18n_taxonomy/i18n_taxonomy.inc
==================================
Jose A. Reyero, http://reyero.net

@phm#5: My Translation Set table is not empty.

I switched to "Per language terms", which works fine. I didn't manage to get the string translation to work though, the vocabulary name & description are translated as strings, but when I use the [term:i18n-vocabulary:i18n-name] pattern in pathauto, it still takes the default language term. Clearly the issue is with fetching translation strings. Maybe I should submit a bug.

@phm#8: A clear bug report is usually helpful, yes. Concerning the '[term:i18n-vocabulary:i18n-name]': In my ears that sounds more like a token issue. Make sure to -- in case you file the bug report under/as i18n -- to at least tag the issue with 'token', I would say.

I have the same issue as phm.

I reinstalled i18n with the latest dev version and option "Localize terms. Terms are common for all languages, but their name and description may be localized." still does not work.

Titles on term pages, views etc. are still in the default language. I will try to do some "debugging" to post more useful bug report.

Subscribe.

It's a bug...

It's show always the default language in node edit and view but also in views drop down.

I think i've found the solution. I had some doubt because it's very short but after testing this a bit it seems this is ok.

I've changed the hook_field_formatter_view function a bit. It was using the $langcode parameter to get term translation, but this variable is the default language of the field, not the current active language. At least if I understood this correctly.

see: http://api.drupal.org/api/drupal/modules--field--field.api.php/function/...

#13 works for me. Thanks a lot idflood for this good catch. We should test now if it doesn't break other terms translation methode.

Subscribe

Hey @idflood! There's a huge i18n codesprint taking place at the moment in Berlin: http://i18nsprint.drupalevents.de. IRC: #drupal-i18n ! Maybe you could briefly join in there?

i changed the patch slightly and used i18n_langauge(). fixed in 0dc1f18

I'm using the latest dev version and have double checked that I the commit from #17 is in, but I'm still having trouble. admin/config/regional/translate/translate lists the terms as translated, but they always show up in the original language (english).

Seems like it should reopen?

Update: oh, and another strange thing. One of the terms that I haven't translated, named "other" is actually being shown translated in other languages.

Same as #19 here. I tried beta6 and latest dev. I wanna localize my terms. The terms are translated, but they are shown in English anyway. What confuses me is that when German is set as the site's language and I wanna translate a string, the original language is German and the language I can translate to is English. I am used to the original language always being English and this is weird because I have to switch to English to translate a term to German. Not sure if this is related.

I'm not having any luck using separate terms per language either :(

I also have terms showing untranslated, but I wonder if that's because I didn't uninstall/reinstall i18n dev as suggested in #3 by @the_phi

In the database, everything seems normal (for example in taxonomy_term_data table, all the values for language are und and i18n_tsid are 0 which are the default ; `language` VARCHAR(12) NOT NULL DEFAULT 'und', `i18n_tsid` INT unsigned NOT NULL DEFAULT 0)

I just wanted to note that the taxonomy term name translation is just available as string translation in the translation interface. The description is not available at all, because when I update the strings, I receive:
The string taxonomy:term:<em>tid</em>:description for textgroup taxonomy is not allowed for translation because of its text format.

In fr/taxonomy/term/tid/translate/edit/fr I can translate the other fields. And this translation is saved and displayed correctly.

I use: Localize. Terms are common for all languages, but their name and description may be localized.

My problem is that I can translate the name of the term, but it's not saved.

So I created a fresh test site where it works ok for the taxonomy term name translation.

In a taxonomy vocabulary with no custom fields, I found: No translatable fields
So I was wondering if I haven't got an issue with Entity translation which is enabled on my website...
But I don't think so, as I disabled taxonomy term entity translation in admin/config/regional/entity_translation
and the translate button was back. I created an issue about that in entity translation's queue: http://drupal.org/node/1182840

In conclusion I'm nearly sure I'm stuck because I used a previous version of i18n dev and I wish I don't have to start again all my translations.

@Jerome F: I just tried reinstalling and it didn't help

I realised that on the taxonomy page, the term name is displayed translated. It's just everywhere else that it isn't.
For example on the content view page, the taxonomy term field is displayed untranslated. Or in an other vocabulary's term page, the taxonomy term field is displayed untranslated as well.

In my views it isn't translated either, but there's this issue out there: Translate taxonomy term names in Views: http://drupal.org/node/346028

I realised something else: when I try to translate a term with the same name, when the translation is saved, the result is "not translated" that's normal, by design, becaose if you don't change anything, if you translate "foo" to "foo" you might as well not translate it. That was obvious but it did confuse me somehow... So that was the answer and solution to my last comment!

Side note:
I searched the differences in the database between my working test site and I found that in locales_source table, in the version column value was 0 in the old site and 1 in the test site, for the textgroup: taxonomy and location: taxonomy:vocabulary:3:name
So I changed it manually in the database. I don't know if it was needed though.

(I posted a lot of feedbacks in #21, #22, #23 and #25 and will not remove it because perhaps it can help)
To clarify, the problem was that the taxonomy term field is displayed untranslated if you keep "default" as format in content types > manage display, you have to choose "default translated"! That's all.

And in views choose a formatter like plain text(localised) or link (localised)

To translate the term description, there's a setting in fr/admin/config/regional/i18n/strings where you can allow translation for filtered HTML to be translated.

I was also wrong about entity translation, the title module lets you replace the term name field and description in the vocabulary's manage fields UI, so you can translate everything as well. http://drupal.org/node/1182840

The problem I'm having is that the term translation isn't being shown on node/add or node/edit. However, I actually did manage to translate the terms by exporting a .po file from built-in interface.

@Jerome F Please don't mark an issue as fixed just because your problem is solved. The problem as described in some comments (like #29) is still there. I am developing an installation profile so my version of i18n is always a fresh install, the tip to re-install are not a solution for me. The terms translations are pulled into the installation profile with a .po file, the terms are translated when I check, but they still show up in English on node/edit (and node/add) when I switch to another language.

I tried a lot, different versions of i18n (beta6 and latest dev), created a new vocabulary and new terms, even tried the option to use separate terms per language. In one case the closest I got to success was the English and German term both showing up =)

I tried this with a brand new Drupal and it's the same thing. I tried with both beta6 and dev of i18n. The translation is there BUT: like I said before, there's a language problem I will try to describe.

Let's say I create a term when my site's language is set to English. I translate the string and then re-visit the "edit string" page for this string. The original is English, the German is correct. See first screenshot attached.

Then I switch the site's language to German and visit the edit string page for that string again. Please see the second screenshot to see what happens - the original text is still the English one, but I can only translate to English instead of German. This does not happen with other Drupal strings.

That must be the reason why the translation isn't showing up because when my site is in German, there is no translation for it.

@aschiwi (#31)

It just works as expected. For user defined strings we assume the source language to be the site default *always*. See http://drupal.org/node/1114012

I don't know if there's anything else left here?

@Jose Reyero #32

Well, there still seems to be an issue. Translating terms using "taxonomy" text-group doesn't translate the term on neither node forms or node displays. I managed to translate terms from "built-in interface" and they are displayed translated in the correct language now on both node forms and node displays. But this can't be intended behavior? A localized term has a translation tab when editing the term. Translating the term results in nothing at all, since it doesn't change how the term is presented (it's still always presented in english).

If it's working as expected, then it sure needs a usability re-haul.

Hey Jose, thanks for your reply. I see what you mean and it makes a lot of sense. However, the string translations do not show up on node/add and node/edit. After what you told me I saw that I had to install my profile in English first (because I am pulling in English term names). Later I switched to German. This makes my problem from #31 disappear because my strings are now in English. The translation is there, but node/add and node/edit still don't show them.
Besides that I'm not too happy about taxonomy terms always being thought of as user defined strings, because this makes multilingual installation profiles with terms impossible if you allow to choose a language during installation. But I do understand that it makes sense in most cases besides this one and it doesn't really matter for my current project.

Anja

***edit: I think I'm starting to understand how this works :D
i18n allows us to localize term names. At first I tested this changing the site's default language, which is wrong according to your comment. This only works when using the language switcher, not when changing the default language. Knowing this probably solves most people's problem with the translation not showing up.

@AdamGerthel are you sure you you use the Formatter "default translated" ?

@Jerome F

You are referring to the display settings right? Well, there is no formatter for node forms. I did however discover a translation tab on the taxonomy reference field. It has two subpages: 'Field' and 'Instance'

Field has not been translated, but Instance has. Translating and saving 'Field' translation doesn't do anything. It appears it doesn't get saved at all.

@AdamGerthel Did you tranlate it to an other word? It appears the translation is not saved only when you don't modify the term string at all. You need to actually modify it.

@Jerome F

Yes, I translated it from 'Milestone' to the swedish equivalent 'Milstolpe'. It never changed though.

Try with english as default language, if it's not already... And try this: http://drupal.org/node/1175338#comment-4586454
But I don't know you mean by node form anyway... Maybe that's why I can't help.
(Is it related to http://drupal.org/project/node_form_template ?) Or do you mean the title and body?
By the way did you enable either Field translation module or entity translation + title? which method do you use?

I haven't used entity translation, only field translation. When I say node forms I mean the form where you save or edit a node. English is the default language.

+1 on the strange behaviour that after translation (and not changing the string, since it's the same in the foreign language), the term is marked as "not translated"... it's confusing, maybe a little help message would seem appropriate in case it can't be changed.

For all I've read so far this looks like a misconfiguration. AFAIK term translations (localized terms) are working fine for both node forms and node views.

Just in case:
- Selecting the right formatter may help for node views, see #37
- If you've gone through multiple i18n updates, disable and enable i18n_taxonomy so field handlers are properly set.
- Clean all your caches.
If still not working, please provide screenshots (node page not working, field and field instance settings, etc) so we can all see the issue clearly.

i confirm this

also when i try to edit the translation i get this error messages:

- Notice: Trying to get property of non-object in i18n_string_translate_page_form() (line 121 of path_to_d7/sites/all/modules/i18n/i18n_string/i18n_string.pages.inc).
- Notice: Undefined index: in _filter_tips() (line 1007 of path_to_d7/modules/filter/filter.module).
- Notice: Trying to get property of non-object in _filter_tips() (line 1011 of path_to_d7/modules/filter/filter.module).
- Notice: Undefined index: in filter_list_format() (line 674 of path_to_d7/modules/filter/filter.module).
- Warning: Invalid argument supplied for foreach() in filter_list_format() (line 674 of path_to_d7/modules/filter/filter.module).
- Notice: Trying to get property of non-object in _filter_tips() (line 1012 of path_to_d7/modules/filter/filter.module).

this if for Plain text format of the description and it seems that the translation it's saved.

for the Filter or Full HTML won't work at all

Same case as in #43. Using latest dev from 2011-Jul-22

I have same error.
I just install the RC1 version, with fresh drupal 7 installation.
The node is translate excepted the taxonomy.

subscribe.

About the issues in #43 see #1030970: Terms description not allowed for translation because of its input format

If any other problem left, please open a new issue because this one is already confusing and long enough.

One issue at a time.

Is there a follow up issue on the untranslated terms in node/add ? I can't get them to translate in there for the life of me :((

I'm running 7.x-1.2 and the correct translations are being displayed on the edit pages but not on the enduser pages.
I believe this is because the following function is not being called. i18n_taxonomy_field_formatter_view()

Edit: Sorry ignore this, my display outputs were not using "Link (Localized)"

When I choose the "Translate.." option in taxonomy and I edit a node in another language then the node's, then the taxonomy doesn't know wich term was selected first. Cause it is looking for a TID of another language, but doesn't searches for a TID in anoter language mathing the origingal TID.

ex: I create a node product and set the node language to "EN". I select a taxonomy "Green" (which came from a translated vocabulary 'Colors' having an English term 'Green' and translated it to Dutch 'Groen'.) between some others colors (red, blue,etc.)
I now switch my site language to dutch /nl/admin/.. and edit that same node again. Everything is prefilled, except the taxonomy colors. It shows the default option '- Choose value-'.

When i change my taxonomy into "Localize" and translate all colors again. The nodes show the correct color in the correct language when editing the node in a different language then the node language, but then the terms aren't translated when viewing the node. When viewing the node it shows the source language..

I have tested this in D6 and there is no problem at all. Looks like some strange taxonomy translation bugs in D7 i18n??

This issue is the closest I've found for my problem, not sure if it's related, but there's definitely a problem:

- I'm able to translate taxonomy terms, and see the translations saved
- However I can't ever display those translations - whether in an auto-generated menu of taxonomy terms in a vocabulary, or from a view that returns taxonomy terms. They always appear in the default language.

I can't find any mention of formatters and localized terms, either when editing the taxonomy, vocabulary, or a view.

I'm also having the same issue with localising menu items, wonder if that's related or not.

@ClaudeS,

Please don't reopen old closed issues unless you are possitive it's the same problem. This one is long and confusing enough.

If you want to create a new one please provide better description (Which modules, which pages, field settings, expected result, actual result).

Anyway, for views, there's a different module, i18nviews.

Up in #47, this issue was marked as a duplicate of #10309700 because of a latecomer's specific text-format matter.

However the original issue isn't a duplicate and it isn't resolved either.

I've just reproduced it with a completely clean Drupal installation, no add-ons except i18n taxonomy and its dependencies.

I've translated some terms in the Tags vocabulary, using the "Localize Terms" setting.

Using the "Plain test (localized)" formatter for the Tags taxonomy-reference field, localized terms aren't shown on localized versions of nodes.

The complaint that this issue is "already too long" isn't a justification for closing it either. The basic support-request remains, and is not complicated, no matter what side issues were brought in later.

It's because $language->language is always the default site-language ('en' in my case) for some reason, which is why line 230 of i18n_taxonomy.module (the output from the field display formatter) returns the original term.

The problem is that i18n_language() doesn't return the content language but the user-interface language, if no language-code is passed into that function.

@beanluc, "The complaint that this issue is "already too long" isn't a justification for closing it either."

Sure. I'll get back when there's patch that needs review.

I'm not going to offer a patch right now because I don't feel like I have a good idea of how to properly integrate this into this module's architecture, but, I'm working around it by replacing $language->language with $GLOBALS['language_content'] on lines 220 and 230 of i18n_taxonomy.module.

I considered updating the i18n_language() function, but in most cases that function really should return the interface language rather than the content language. I suppose that a boolean argument for content could be added to that function, in order to return the right language based on that context, but I'm not familiar enough with the bootstrap phase and the node.module to really have been able to write all the right condition tests into the language_content part of the function.

When using content_translation.module, there's only interface language, there's no content language.

It occurs to me that perhaps the proper way to update the i18n.module would be to explicitly handle the difference between whether entity_translation.module is being used vs. content_translation.module, instead of passing an argument into i18n_language().

I really wish I had the time to offer a patch. The work-around described above really can't be taken seriously as a proper update to i18n_taxonomy.module.

I've resolved my issue - it seems that there's lots of complexity surrounding localization, within i18n and Taxonomy Menu that I was using. I did have to create a custom version of i18n_menu_localize_tree to ensure children within a menu were localized even if the parent didn't need localization. Also I needed to rebuild menus after saving Taxonomy Term localizations.

I'm no longer sure which module (or lack of decent documentation) caused problems, but out of the box, it's not easy to get all of this working.

Same problem but no solution yet..
I had create a taxonomy vocabulary in french and created some content with this vocab. After that, installed the module i18n and to be more "friendly", I changed the terms from french to english and choose "Localized" for the voc. So, I went to "translate interface" and translated these terms to french. After, I tried with the term (URL taxonomy) but in different language I saw all the nodes and also the term in the node doesn't changed, remained the same for both languages.
I don't know what to do, everything looks ok but the problem still here.....?

try this : go to structure > content types > manage display. for each display, for each vocab, chooze Link (localized) instead of link only

That's fine advice, most of the time.

It won't work in the edge-case where someone using Entity Translation is presenting localized content in an unlocalized page, or if the localizations are different on the page and in the content. Taxonomy terms will always be shown in the page language, not the content language, when using the "localized" setting of the formatter.

@ haclong99: you are right, it has to do with display.. And something else, When we want to present these fields in Views we have to choose "translate" and not "Localize".

I can confirm that I am having this issue as well. However #61 worked fine for me. Is this indeed a bug or is #61 the correct way to handle localized terms? I don't know what Entity Translation is. Beanluc can you elaborate more on why you feel this is not the correct solution? It does feel like the logic is a little off - if you click on translated content you expect to see the correctly localized terms. Perhaps the documentation could be a little more clear?

Thanks

Beanluc can you elaborate more on why you feel this is not the correct solution?

It *is* the correct solution, *except* in the special case I described. In that case, the bug described in #54 and #58 above prevents the "correct solution" from working.

I don't know what Entity Translation is.

See http://drupal.org/node/1498708.

My taxonomy terms are showing correctly translated except for when in views.
I ended up using entity translation and created a translatable field just for views.
I am lucky that i haven't got many terms and those are fixed.

This is not ideal and will be looking at alternatives haven't evaluated i18nviews but i don't see why it should be needed for this.

See #1371696: Taxonomy terms not translated when viewing/editing node

PLEASE DON'T REOPEN THIS ISSUE, POST A NEW ONE WITH A CLEAN, UPDATED DESCRIPTION.

Thanks.

I know that you guys already closed this issue, but i faced the same problem where the translated terms are displayed in the default language, and i don't think the i18n module is causing that! i think the problem from Views! please check the views_plugin_display_page.inc and while debugging you'll see that execute function will get the title translated after rendering, but before the function returns the render variable

return $render;

you'll see:

drupal_set_title(filter_xss_admin($this->view->get_title()), PASS_THROUGH);

and that's what causing the problem! try to get the title before that by using drupal_get_title and you will see the title translated! so anyone knows how to solve this in a clean way?

Thank you.

Hi there, all this is complicated. And as we are not using the same settings and having the same goals, it will take ages before we talk about the same problems.

In my case, I have a site with two languages, english being the default. Most of the content is translated, except a node type (used for classified ads, but I don't want users to have to translate their ads). So first I set this node type to not have multilingual options, and (it might seems weird but) the node is then set to english when you create it. Enabling multilingual, enable you to set the node to language neutral. But if you don't plan to translate the node, so far, it doesn't make much difference (if it is, teach me how). When the user create that kind of node, he fills it in english or in french, then the node is in english by default or language neutral (depending your node type setting), but is shown independently of the site chosen language.

On the taxonomy side, I wanted the user to be confortable and use a localized taxonomy that will use the same translated term for a node. That means when the user is editing his node in english (using the language switcher), the taxonomy is presented in english, when is editing it in french, the taxonomy is in french. But the node is tagged with the same term id. To achieve this result I set this vocab. to be Localize.

And on the view side of it, when the user is in english filtering his view, he selects the english term result in showing the node tagged with this term. That same list could be filtered in french with the corresponding term localisation also showing the same result. (Chose "This view is set to be dependent of the user language". )

So a node can share the same term id localized, say you tagged it with the term "clothing" will show "vêtements" in french when you language switch on node view and views view (only if you choose "Link (Localized)" in field display). Also when you edit the node, the translated version of the term is presented in the selection.

My issue was the view filter using this localized vocab., it was always presenting the term selection in english. But the filter behave correctly. When I set the site in french the node tagged with "vêtements" was shown correctly, the term "vêtements" was appearing in french in the views. Using the filter and selecting "clothing", let only nodes tagged with "vêtements".

To solve this use i18nviews as described here: http://drupal.org/node/1402458#comment-6194682

Cheers

#61 solved my problem, too. Took a while to find out :-) Thanks!

#61 works fine. Thanks.

#61 should be the way to do it anyhow. still not working for me ... source language of my site is german and i keep it set like this because translation management is important. (tried changing, but did nothing)
#57 seemed to be the solution, but is not working in my case. i still get only the english terms displayed, no matter which language i am looking in. (well, i did not flush the caches .... would it help?)

first i had separate vocabularies for every language (fixed lang.) and i made fields for each of them and inserted them in the article type (f.e.). also in this case, only the english terms were showing. the other fields showed only their labels.

then i tried putting all in one vocabulary making translation sets, still only the english terms are showing.
i changed the vocab settings from translate to localize - nothing ...

BUT choosing the autocomplete field instead of checkboxes/radiobuttons as a widget for the taxonomy-field in my content-type, then it works fine (completions in the right language are showing)

so it must be a minor bug, just in creating the checkboxes which is not taking effect if the tag-field-widget is used.

It doesn't work at all I updated to Latest DEV.

Still if I switch from English to Arabic the term in View is still being shown as "English".

This is so frustrating.

Regards,
Amjad

#26 solved my problem.

thank you @Jerome F.

Please, do read the whole thread before reopening

I tried to follow the instruction of #26 but could not. What admin page are you referring to? Can someone paste the url to that page please?

Thanks

I think I tried everything here and in all Internet at all.
Nothing is working.

BTW:
I am also confused, that on admin page when I cross:
Structure -> Content types -> I see all Content types on the language I've created them, despite on use of translating their names via Entity Translating and Title modules.

Thanks God, there are no bugs on front end. But another language on node creating or additting seems very unprofessional.

So, what about #26 - I have not found these admin settings to...

So,,, Subscribe )))

Thanks for #61 (also works in Views). I was totally stumped.

Hello, I have tried out many of the suggestions in #26, #51 etc. I am one step away from doing something like #72, and abandoning entity translation for taxonomy, it doesn't seem to work for me.

Here is what I did:
-I have an English language taxonomy Localizable. I have entity translation enabled for taxonomy in general.
-I added translations for each term for the Portuguese language
-I went to the translation table and saved translations for each of these terms.
-ran cron/flush cache

Here is what happens when I try to do what I would like:
- When editing a node in the translated language (pt-br) the taxonomy terms do not display. Whilst some people say that English appears, I have nothing. I tried switching to auto-complete but will receive an error of Malformed entity if I type in either English term or Portuguese term.
- When I want to view the term page i.e. taxonomy/term/1 I get the page not found error. I tried setting the portuguese alias, and tried entering pt-br/taxonomy/term/1 etc.

Here is what I did to troubleshoot:
- Many things from this thread, i.e. disabling and re-enabling taxonomy translation, changing to translatable instead of localizable, recreating the vocabulary, reviewing and fiddling with all the field and display settings (although I'm not having problems displaying terms on the node view page...I am ONLY not able to see the translated terms on node/add/edit, if I set the term in English, save the node and then switch, the translated term displays.. also I made sure I was in pt-br/node/add so that maybe the detection wasn't screwing with it).

Is there anything important that I have missed from this thread? Otherwise, it seems I need to turn off entity translation for taxonomy, and re-direct to views of these terms per language.

I've reopened because I am hoping for some help on this.

All I did to fix this was turn off multi-language support entirely and then turned it back on again.

Thanks for #61!

https://www.drupal.org/node/1070256#comment-6004178

Yes #61 works perfectly even on Views. Thanks!

This has a conflict with admin_language module if the language of the node you are viewing is different from the selected admin_language.

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

Hi, I fixed my problem with custom module. Solution is below

Problem description
- multilingual site
- taxonomy not only has title and description but also custom fields and view mode
- taxonomy set up as 'localize'
- terms are added and translated via the 'Translate' button on the term edit page
- On the taxonomy page, or term page or term detail page (however you want to call it): the content is only shown in the default language. The translations are not shown.

I absolutely don't want to set taxonomy to 'translate' instead of 'localize' for these reasons:
- 3 languages, 5 terms with 5 subterms would result in 75 terms, it is hard to manage and position them
- each time you add a subterm and translate it you would have to reposition each translated term in the correct parent term
- if you use a term reference field on a node, in the dropdown all the 75 terms are shown, which is not only difficult and confusing, but term1 in language 1 has a different id and parent term id than term1 in language 2. this is for my code unwanted behaviour.

So I use 'localize'. I could translate the terms via 'translate interface' but it is my client that has to add and translate a lot of terms and each time going via translate interface is not a good workflow and is very time consuming.

So what I dit was create a custom module that edits the term page for the taxonomy 'category'. It loads the term from arguments, loads its translation and then sets the translation:

function yourmodulename_taxonomy_term_view_alter(&$build) {
  //If taxonomy is set to localize then you can enter translations via term edit -> translate.
  //That's nice, but drupal does not show these translations on the term page itself
  //so i fix it !
  if ($build['#view_mode'] == 'full' && arg(0) == 'taxonomy' && arg(1) == 'term' && module_exists('i18n_taxonomy') && $build['#bundle'] = 'category') {
    $tid = arg(2);
    $term = taxonomy_term_load($tid);
    module_load_include('inc', 'i18n', 'i18n_taxonomy.pages');
    $term = i18n_taxonomy_localize_terms($term);
    $build['title']['#items'][0]['value'] = '<h1>'.$term->name.'</h1>';
    $build['title'][0]['#markup'] = '<h1>'.$term->name.'</h1>';
    $build['description']['#markup'] = $term->description;
  }
}

For those with problems with localized taxonomies and views, just check out this:

http://ggordan.com/post/localising-taxonomy-terms-in-views.html

I implemented the solution above here:

https://github.com/rogercodina/i18ntaxonomy_views

Just in case if anyone happen the same to me. After half day trying to figureout why in my dev site work but in stage doesn't!!! I found that you must save again your Source Language or change to any other language and back again.

admin/config/regional/i18n/strings

I isolate the problem in a clean drupal and the same problem, but fixed after save the source again.

Since I had the same issue and couldn't find any solution here, I've tried by my self and this is my solution:

$query = new EntityFieldQuery();
$query->entityCondition('entity_type', 'taxonomy_term')
         ->propertyCondition('vid', $vid);

$result = $query->execute();
        
if (!empty($result['taxonomy_term'])) {
  // Solution for all vocabulary terms:
  // Load all terms and translate.
  $terms = i18n_taxonomy_localize_terms(taxonomy_term_load_multiple(array_keys($result['taxonomy_term'])));

  foreach ($terms as $term) {
    $translated_term = $term->name;
  }
  ....

  // Or translate terms one by one.
  $terms = taxonomy_term_load_multiple(array_keys($result['taxonomy_term']));

  foreach ($terms as $term) {
    $translated_term = i18n_taxonomy_localize_terms($term)->name;
  }
  ....
}

Sorry may I ask when and if this patch will be included into the modules?
I updated everything yesterday 06/01/2016 and still the issue up there: Taxonomy is always shown in Default language.
I do hope this module still supported again ...

#61 worked for me as well. Changing the display widget to plain text (localized) for the content type display and in the view field display did the job.

Not quite as intuitive as one might want it to be, but it works. Once learned, never forgotten, I hope.