An assigned URL path is only used for the "active" language. If you open a node with a specified language prefix, all links to translations (which have URL paths assigned too) are not aliased.

I am not sure which module is to blame: path or locale :)

Steps to reproduce:

1) Activate modules Locale, Path
2) Add language German
3) Set language negotiation to "Path prefix with language fallback"
4) Add prefixes to both languages (en, de)
5) Create original node (in English)
6) Add translation (in German)
7) Add "about" as URL path to both.

The path is working for both (if you enter them manually), but:
1) In /de/admin/content/node a link to the English node is listed as /en/node/1
Likewise the German node is listed as /de/node/2 in /en/admin/content/node
2) When navigating to one of the two (by entering the URL in the browser) - the link to the other language says <language prefix>/node/xxx instead of <language_prefix>/about

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Gábor Hojtsy’s picture

Status: Active » Closed (duplicate)

Path aliasing with node submissions has some issues discussed here. Please try that fix and reopen this issue, if that did not fix it and it looks you are facing a different issue which cannot be fixed there. http://drupal.org/node/154517 Thanks!

daniel.soneira’s picture

Status: Active » Closed (duplicate)

I downloaded the latest dev-snapshot (2007-12-01). The problem i described is still there.
In this version there is a change to the problem as well (which makes it worse):

1) The path (about) is not used for the node regardless which prefix I use to navigate to the node.

Example:
de/about => Link to English node is de/node/2 instead of en/about
Before (beta 3) when I clicked on this link it at least showed the correct path back to the original path (which I navigated to).

Likewise in /admin/content/node no path aliases are used for the links to these two nodes.

Do I have to do something else to try that fix besides downloading the snapshot?

Regards
Daniel

daniel.soneira’s picture

Version: 6.0-beta3 » 6.x-dev
Status: Closed (duplicate) » Active
Gábor Hojtsy’s picture

Status: Closed (duplicate) » Postponed (maintainer needs more info)

Hm, where are those links placed?

1. In the menu?
2. Or printed by node module as translation links?
3. Or by the language switcher blocks as translation links?

daniel.soneira’s picture

The incorrect links are:
- in the node itself (I guess that's what you call "language switcher") at the bottom => "English version" / "German version")
- in administration console (/admin/content/node) in the list of all nodes when you hover over the nodes' titles you can see they don't use the correct URLs (was partly correct in beta 3).

I haven't added these nodes to a menu yet. I will test this when I'm home.

Gábor Hojtsy’s picture

Status: Postponed (maintainer needs more info) » Active
Freso’s picture

Title: locale / path » Path aliases does not work with "path prefix" language negotiation

I am experiencing these very same symptoms (only using da and sco instead of de), thus subscribing.

I have done a bit of testing, but am currently too tired to trust myself writing anything coherent. But this is a major drawback for multilingual/internationalised sites.

Gábor Hojtsy’s picture

FileSize
6.39 KB

Actually, the bug fix for http://drupal.org/node/176070 (you were unable to save the same alias for translation nodes) broke this one. Previously, path alias saving was not really language aware, aliases being saved as language independent. Now that aliases are properly saved (thanks to Desbeers for his huge work on this), we need to pass on the language object whenever we are about to display a link to a content in a different language. Neither the translation links, neither the node admin page passes the language object on for aliasing, so therefore, you don't get the proper language aliases.

Actually, language_url_rewrite() and url() got a bit inconsistent on this through the previous week, as I fixed some issues without looking at the bigger picture, so there was a 'langcode' url() option key introduced which should have been the full 'language' option key, which was available before.

Attached is a rough cut of what is needed here IMHO:

- getting rid of the confusing extra 'langcode' in url() and language_url_rewrite()
- document 'language' and the internal 'base_url' keys on url()
- pass on the language object on the node admin screen
- pass on the language object in the translation links

Seems like the language switcher block already passes on the proper language object, so there is no issue there.

The patch is yet untested, but I'll test later today. Until then, feel free to comment / test yourself.

Gábor Hojtsy’s picture

Status: Active » Needs review
FileSize
8.26 KB

Well, here is an actually tested patch. Although I was right that the language object was not passed forward, the real problem was that path negotiation modified the path before the alias lookup happened, so the alias set for the given path was not looked up. We need to do the same thing as done with the domain negotiation: remember the path prefix to use, and after all altering, tack it on to the beginning of the path.

This works for me with links to anything. The actual link building code needed a rethink, as it's special case for the front page was not clean URL aware. I tested both in clean URL and non-clean URL mode.

Please review soon!

Gábor Hojtsy’s picture

FileSize
12.35 KB

Hm, some further testing revealed, that all themes use base_path() ($base_path in phptemplate) for the logo links, assuming that it links to the front page. Well, with language based domains and path prefixes, this is not actually the case. So attached patch fixes all core themes to use url() instead, which nicely generates a proper front page url when called without parameters for the actual language at hand. This might be better to be made a $front_page (or something along these lines) variable in phptemplate.

By the way, it is quite shocking that such bugs are discovered so late in the cycle. Anyway, let's get these fixed soon.

Gábor Hojtsy’s picture

FileSize
14.75 KB

This one includes $front_page in theme.inc and usage of it in all phptemplate themes to make sure this gets in soon. Please test!

Freso’s picture

I didn't do a very thorough testing (mostly due to not being completely sure of exactly what to test), but it fixes the problem described in the initial report, so, yay! :) (I'm also out of the loop and a bit under the weather, so...)

