Closed (won't fix)
Project:
Internationalization
Version:
6.x-1.x-dev
Component:
Taxonomy
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
15 Feb 2010 at 09:06 UTC
Updated:
9 Aug 2013 at 08:05 UTC
Jump to comment: Most recent file
Comments
Comment #1
mvidelgauz commentedI think my issue has the the same source so I am not creating another issue. Here my description of the problem:
I also have created a taxonomy vocabulary with the option Localize terms. Originally all terms were added into vocabulary in English and I don't remember what language was selected as default at that time (most likely English but I don't think it matters). Then I created translations for all terms into Russian and Hebrew. Everything is working fine as long as default language of the site is English (all terms are rendered in currently selected language). But if I change default language to Russian then:
1. All terms are rendered in English if selected language is English and also if it is Russian. If selected language is Hebrew then they are rendered in Hebrew.
2. On the admin/build/translate/search page I see that term "Green" has translation options "ru" and "he", but when I click "edit" then it says "Original text: Green" and offers me to enter translations into Hebrew and ... English!!! (although if default site language was English then options were Hebrew and Russian)
So my conclusion is the following:
Internationalization module incorrectly assumes that terms in term_data table are in current site default language. And if selected language matches default language it takes it from that table instead of taking it from translation table
I think that it should work the same way like it does for nodes - when a new term is entered user should have a way to specify in what language it is and later translations should work. I know there is field "language" in term_data table but it is doing something else - if is is not empty then term is visible only when selected language matches that field and translations don't work at all.
I have found module http://drupal.org/node/133999 that works in a way that I would expect, but it is only for D5 ((((
Comment #2
univac commentedI managed to make it working thanks to translation_table module.
Give it a try.
univac
Comment #3
mvidelgauz commentedHow? Is there a new version of this module? My /admin/reports/updates doesn't say anything about it...
Comment #4
univac commentedam using the latest Translation table 6.x-1.0-rc2.
univac
Comment #5
sanderc commentedI have kind of the same problem, only my problem is that the terms show on my website in 2 languages: English and Dutch. I use Views to display a list of Taxonomy terms, but nowhere in the view settings I can choose which languages I want to show (as I can choose that with views of nodes).
I have created terms in the two languages, set the languages correctly and paired them on the translation page (/admin/content/taxonomy/3/translation).
I noticed that this bug has been reported before (I think it is the same), but it was closed due to inactivity: http://drupal.org/node/365606. Is this the same Issue?
Comment #6
univac commentedHi All,
sadly I have to report that after a few node, the translation is not longer working.
So now I have few nodes that are correctly translated, while newer one are not and it is not clear why the translation stopped to work.
I have changed the issue category from support to bug.
Comment #7
univac commentedinteresting to report is that if I define the node in the second language and then translate the content for the default language later on, this let me create the taxonomy title and keywords both in the default language and translated one thanks to [i18n-term].
hope this helps to locate the bug ;-)
Comment #8
robertdouglass commentedSeeing the same bug. Here's how it manifests itself.
I've got a vocabulary with the second option (Localize terms). (see screenshot)
I then used the l10n_client module to translate the term name. When I save the term, it takes the text that I entered (the translation) and records it as a new source. I then have the original term and the text that was supposed to be the translation in the sources. (see screenshot)
Comment #9
robertdouglass commentedMarking critical as this module doesn't seem to work at all.
Comment #10
robertdouglass commentedUpdate. This feature DOES work. However, only after you go to admin/build/translate/refresh and refresh the strings in the Taxonomy string group. (see screenshot)
Then, when using the translation interface, it has new text groups (taxonomy) and THAT's what you translate. (screenshot)
Comment #11
mvidelgauz commentedSubscribe
Comment #12
dagomar commentedI'm sorry but I am having an issue here. I cannot translate the term. I can find the term, click edit, but instead of letting me translate in dutch, i am translating to english. My default language is dutch, but I was presuming created terms would be in English and translatable to dutch. Changing back default language to english, then translate to dutch, doesnt work either, terms never show up translated.
Comment #13
jose reyero commentedSo is this an issue with l10n_client only? or a general taxonomy translation issue?
Comment #14
sinasalek commentedI have the same problem. I expected i18ntaxonomy module to consider the active language. however it seems that it doesn't.
Comment #15
jose reyero commentedPlease, answer question in #13
Comment #16
domidc commentedHas something to do with taxonomy_override_selector #619726: Ensure normal (non-HS) taxonomy form items get translated via i18n
Comment #17
hip commentedTo #10 (+ everybody else here)
I do all the steps you mention. No problem to find the tabs, pages, forms, refreshes,... nor to fill them up and get the term translated. But (using Views, at least) every single field shows up correctly translated to the navigation language BUT the taxonomy term!!!
I'll try to detail my case below in a few hours time.
Comment #18
bohz commentedHI!
I have a (sort-of) very similar problem with taxonomy terms translation.
I have a "Per language terms" multilingual vocab and a "Path prefix with language fallback" language negotiation
that is, for example:
taxonomy/term/1 (Italian) is translated with taxonomy/term/2 (English) and vice versa
When I am viewing a taxonomy/term page, regardless if it's overriden or not with views and/or with default or aliased paths, if i switch language through the language switcher the module simply switches the prefix only, leaving the rest of the path untouched
according to the previous example:
mysite/it/taxonomy/term/1 ---> mysite/en/taxonomy/term/1
when it should actually be:
mysite/it/taxonomy/term/1 ---> mysite/en/taxonomy/term/2
any suggestion on how to correct this behavior would be greatly appreciated.
Thanks in advance!
Comment #19
ern0 commentedQuick solution:
In the file
.../modules/i18n/i18nstrings/i18nstrings.module
find the function called
i18nstrings_translate_langcode
and insert a
return true;
statement as its first line.
It should looks like:
It's around line #238.
Official solution:
If you have a little more time, install the 2010-Sep-21 version of the i18n module: http://drupal.org/project/i18n
Comment #20
bohz commented@ern0
I have invested a little more time and installed the dev version of i18n. in fact, the problem seems now solved.
Thanks a lot!
Comment #21
arski commented@ern0: brilliant quick fix, thanks a lot, worked like a charm.
@module maintainers: could you please do something about this bug so that it wouldn't require an old -dev version to work. To answer your previous question, this is not a l10n_client related issue (at least not for me), but that when the "localize terms" option is set, you can find the terms, translate them, but then those translations are ignored when the terms need to be displayed in a secondary language, for example when adding a new node with a taxonomy selection.
Thanks in advance.
Comment #22
manoloka commentedIs there any solution for this yet?
#19 didn't work for me :(
subscribe
Comment #23
jaisenan commentedThank you very much ern0!!
That fixed my issue.
Comment #24
jvieille commented#19 works for me
Thanks a lot!
Comment #25
jose reyero commentedReally,
There's no patch here, nor it's a critical bug.