Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Terms get translated if they happen to have the same name as a translated string. But of course their name shouldn't be translated.
I'm not sure if HS is really the culprit here but for example in taxonomy manager this doesn't happen.
Comments
Comment #1
wim leersProbably the Taxonomy Manager module doesn't support translated terms.
I'm not sure how we could avoid this. Moving to i18n queue to get some feedback.
Basically, what I'm doing is:
t($term->name)I doubt we can prevent terms from being translated using this approach?
Comment #2
nath commentedWell, Internationalization is a module that I don't even use, so I doubt that is has something to do with this issue.
I don't think that terms should be translated, at least not with the standard t() function.
Comment #3
wim leersAnd how else should they then be translated? That *is* the only way they should be translated, or even could be, in Drupal.
Comment #4
nath commentedAs I understand it, the stuff that I enter shouldn't be touched by the t() function. The function is to translate text included in the code.
I don't expect the title or body fields of my articles to be translated just because they happen to match some text in the code and neither should my terms.
Comment #5
wim leersThat's how the i18n_taxonomy module works as well. It's by design. I'm waiting for feedback from the i18n module maintainers to find out how they would like to handle this edge case.
Comment #6
jose reyero commentedThe thing is Drupal localization doesn't support context for translation. And you are not supposed to run user defined strings through this localization.
But i18n does support it, it would need to be implemented by other contrib modules though.
See:
i18nstrings module, tt() function
i18ntaxonomy module
and
http://groups.drupal.org/node/15177
Comment #7
wim leers