By the way, it is quite shocking that such bugs are discovered so late in the cycle.
Well, this bug only showed itself as another bug was fixed... it's hard to discover a bug that's hidden behind another bug (or introduced as the fix for another bug). :x

Freso’s picture

Status: Needs review » Reviewed & tested by the community

Okay. Patch applies cleanly. Path aliases now work as expected. Logo point to "site/lang/" (instead of "site/"). Looking over the code, I can't find anything suspicious looking – most of it looks like a find-and-replace job, correcting 'old' (and incorrect) variable and function names and calls with their 'new' (and proper) variable and function names and calls.

I still haven't done heavy testing, and there might be some corner cases I haven't thought of, but I feel that this really is RTBC, as I can't find any immediate flaws in it, so... marking as such.

Gábor Hojtsy’s picture

Status: Reviewed & tested by the community » Fixed

Great. Thanks for testing. I committed this patch. Please submit more bug reports as you find any misbehavior. Make sure to mark them for locale.module or language subsystem if connected to locales/languages.

daniel.soneira’s picture

Version: 6.x-dev » 6.0-beta4
Status: Fixed » Needs work

I just tested this on beta 4.
The links in administration and on the node itself work like a charm but I tried out the menu feature as well.
Sorry, I couldn't test it earlier.

I added a "Menu link title" for both nodes (about_de, about_en).
First thing I noticed was that I got a warning after saving the English node (no warning was shown when editing the German one):

user warning: Duplicate entry 'about-en' for key 2 query: UPDATE drupal6b4url_alias SET src = 'node/1', dst = 'about', language = 'en' WHERE pid = 2 in C:\xampplite\htdocs\drupal6b4\modules\path\path.module on line 98.

This warning is shown whenever I want to edit (without changing anything, simply saving) the English node. (Maybe a different issue?)

After ignoring this I looked at the links in the menu (default language=English).
It shows the same behavior as before the patch (it only shows the alias for the "active" language). So the German link was en/node/2 instead of de/about

Another thing I'm not sure about (which most likely has nothing to do with this issue):

Should BOTH menu links appear at the same time?
I would have thought that only one of them would be shown depending on the user's language.

I hope I haven't done anything wrong with setting back this issue's status but I thought it still fits the new issue's title. Should I have opened a different bug report instead?

Gábor Hojtsy’s picture

Status: Needs work » Fixed

Menus are without multilanguage support (just like categories, user profile labels, blocks, etc). For multilanguage aware menus (as with paths and item selection), you will need i18n or localizer.

The duplicate entry issue is a problem however. But that's connected to http://drupal.org/node/154517 so reopen that one please, and carry over your report about the duplicate entry for the alias. Thanks!

Anonymous’s picture

Status: Fixed » Closed (fixed)

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

eriksson-1’s picture

subscribing