Foreign language node links are not aliased

While Drupal 6 stores the path alias for nodes in the language you saved the node, when it emits a link to node/x, it does not know that it need to look up a path alias for that path in that language (and it should use the path or domain prefix for that language). This is a missing feature, and you can plug this in with contributed modules like i18n or localizer when they become available for Drupal 6.

I don’t think this is a missing feature in Drupal 6, but a very serous bug.

Take the following scenario:

A site has English and Dutch content.

• Site is build with Drupal 5, without any internationalization.
• Site is upgraded to Drupal 6 and ‘story’ content-type is made language aware now and optional translatable. The Dutch language is added with ‘path prefix = nl’ as secondary language.
• All the Dutch nodes are converted to there respective language, one by one, with the intention to add translation in the future.

What happened:

• All incoming links are broken for the ‘Dutch nodes’.... When re-saving a node the original alias became ‘language aware’ while making them Dutch.
• All outgoing links for the ‘Dutch nodes’ have no more alias when visiting the site with the default language.

What I was expecting:

Drupal should fallback to the most suitable alias, but it doesn’t. It looks for an alias in the active language and as only fallback it looks for a ‘non-language’ alias too....

Solution:

It looked to me that a contributed module can’t fill this gab because it’s a fundamental problem in function drupal_lookup_path() in path.inc.

Because path aliases are currently broken in HEAD and that issue is a bit out of my league so to say [1] I created a patch for Drupal 6 now.

What this patch does:

Function drupal_lookup_path() still likes the alias set for a specific language the most, but if it can’t find it, and we are looking for a ‘node/$nid’, it will take the first option it could find, whatever it has a language set yes or no.

• Lets say I have a Dutch node with a Dutch alias. If I’m visiting in the ‘English language mode’ it can’t find an English alias but it will find the Dutch one and use it.
• Incoming aliases are not broken anymore; in depended of the used prefix an alias will be found. So example.com/nl/nederlands will give me the same result as example.com/nederlands
• When you have a Dutch node with an alias but like to create a German alias as well it will take the German version over the Dutch one.

Please note about this patch:

It will ignore aliases in ‘non-preferred’ language if the $path doesn’t contain ‘node/’. So you are still able to create an alias for ‘/contact’ in Dutch (‘kontakt’ as we call it) and in English it’s still ‘/contact’. It only became a bit smarter concerning ‘node’ aliases.

I set this issue to ‘critical’ and ‘code needs review’. I consider it critical because it’s breaking existing sites that upgrade to Drupal 6 and are using the (great) multi-languages capabilities and although the patch is not for Drupal 7, the solution is basically the same. The current alias-issues in HEAD are not related to this issue.

Nick

[1] path alias is broken in HEAD:

http://drupal.org/node/196862
http://drupal.org/node/222109
http://drupal.org/node/259412

oops, wrong patch...

Another patch; found a typo and tabs....

I agree with Desbeers. This is rather unfortunate behaviour. Desbeers, if it's the same approach for 7.x, could you make a patch for that? There's no need to go about reviewing a 6.x patch when it won't be checked in until 7.x has been fixed...

Oh, and the patch from #4 introduces trailing white-space (new lines 74 and 89).

It works for me.

and why Drupal 7?

dvinegla: Because the (unwritten? written? (where?)) commit policy says that stuff needs to be committed to n.x before being applied to n-1.x before being applied to n-2.x before being applied to... (Where n is the version of HEAD.)

As a heads up, patch #4 creates a problem I haven't been able to unravel as of yet with any pages that have the same alias in different languages. ^1,2

Setup:

• 4 language site
• Path prefix with language fallback selected
• i18n, pathauto installed¹
• First example:
  • front page set to alias 'home', which is node/1
  • translations of node/1 all aliased 'home' as well
• Second example:
  • node/666 alias set to 'coca-cola'
  • translations of node/666 aliased to 'coca-cola' as well

Issue after applying patch:

• testsite.com defaults to the node of the last language returned from the query on (post patch) line 89
• every other [lang code]/home alias returns same node as above
• ditto for pages aliased 'coca-cola'
  • menu block set to show on all pages disappears on pages with same alias²
• on all other pages, all paths to 'home' or 'coca-cola' in menu blocks are unaliased unless one is navigating in the last language returned

¹Possible conflicts caveat #1.
²Possible conflicts caveat #2. This particular menu is a primary menu fed through a custom module similar to nice menus.

The issue seems to stem from the second part of path #4 when multiple rows from the query on line#89 causes $src to be set to the last row result at the end of the while loop.

Patching just the first part, the front pages are properly aliased, menu block shows up, and all subsequent links are aliased as outlined in the initial & #2 posts - I haven't found any other weirdness as of yet.

I'm still picking apart path.inc, patch #4, & where/if the above caveats cause a conflict; if I manage a fix I'll post it. In the meantime, thoughts or ideas from those that know the path & menu system better than I would be greatly welcomed.