Hello,
I'm not sure whether this is an issue with the i18n module or the core translation module...

  • I've installed the Locale, Content Translation and Internationalization modules on a clean Drupal 6.3
  • set up 2 languages domain-based language negotiation (e.g. http://drupal for primary language and http://de.drupal for second language)
  • and then created a new page in the primary language (node/1, english) plus a translation in my second language (node/2, german)...

Now, when I go to the translation table (translation tab on nodes) I get a table listing the current node and it's translation as expected.
In that table the node titles link to their respective node views and the edit links to respective node edit forms. My problem is: Both links don't seem to be localized.

That is: If I'm currently on http://drupal then the link for node 1 looks like http://drupal/node/1 which is fine, but the link for node 2 (which is a german page) looks like http://drupal/node/2 where I think it should be http://de.drupal/node/2 (using the path of the node's language).

This probably doesn't pose a problem for most people because drupal doesn't care if a node's translation doesn't match the current page language... but if you try to change that behaviour by doing something like described in this issue those links stop working.

So I guess what I'm asking is whether I can somehow change those links in the translation table to make them localized ones?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

bforchhammer’s picture

Project: Trace » Internationalization

uh, wrong project.

bforchhammer’s picture

Project: Internationalization » Drupal core
Version: 6.x-1.0-beta1 » 6.3
Component: Code » translation.module
Category: support » bug
Status: Active » Needs review
FileSize
1.72 KB

I think I found a solution myself...

Adding the current link's $language to the $options array of the link function solves the problem... Attached is a patch for Drupal 6.3 doing exactly that.

Are there any downsides to this solution that I'm not aware of?

bforchhammer’s picture

Version: 6.3 » 6.x-dev

10 weeks later and I still think this would make sense and should be implemented...

bforchhammer’s picture

Version: 6.x-dev » 7.x-dev
bforchhammer’s picture

Status: Needs review » Needs work
R.Muilwijk’s picture

Status: Needs work » Needs review
FileSize
1.29 KB

Reroll against head.

Status: Needs review » Needs work

The last submitted patch, 284625.patch, failed testing.

R.Muilwijk’s picture

Status: Needs work » Needs review
FileSize
1.3 KB

Hmmz.. fixed the typo's.

plach’s picture

