I have a multilingual site in English, Italian, and German. All languages have the language prefix set for the path.

I'm using the admin interface in English. When I go to .../en/admin/content/node, I see the content in English with Italian and German translations. But all the edit links, also have /en/. When I click the edit link next to the Italian node (.../en/node/2/edit?destination=admin/content/node), I go to the Italian node. Even though the url is /en/, all the content on the page is Italian except for the taxonomy terms (term reference) is in English.

The end problem is that the taxonomy terms don't display the translation. But it's caused by/related to the /en/ in the url. All the other links for accessing this content switch the url to /it/ and thus the terms are translated.

Here's a screen shot.

I'm not sure where the problem lies. I've spent days searching, so sorry if I've missed something.
Thanks for your help,
Linda

CommentFileSizeAuthor
Italian-page-english-terms.png153.34 KBAnonymous (not verified)

Comments

juhaniemi’s picture

Status: Active » Closed (works as designed)

Hi Linda,

The behaviour which you described in the issue title (Edit node link on the Content List page doesn't have the correct language prefix in the URL) IMO is the way Drupal should work. The language prefix is not a signal of content's language, but it is a language of the user interface. So if you try two different URL's, it/node/2/edit and en/node/2/edit you are actually editing the same (English?) node but with different user interface.

The second mentioned problem with taxonomy terms, which don't correctly translate because of the wrong language path prefix, is propably not a Drupal core issue, although it sounds like there might be a real problem there. Drupal core does not provide taxonomy term translations at all, so the out-of-the-box behaviour is that you should get the same terms for all languages. You might have i18n module installed for this need, so this problem can be a bug or some misconfiguration in i18n.

I'm marking this issue as "works as designed". If you can trace the bug into i18n, please post another issue in their issue queue.