Hi,

I was using i18n 5.x-2.3 before and decided to update to 2.4 today. It all looked good! (think the added info in the blocks settings page: 'Translations for content' is very good as this block was confusing for newcomers like me, used to be Translations and Language switcher)

Anyway, I have my site enabled for 6 languages. But only the English content has been added so far. Now here's the bug I encountered in 2.4 which wasn't there in 2.3 (I downgraded and it's all working as expected again)

When on certain pages in English (domain.com/en/about-us/about-us) and I click the English flag it doesn't redirect me to domain.com/en/about-us/about-us but to some other page. This happens on certain pages and usually redirects to the same wrong url. Yet once on that wrong url clicking the English flag will redirect me to another wrong url. This doesn't happen on every page and ofcourse it would be silly for a visitor to switch to English when already on an English page but still.

I ran the update.php after upgrading to 2.4 so that's not causing it. Might there be some cache I need to clean? Or is this a bug indeed? If it is, I'm pretty sure it's i18n 2.4 cause downgrading to 2.3 solved the problem without enabling/disabling other modules or doing other funky stuff.

If you need more information, like my website setup, modules and such just let me know.

Regards!

CommentFileSizeAuthor
#7 translation.notempty.unified.patch918 bytesTheRec
#2 translation.notempty.patch1.08 KBstefanw
#2 translation.notempty.patch1.08 KBstefanw

Comments

stefanw’s picture

stefanw commented

I can confirm this, we have the same problem on our site.
Our default language is German, and nodes are translated to English.
Ideally all nodes should have an English translation, but sometimes the editors forget that step.

Steps to reproduce here:
1) create a node, and assign "German" as language.
2) do *not* create a translation for that node.
3) view the node

Both links in the "Translations for content" block now point to wrong URLs.
The link to the German page should link back to the same page we're on.
The link to the English page... I don't know. Maybe it should link to the front page?
But instead they both link to what appear to be a random pages with the same content type and language.

The option set on "Multilingual system" -> "Advanced settings" is:
"Only current language and no language"
[Edit: changing this setting has no effect on the links in the translation block]

Hope that helps.

stefanw’s picture

stefanw commented
StatusFileSize
new translation.notempty.patch1.08 KB
new translation.notempty.patch1.08 KB

I have done some preliminary checking, and I found that the culprit is probably the function translation_node_nid in translation.module.

The problem appears to be that the function is looking for other nodes with the same value in the i18n_node.trid field (which I take to be the translation ID). When a node is created that has a language assigned, but no translation yet, a record is created in the i18n_node table, and a (temporary?) "trid" of 0 is inserted. Unfortunately, there can be quite a number of nodes with trid=0, and these are all returned as translation matches for an untranslated node, leading to the false results that we are seeing.

I have created a patch that excludes records with trid=0 from the result set; this seems to solve our problems for now.
Note that I am in no way an expert about Drupal internationalisation, and as I'm typing this, I'm still testing if there are any unintended side effects of this change. I'm uploading the patch as a basis for discussion, and would welcome feedback of any kind.

The patch should be applied to modules/i18n/translation/translation.module.

Hope that helps.
stefanw

bartezz’s picture

bartezz commented

Hallo Stefan,

Thanx for your reply. I was starting to think it was a problem with my setup...

I will look into your patch asap as I don't have the time to do so now! Thank you for posting it.
Hopefully more people will find this thread so we can get rid of this bug!

Cheers

Johnny vd Laar’s picture

Johnny vd Laar commented

i had the same issue. thanks a lot for this fix as it solves it again

stefanw’s picture

stefanw commented
Status: Active » Needs review

A short update, FYI. We've been running with this patch for a while now, and so far it's looking good.
I'm changing the issue status to patch (code needs review).

adixon’s picture

adixon commented

I just found this one also, and can confirm the bug and that the patch works. I think the sql would be more efficient to move the n.trid != 0 into the inner join condition, but I'm not an sql expert.

Also, the bug is due to the fact that trid is defined as NOT NULL in the i18n_node table, but the SQL condition is set to NOT NULL which is always true. So you can remove that part of the SQL (really, the fix is to replace NOT NULL with != 0).

TheRec’s picture

TheRec commented
StatusFileSize
new translation.notempty.unified.patch918 bytes

The patch works for me Drupal 5.12 / i18n 5.x-2.4 , I just added the unified version of the patch. Thanks stefanw for this one :)

*** Edit ***
Also applied the second advise of adixon and updated the patch, he's right, this field will always be NOT NULL since it is set so in the database schema, so why bother checking if it is indeed ? Of course it works too according to my tests.

mr.j’s picture

mr.j commented
Status: Needs review » Reviewed & tested by the community

Confirmed, bug fix works as described. Advancing status as no-one seems to be complaining.

nedjo’s picture

nedjo
he/him/his
Primary language English
commented
Status: Reviewed & tested by the community » Closed (duplicate)

Duplicate of #286758: translation node_nid and term_tid SQL improperly handles 0.