Status: Needs review » Needs work
+++ modules/translation/translation.pages.inc	21 Jun 2010 22:51:08 -0000
@@ -33,9 +33,9 @@ function translation_node_overview($node
+      $title = l($translation_node->title, 'node/' . $translation_node->nid, array('language' => $language->language));
       if (node_access('update', $translation_node)) {
-        $options[] = l(t('edit'), "node/$translation_node->nid/edit");
+        $options[] = l(t('edit'), "node/$translation_node->nid/edit", array('language' => $language->language));

l() needs a language object, not a language code.

Moreover we need a test ensuring we won't break this behavior in the future.

Powered by Dreditor.

R.Muilwijk’s picture

Hmmz plach normally I would agree but look at current core code, line number 50:
http://drupalcode.org/viewvc/drupal/drupal/modules/translation/translati...

At the moment in the same function it already uses $language->language which I followed. Should all 3 instances be fixed to give the language object?

plach’s picture

At line 50 the language code is used to format the query string not as an option for l(). See http://api.drupal.org/api/function/url/7 for details.

Anyway I tested the patch and it does not work without the fix I suggested.

R.Muilwijk’s picture

Oh, that is true. I'l reroll!

bforchhammer’s picture

FileSize
1.77 KB

Here's a re-roll against current head using language objects, and added for the third link ("create translation") as well. Tests are still missing (need to read up on that topic first).

Note that this doesn't work at all when using the administrative overlay, probably related to #759844: Overlay does not work with prefixed URL paths.

plach’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 284625-#13.patch, failed testing.

bforchhammer’s picture

Status: Needs work » Needs review

#13: 284625-#13.patch queued for re-testing.

plach’s picture

It seems the patch is somehow corrupted. Can you post it again?

bforchhammer’s picture

FileSize
1.77 KB

Hm, here we go...

Status: Needs review » Needs work

The last submitted patch, 284625-18.patch, failed testing.

plach’s picture

You need to reroll the patch from the drupal root.

plach’s picture

However this does not work when adding a translation in a disabled language (see #356036: Allow creating nodes in disabled languages). You should use http://api.drupal.org/api/function/language_negotiation_get_switch_links/7 for each path to get the proper URL for each language.

bforchhammer’s picture

Here's the patch again, hopefully working now.

About #21: I can't imagine a case where it would make sense to "link to a language path" when the language is disabled. So isn't that something that should perhaps be handled inside the url() function?

plach’s picture

Status: Needs work » Needs review

It's pretty easy to reproduce: enable french and german, disable french and then try to add a translation for it (if you can't see a use case for this please read the issue above). As language negotiation works only with enabled languages /fr/node/x won't work. However I performed some tests and this turned to be another issue.

Edit: related issue: #926212: URLs rewritten with disabled languages.

plach’s picture

@bforchhammer:

The patch looks good and works as intended. If you provide a simpletest I'm ready to RTBC it.

bforchhammer’s picture

Attached is my attempt at providing tests.

This is my first time using the testing framework; feel free to point me to guidelines or documentation which I might not have followed...

plach’s picture

Other than the minor coding standard issues below this looks good to go :)

+++ modules/translation/translation.test
@@ -45,14 +52,23 @@ class TranslationTestCase extends DrupalWebTestCase {
+    $this->assertLinkByHref( $languages['es']->prefix . '/node/add/' . str_replace('_', '-', $node->type), 0, t('The "add translation" link for %language points to the localized path of the target language.', array('%language' => $languages['es']->name)));

The whitespace between the method parenthesis and the arumgent shouldn't be there.

+++ modules/translation/translation.test
@@ -45,14 +52,23 @@ class TranslationTestCase extends DrupalWebTestCase {
+    $this->assertLinkByHref( $languages['es']->prefix . '/node/' . $node_translation->nid . '/edit', 0, t('The "edit" link for the translation in %language points to the localized path of the translation language.', array('%language' => $languages['es']->name)));
+    $this->assertLinkByHref( $languages['es']->prefix . '/node/' . $node_translation->nid, 0, t('The "view" link for the translation in %language points to the localized path of the translation language.', array('%language' => $languages['es']->name)));

idem

Powered by Dreditor.

bforchhammer’s picture

Cool :) Attached patch fixes the whitespace issue.

plach’s picture

Status: Needs review » Reviewed & tested by the community

Nice!

plach’s picture

Status: Reviewed & tested by the community » Postponed

@bforchhammer:

Sorry for changing status but #926212: URLs rewritten with disabled languages should be fixed before committing this, otherwise we would introduce a major core misbehavior.

Could you stay tuned over there? I'll try to provide a simple test ASAP. If you can test and review it too, this would speed up the commit of this issue. I'll RTBC this again once the other one is RTBC.

plach’s picture

Status: Postponed » Reviewed & tested by the community

@Dries, @webchick:

Before committing this, be sure to commit #926212: URLs rewritten with disabled languages as this exposes the bug fixed over there.

plach’s picture

Status: Reviewed & tested by the community » Needs work

After some additional testing I realized that the last patch is incomplete: if you enable the Session language detection method instead of the URL one the translation links are still unlocalized.

As I suggested in #21 we should use http://api.drupal.org/api/function/language_negotiation_get_switch_links/7 to obtain the proper localized links. We must also keep in mind that when no language detection method is enabled its result will be empty, but in this case we don't need localized links.

bforchhammer’s picture

Not sure how the session language detection works... is there a way to change the session language with the click of a link? If not this is going to be hard to solve (?).

As I suggested in #21 we should use http://api.drupal.org/api/function/language_negotiation_get_switch_links/7 to obtain the proper localized links

I shouldn't be that hard to tell a link to be rendered localized in a different language; from my naive developer perspective I would say that the current implementation is the most logical one and if this isn't working for certain types of language negotation then maybe that's a defect in the url() function (or related ones).

plach’s picture

This is not a defect in url(): in the latest patch we are esplicitly providing an option to change the language, but this concerns only URL language, while to switch session language we need to provide a query parameter. But this would not take into account any other possible contrib language detection method. http://api.drupal.org/api/function/language_negotiation_get_switch_links/7 does by invoking all the defined language switch callback functions. Using it is not that hard after all.

bforchhammer’s picture

I think I understand the difference between what the two functions url() and language_negotiation_get_switch_links() do (thanks to catch@irc), but I don't quite get why there is a difference -- I can't imagine a case where one would pass the language object into the url() function and then NOT want to actually switch languages when clicking the resulting link.

Of course I don't want to unnecessarily hold this issue back, so if the language_negotiation_get_switch_link() function is the way it has to be I'll adjust my patch...

plach’s picture

I understand you perplexity: the reason is that with the new language negotiation API a URL can convey an arbitrary number of language types, so we can't simply rely on $options['language'].

plach’s picture

Status: Needs work » Needs review
FileSize
5.75 KB

Let's try this.

Status: Needs review » Needs work

The last submitted patch, translation-284625-36.patch, failed testing.

plach’s picture

Status: Needs work » Needs review
FileSize
6.35 KB

Tests should pass now.

bforchhammer’s picture

Status: Needs review » Reviewed & tested by the community

That's working nicely. :-)

tom_o_t’s picture

#38: translation-284625-38.patch queued for re-testing.

webchick’s picture

#38: translation-284625-38.patch queued for re-testing.

webchick’s picture

Status: Reviewed & tested by the community » Needs review

#926212: URLs rewritten with disabled languages committed. Sent for a re-test.

However, I reeeeeeeeally am not a fan of introducing a "special" l() function here. Can we just include that code in translation_node_overview()?

plach’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
6.56 KB

And here it is :)

Status: Reviewed & tested by the community » Needs work

The last submitted patch, translation-284625-43.patch, failed testing.

plach’s picture

Status: Needs work » Reviewed & tested by the community
FileSize
6.59 KB

this should work

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Thanks!

Committed to HEAD.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.