Endless loop with translation (D6)

Well, Global redirect does the redirects, so it needs to be aware of the language. Is this true for all non-default languages?

I have a site with 3 languages and 3 nodes. And in my settings.php I added:

$conf['i18n_variables'] = array( 'site_frontpage' );

German (default): no prefix, site_frontpage: home (url: node/1)
English: en, site_frontpage: home (url alias: node/2)
Portuguese, Portugal: pt, site_frontpage: node/3 (no alias)
(Aliases are language specific)

http://example.com/ -> node/1
http://example.com/home -> node/1 (redirect to /)
http://example.com/node/1 -> node/1 (redirect to /)
http://example.com/node/2 -> node/2 (no redirect)
http://example.com/en/node/2 -> Error
http://example.com/en/home -> Error
http://example.com/en/ -> Error
http://example.com/node/3 -> node/3 (no redirect)
http://example.com/pt/node/3 -> node/3 (no redirect, should be redirected to /pt)
http://example.com/pt/ -> Error

Error: Browser detects endless loop of redirects

Michael

After playing a little bit with php code I think that the missing redirect of http://example.com/pt/node/3 is a problem of the i18n module.

So to fix this for my website I added the alias "home" for node/2 and added a hack to function globalredirect_init() in globalredirect.module by changing the if statement which handels frontpage urls:

old:

    if (!empty($_REQUEST['q']) && drupal_is_front_page()) {
      drupal_goto('', $query_string, NULL, 301);
    }

new:

    if (!empty($_REQUEST['q']) && drupal_is_front_page()) {
      // 1 if statement would be enough, but so it's nicer to read;)
      if (!(module_exists('i18n') && array_key_exists($_REQUEST['q'], i18n_supported_languages(FALSE)))) {
        drupal_goto('', $query_string, NULL, 301);
      }
    }

Only a hack, but worked for me:)
(All 4 Errors and the missing redirect are "solved".)

Michael

MichaelK - Thanks for looking into this. Are you using the i18n project for Drupal 6 or the built in translation stuff?

I'm using both of them.

The modules I use are
core: Content translation, Locale
i18n: Content Types, i18n - views, Internationalization, Language Icons, Multilingual Menu, Multilingual Profile, Multilingual taxonomy, Mutilingual Blocks, Strings, Translation Synchronization
That means every i18n module except for Multilingual Poll

So now I have some more nodes (type: page).
http://www.examle.com/node/4 <-> http://www.examle.com/impressum
http://www.examle.com/en/node/5 <-> http://www.examle.com/en/about-us

node/4 is redirected to impressum but en/node/5 is not redirected to en/about-us
And if someone wants to use /en/node/5/ he gets /en/en/node/5 (same when using /en/about-us/ => /en/en/about/us

So, the problem is the path prefix (here: en) in $_REQUEST['q'].
The path prefix can be found in:

  global $language;
  $language->prefix;

Is there any easy way to get the same as in $_REQUEST['q'] but without the language prefix?

I suppose the question is - what do people want the actions to be... 3 example paths:

1. node/4
2. en/node/4
3. fr/node/4

Say Node 4 is the 'about-us' page and defaults to English ('en'). I assume, if this were the case, you'd setup some aliases like:

• node/4 <-> about-us
• fr/node/4 <-> about-us-french

I also assume, in this case, en/node/4 should redirect to node/4 (and therefore 'about-us').

I ALSO assume that the language code can also be toggled so SUFFIX instead of PREFIX (eg, node/4/en)?

Thoughts?

Ok, let us use your 3 example paths. Then i think fr/node/4 should not redirect to fr/about-us-french (which would be for example be equivalent to fr/node/5).
Staying at fr/node/4 does make sense because you can use the path specified language for the user interface (l10n). That's not necessary for the site visitor but for the author.
Although my native language is German and the website i administer uses German as default I prefer using an English interface while editing nodes.

en/node/4 can not be found (Error 404) while there is no language path prefix "en". But it would be nice if it redirects to about-us. (Not important for the moment I think).

I don't know if it's possible to use language suffixes instead of prefixes with drupal 6. I did not find such an option.
Best way would be to get a language suffix/prefix free version of the original path from drupal core and give another suffix/prefix free path to drupal_goto().

Another cool feature would be to eliminate double slashes like example.com//about-us

Here is my current version (based on globalredirect-6.x-1.x-dev.tar.gz)

    // Get the Query String (minus the 'q'). If none set, set to NULL
    $query_string = drupal_query_string_encode($_GET, array('q'));
    if (empty($query_string)) {
      $query_string = NULL;
    }

    //NEW
    global $language;
    $request_untrimmed = $_REQUEST['q'];

    // eliminate prefix
    if($language->prefix == substr($request_untrimmed, 0, strlen($language->prefix))) {
      $request_untrimmed =  substr_replace($request_untrimmed, '', 0, strlen($language->prefix));
    }
    //END NEW

    // If current path is also the frontpage, redirect to ht tp://www .example.com
    if (!empty($request_untrimmed) && drupal_is_front_page()) {  // <- $_REQUEST['q'] => $request_untrimmed
        drupal_goto('', $query_string, NULL, 301);
    }

    // Trim any trailing slash off the end (eg, 'node/1/' to 'node/1')
    $request = rtrim($request_untrimmed, '/'); // now rtrim instead of trim (endless loop!)

    // (...)

All below "$_REQUEST['q']" should be replaced by "$request_untrimmed"

May be a redirect like fr/node/4 to fr/about-us-french (= fr/node/5) would make sense if the user is anonymous.
Or generating an options page where the admin can choose what to do.

Where a redirect absolutely does make sense would be fr/about-us. Because if the aliases are about-us for the english version and about-us-french for the french version fr/about-us would cause an 404 error.
But I didn't find a way yet to check whether a url is correct or not.
At the moment I found 4 cases which produce a 404 error and where a redirect would be nice:

• fr/about-us => fr/about-us-french
• fr/node/4 =>fr/about-us-french (=node/5)
• en/node/4 => about-us (= node/4)
• en/about-us => about-us

The first 2 and the last 2 are very similar. The first a about switching to the right language and the last are about eliminating the not existant prefix. Only for case 2 I have something like a idea.
My biggest problem is: how do detect that a path causes a 404 error (cases 1, 3, 4) and how to check if another path would be correct?

Here is a patch with my code from March 26.

Can anyone test it with a non multilanguage site?

What if using different domains instead of language prefixes?
I'm not willing to test this (at the moment) because having to less time till May. Sorry about that.

Looks good MichaelK - thanks... Although I have issues with the ways you handle the slashes.

(1) No need to trim the slash off the front manually, surely trim function following that will handle removing slashes off the front and end?
(2) Why do you need to check for double slash (the // test)? Where would that ever come up?

1 and 2 are related to each other. Without 2 you should use rtrim. When using trim you get different string with $_REQUEST['q'] == '/fr/what-ever'.

$request_untrimmed == '/what-ever'
$request == 'what-ever'

Another solution could be:

  if ($language->prefix == $request_untrimmed) {
    $request_untrimmed = '';
  } else if($language->prefix .'/' == substr($request_untrimmed, 0, strlen($language->prefix)+1)) {
    $request_untrimmed =  substr_replace($request_untrimmed, '', 0, strlen($language->prefix)+1);
  }

Now I think this is even the better way because it causes no error for $_REQUEST['q'] == '/fr-what-ever'.

The // is not really necessary. It would only come up if anyone make a typing mistake;) When I wrote this code I was just searching for more features to implement because i was angry about my inability of finding a solution for the above mentioned redirect 'fr/node/4 =>fr/about-us-french' (#10)... May be the way I did it in #9 is better for the official release;)

And here is the patch with the #13-code and without the //-test.

#153950: Endless loop with i18n deals with the same issue in D5.

- Please use diff -up to create patches. See http://drupal.org/patch/create for further information.
- global $language should be at the top of this function.
- To ensure that $language->prefix won't be changed during this function, it should be copied into a new variable $prefix.
- A single preg_replace('@^'. $prefix .'/?@') would be much faster than multiple string comparisons, substr_replace(), and strlen() in the first if condition.
- Wrong indentation for drupal_goto() in the second if condition.
- $request_untrimmed is poorly named, because it gets trimmed in this function.

Sun - you should work for DrupalToughLove!

I'm going to try knock this one on the head this week (along with D5)...

on my D6
i applied the #14 MichaelK's patch, nothing..
then #4 MichaelK, nothing..
then i replaced all the $_REQUEST['q'] based on these lines:

global $language;
$request_untrimmed = $_REQUEST['q'];

and working well..

on the D5 just the #4 MichaelK's things was necessary..

thanks.. good job!

Re-rolled patch in #153950: Endless loop with i18n for D6.

Are there any updates on this issue? I would use Global Redirect, but I have multiple languages (D6). (subscribing).

I am also having this issue, using i18n, any updates? thanks for your work! I can test stuff if you tell me what to do. (subscribe)

The patch in #18 actually completely works for me. I get no errors whatsoever.
I have a Drupal 6.2 site with 3 languages, and language negotiation set to 'domain name only'. I access the site through 3 different top-level domains.
Well, this just works for me, thanks. Hopefully there will be a D6/i18n ready GlobalRedirect soon ;)

the patches above don't work for me on drupal 6.3. here's my solution. it's very simple, just modified one line in file language.inc, see below:

// Search prefix within enabled languages.
foreach ($languages as $language) {
if (!empty($language->prefix) && $language->prefix == $prefix) {
// Rebuild $GET['q'] with the language removed.
$_GET['q'] = implode('/', $args);
return $language;
}
}

to:

// Search prefix within enabled languages.
foreach ($languages as $language) {
if (!empty($language->prefix) && $language->prefix == $prefix) {
// Rebuild $GET['q'] with the language removed.
$_REQUEST['q'] = $_GET['q'] = implode('/', $args);
return $language;
}
}

i think this solution is more essential. please test it. thank you.

I've committed a version as 6.x-1.0 and I've tested it on my dev environment pretty thoroughly and cant break it.

http://drupal.org/node/290943

Please let me know if this doesn't work for you and we can try adjusting it.

Marking as fixed as I cannot reproduce any endless loops anymore with the 6.x-1.0 version.

Sorry but has to reopen as this not seem to be fixed. I get hit by this bug on a fresh install of 6.3, apart from defaults only book and blog modules activated, however I installed using Swedish as the default language, hence locale is activated as setup did that. The only languages I have is swedish and english.

Activating the module globalredirect-6.x-1.0 (or the dev version) immediately result in Firefox trowing a page load error:

Redirect Loop

Firefox has detected that the server is redirecting the request for this address in a way that will never complete.

The browser has stopped trying to retrieve the requested item. The site is redirecting the request in a way that will never complete.

* Have you disabled or blocked cookies required by this site?
* NOTE: If accepting the site's cookies does not resolve the problem, it is likely a server configuration issue and not your computer.

and the only way to get my site back is to manually edit the db file to inactivate globalredirect. So there is still something missing in that patch. I use clean URL's, and have tried to switch them off as well, but no change.

poop...

yettyn could you explain your locale configuration fully please and I'll try to replicate the issue.

explain? not sure what you mean by that but anyway... I will take it from the beginning.

I untar my 6.3 tarball in web root, so drupal lives at /, I untar the tarball for Swedish translation on top of that, run install and choose Swedish as install language. Everything goes fine. In language I have listed first english, then swedish and swedish is marked as default (standard in swedish). So I have a totally swedish GUI. In locale settings (Inställningar) I have None (Ingen) selected for what in swedish is called "språkförhandling" which literary would come out as something like "language negotiation", not sure that is what it says in english version though.

Anything else you need to know? Just tell me what you want me to do to dig up necessary info and I will try it.

Just some update, I switched to English as default language (keeping swedish as an option) and then I have no problems with activating Globalredirect. but this may already be known.

some further info, and partly solution.

In Language config, if I change language negitiation from None to the 3rd alternative (haven't tested the others), Global redirect now works. I am not sure if that's how I want to have it though, just started to build the site, so not sure yet if I even will have it multilang or just swedish.

Ahh so the issue appears to be language negotiation!

Which option are you trying to use? I'm wondering if sites will also break with a language domain too...

Initially I used the None option, and that's when Global redirect doesn't work. I have now tested all of them and the only one that seem to work is "Path prefix with language fallback. ", all the others give the redirect loop error.

That should pinpoint it I guess, or at least hope.

I think there is more to it as I decided to build my site in Swedish only, hence disabling English. Now Global redirect causes a redirection loop error, no matter which option for language negotiation is used. So it seem somehow module doesn't like other languages then english, but maybe this is an i18n flaw really, I don't know.

Ok, I'm having the same issue and did some testing.
I'm using drupal 6.3 with spanish as the default language and english deactivated (only those 2 languages installed).
With: "None" option in language negotiation.
That configuration gave me endless loop.

I tryed using the: "Path prefix with language fallback".
Endless loop.

I don't really need english in my site but i wanted to try having 2 languages activated so i installed portuguese translation and activated it.
This gave me endless loop with the "none" option (in language negotiation)... but it worked great with "Path prefix with language fallback".
The problem is that it changes all my links from example.com to example.com/es

The second option: "Path prefix only" just shows the frontpage and endless loop for all the others.

bugger. Will have to do some testing. I thought I had this licked! :-(

Cheers for the info guys.

This will probably not solve it, but I noticed that you forgot do do the hook_help change from 5.x to 6.x, it's just 2 lines in globalredirect.module

function globalredirect_help($section) {
  switch ($section) {

need to change to

function globalredirect_help($path, $arg) {
  switch ($path) {

as it's such a trivial thing I don't bother to open a new issue for it.

Getting this issue to with french as default language and english disabled.

Using drupal 6.3
Content translation disabled
Global redirect 1.0

I get endless loop with all pages.

I'm bumping the priority of this, at it will render a fresh site (ie., one that hasn't changed any language settings) unusable.

If it helps, I was running into a similar problem until I updated my Global Redirect Module to the latest version (8-5-08 I believe the date on it is). After updating, I no longer get endless loop errors. Also, I am using the path prefix, ie http://example.com/es/node, and Drupal 6.3 with the Content translation and Locale core modules enabled.

I encounter exactly the same issue. I use drupal 6.3 and I have franch as default language ant english, which i don't use.
When the former globalredirect module was activated, i had no problem. Since i updated the module to 6.x-1.0 i have endless loop.

Thank you for your help

I'm having a similar issue and am torn about whether it should be open in a new queue or not. The difference is that I'm not running any form of internationalization.

Upgraded a site from Drupal 5.9 to Drupal 6.3.

Things seem to work ok for a time. At some point (the one time I tracked it for sure it was when I turned off Site Maintenance) all pages but except the front page stop responding. I've looked at the url_alias table and unlike some other issues there don't seem to be duplicate paths in there. This, however, affects all URL's including admin pages and /node/##/edit.

One interesting distinction is that it happens in browsers as Anonymous or a logged in user. However requesting a URL with CURL is at least able to successfully get the access denied page that Safari and Firefox are not shown. Disabling Global Redirect causes the site to begin functioning again.

Here is my current module set which will cause the problem if Global Redirect is on... It will with most of these off as well but this is what's running at the moment:

Drupal core
Drupal 6.3
Includes: Aggregator, Block, Blog, Comment, Database logging, Filter, Garland, Menu, Node, OpenID, Path, Ping, Profile, Search, System, Taxonomy, Update status, Upload, User

Modules
Drupal Administration Menu 6.x-1.0
Includes: Administration Menu

Amazon 6.x-1.0-beta3
Includes: Amazon API, Amazon Filter

Content Construction Kit (CCK) 6.x-2.0-rc4
Includes: Content, Node Reference, Option Widgets, Text, User Reference

FileField 6.x-3.0-alpha2
Includes: FileField

ImageAPI 6.x-1.0-alpha2
Includes: ImageAPI, ImageAPI GD2

ImageCache 6.x-1.0-alpha2
Includes: ImageCache, Imagecache UI

ImageField 6.x-3.x-dev (2008-Aug-08)
Includes: ImageField

Mollom 6.x-1.3
Includes: Mollom

Pathauto 6.x-1.1
Includes: Pathauto

Token 6.x-1.11
Includes: Token

Themes
Nitobe 6.x-1.6
Includes: Nitobe

same issue here. using drupal 6.4, core locale module enabled, 2 languages (en & tr) activated, tr is the default.

Same issue after Global Redirect upgrade to 6.x-1.0.

Environment: Drupal 6.4, all of contirbuted modules disabled but Global Redirect; just Polish translation enabled and set to default, language selection set to none (site is not multilingual, not using prefixes or any other method to select language). Clean urls enabled, rewrite base set to "/" (as it should be).

Trying to visit "www.example.pl/aaa" gives a redirect loop.

None of:
- undefining rewrite base,
- changing language selection method (to any of four available),
- disabling Content translation & Locale
helps.

Disabling Global Redirect or commenting out lines 82-84 in globalredirect.module does help.

These lines are:

if ((empty($language->prefix) ? $alias : $language->prefix .'/'. $alias) != $_REQUEST['q']) {
drupal_goto($alias, $query_string, NULL, 301);
}

For the example address above, values of variables before the statement are:
$_REQUEST['q']="aaa"
$language->prefix = "pl" (should it be defined, there's no prefix in the request?)
$alias="aaa"
$query_string=""

So basically, it checks that the request doesn't start with a prefix, it does not, and redirects again to the same place (without the prefix). Not sure if this is the real problem or not, maybe this will help understand what's going wrong nevertheless.

subscribe

haven't anyone try my solution at #24 (http://drupal.org/node/216271#comment-928145)? that's the essential solution to this bug. i think somebody with the right permission should commit it to the core.

@wilson98:

Doesn't work for me (neither does replacing $_REQUEST['q'] with $_GET['q'] in the globalredirect.module; also it can only help when using prefix negotiation which is not the case), however you seem to have found another problem ;)

$_REQUEST doesn't automatically update on changes to $_GET, a test of that. So, updating just one can cause trouble.

Nevertheless, isn't $_REQUEST supposed to equal merged $_GET, $_POST, and $_COOKIE (with a possibility to define overwriting order)? If so, rebuilding based only on a value from $_GET still seems risky to me, unless 'q' won't be ever defined through a form here. Separately updating q in all four arrays (where defined) would be safer.

I am using Locale. After setting Russian language as default i cannot enter /admin page. Problem is "redirect loop".

it seems that the system use $_GET['q'] as system path and $_REQUEST['q'] as request original path for other modules such as globalredirect to use if needed, so it won't work if you just replace $_REQUEST['q'] with $_GET['q'] in globalredirect.module.

subscribing...

The problem I think lies in the fact that the following line of code in globalredirect.module does not account for the language_negotiation variable:

if ((empty($language->prefix) ? $alias : $language->prefix .'/'. $alias) != $_REQUEST['q']) {

I have to little experience with the locale module to be sure what to change, but when language_negotiation is set to none, the language prefix should not be applied, even when it's non-empty.

There was some discussion of the i18n_frontpage at the top of this issue. I'd just like to point out that i18n_frontpage does not work as an internationalised variable at the moment so don't rely on that in your tests. This doesn't change most of what is written here but might help some readers (see #249694: Multilingual front page and a "page not found" error).

Does anyone have a plan of action in mind to fix this critical bug? Where do we start? Should we try to build a modified version of the patch at #153950: Endless loop with i18n (same problem in D5)?

Various comments show the the cause seems unclear... can anyone spell out what the patch should do to fix the issue or is it back to square 1: lots of testing still required?

I can try to find a solution if I have time. I just need to know from everyone that has problems, the following data:

- List of languages that are active
- Links to the translations you are using
- Default language
- Your value for the language_negotiation setting (find it at admin/settings/language/configure) (None, Path prefix only, Path prefix with language fallback, Domain name only)

For me it would be:
- Dutch, English
- Dutch: http://drupal.org/project/nl
- Dutch
- None

I agree with the comment #50. The code assumes that when $language->prefix is set drupal_goto() will add the prefix. This doesn't happen in two cases: when language negotiation is none or domain; or even when the negotiation is path based, but the requested language is the default one (see: http://api.drupal.org/api/function/language_url_rewrite/6).

Attaching a patch that makes globalredirect use the same prefix logic as drupal_goto() does. Seems to work but definitely needs testing ;)

Can we please get the patch in #54 reviewed and tested please. Thanks for working on this guys. I am personally at a loss with it, I dont get all this i18n stuff ;-)

I can confirm that it works for my use case (as described above). Thanks for the patch!

Hi guys,

I never really worked with globalredirect before thus I never really experienced the previous bug. However I tried this patch out on two different installs - one path language negotiation and one domain language negotiation. Both worked nicely.

The only thing is that under domain language negotiation, a node link will still work in the wrong language - eg. you have en.ex.com and de.ex.com and you create English node 1 then you can still access it at de.ex.com/node/1 - which is actually duplicate content - however I suspect globalredirect always worked this way so therefore it's not part of this bug.

So I say apply!

May be true, but it still is a bug, as Global Redirect promises single urls for all content.

Yes, it's a bug. But not a bug related to this issue; and we like to keep issues to one issue per issue now, don't we? ;) So, goto() #201675: Redirect to version in native language and help with getting this glitch fixed. :)

For this issue's patch, it might perhaps be nice with a comment saying that the logic was lifted off of drupal_goto(), so that if it starts working funky, one can quickly go to drupal_goto() and see if the logic has changed there. Just a suggestion, and definitely not something I'd want to remove the RTBC for. :)

Extended the solution to front pages (module handles front pages separately, somehow skipped that before), added some comments and replaced a single tab with spaces :)

One interesting thing is that language_url_rewrite() takes a path and does not use it at all (maybe it should be called something like language_options() and just take one argument?).

Could someone truly using a multilingual front page test it, please.

Could someone truly using a multilingual front page test it, please.

Could you please clarify what you mean by this? Can you give us an example of one?

I don't have any page that has more than one version of the frontpage. Not sure if I can reproduce the setup that such a site would actually use.

My test was: point Drupal to the front page for the default language and create a language specific aliases for other pages (for example with the path negotiation www.example.com/en and www.example.com go to the (default) English version, while www.example.com/es gets you to the Spanish version). It works, no redirection loops, but i guess there are other methods of making a multilingual front page, so the test may not be sufficient.

I think your test is satisfactory. There is only one simple way to make a multilingual front page and I think it's what you've described. Set front page as (e.g.) 'home' and then create node in each language with alias 'home'. I actually tested the last patch with this setup and it worked.

The i18n_frontpage variable doesn't work at the moment without custom modules/core hacks so I think we can reasonably ignore that case until it's fixed in i18n (if that ever happens).

Tried it again, works nicely, was about to put it on a live site but found a bug:
On my site english has no URL prefix, but other languages do. www.example.com/node/1 redirects correctly to an English page, but www.example.com/nl/node/4 redirects to www.example.com/nl/nl/url-alias. Obviously, there is one "nl/" too many in the path. I assume this happens for all languages.

I applied this patch. And it works fine. No endless loop. Thanks guys!

Yes, that's a bug, thank you for testing. Shouldn't have added the prefix to the alias, attaching a small fix.

Excellent, it works. I have applied #66 at www.cai.org and will soon also do it for another site. I think this page should give you quite a few test cases to try out if you are still wondering about anything.

Maintainer, please commit.

This is awesome news!!! Nice work guys!!!

Tested the patch and it is working for me as well.

Just for the record:
D 6.4 fresh install with German as default and only language
"none" set here /admin/settings/language/configure

modules activated before global redirect:

Database logging
Help
Locale
Menu
Path
Taxonomy
Update status

Advanced help 6.x-1.0
Advanced help example 6.x-1.0
DHTML Menu 6.x-3.x-dev
Administration Menu 6.x-1.1

Thanks :)

I can no longer replicate any endless loops on my dev system using English as default and German as a second language.

This patch has been commited to 6.x-1.x-dev along with several synchronisations with the DRUPAL-5 branch.

Thanks for all your help everyone! Much appreciated!

Cool. I guess you'd better update the project page.

I'd like a few people to test DRUPAL-6--1 to confirm that it doesn't break anything else before I release it as an official release. At that point I will announce it on the project page :)

Cheers,
Nick

Deployed latest DRUPAL-6--1 on drupal.hu (well, living on the edge :). Looks good so far.

Thanks Gábor, I'm glad to hear its working! This is very promising!

EDIT: Gábor, does drupal.hu have and translation "stuff" enabled? Eg, nodes are hungarian by default but could also be english, etc?

Working great for me.
Spanish as the default language, portuguese activated and english deactivated.
tried it with: none, Path prefix with language fallback and Path prefix only in language negotiation.
All working.

This is sounding VERY promising!!! Anyone else?

Drupal 6.4, core locale module enabled, 2 languages (en & tr) activated, tr is the default. No problems!

This is looking VERY promising... 3 working sites. If there are no complaints by the end of the day I will promote the current 6.x-1.x-dev to a 6.x-1.1 :-)

Have been waiting for this... THX

Why not promote it now :) - anyway U know best. I'm just impatient, cannot wait.

Good job.

/FAF

The last thing I want to do is put a 1.1 release up and say "GOOD NEWS FOLKS, THE GREAT PEOPLE IN THE ISSUE QUEUE HAVE FIXED THAT ANNOYING BUG WHICH CRIPPLED MULTILINGUAL SITES!!!"...

... only to have someone post back here saying "ah, but you didn't think of the situation where [insert situation here]"...

:-)

Yes that's understandable....... I need it for a production site, so...

At least there is light at the end of the tunnel.

I'll check back Monday, to checkout the status.

Good karma to u all.

Tested working on another site:

"Path prefix only."
Languages: de(standart), en, ru
A whole bunch of modules like i18n, admin_menu, cck, views, dhtml_menu, fck, filefield, imagapi, imagefield, imce, language_icons, translation_overview, ...

Sweet! :D

I have tested the latest -dev on my local server, using three different domains and language negotiation based on 'domain name only'. I haven't seen a glitch ;)

I think I had 6x-10 version working on a multisite installation, but after reading the problems above maybe I was wrong and always accessed the aliased nodes never checking the node/# redirects.

Anyway in a blond moment I changed language negotiation from Path prefix with language fallback to None and got redirect loop on everything except home page (my home page is normal /node).
I removed the Global redirect module folder and then I was able to access the admin pages and content too, although there were problems with path aliases.

Before that the english language didnt have prefix, after I gave it prefix "en" it seemed to fix the links (english is not default language for the site).

I'm now using the Path prefix only option. The 6x-10 version always causes redirect loop no matter what I do.

I installed the 6x-1xdev and it seems to work (no redirect loops) but only partially, the default language is redirected ok, and so are the paths with the en prefix

node/## --> red
en/node/## --> en/blue

but the en content is also accessible through node/## (without en) and those links aren't redirected.

Is this Global redirect issue or am I missing something in my settings?
What does lang prefix actually do, should I delete the prefix for my default language (English didn't have a prefix when it was default).

6.x-1.0 is not patched you were lucky it worked ;) The language prefix is the thing you add to the URL to request, chose a language.

If you set a prefix for your default language you'll have all content available under two URLs. On the other hand it's hard to predict what an empty prefix for a non-default language would do (not a great idea probably).

In short:
- default: empty prefix
- others: some prefixes

Check language of aliases for the English content. If language of an alias (Site building-->URL aliases) is set to the non-default English and you type node/# (so the requested language is the default one) there is no alias for the given node for the given language and you won't get redirected. You may want to set up aliases for the default language or language neutral aliases (for the English content too). One possibility is:

node/8 in some language, aliases:
- English: eight-->node/8,
- All: ocho-->node/8,

then node/8 should redirect to ocho, en/node/8 to en/eight, and any other valid prefix would go to prefix/ocho too.

There is an idea of choosing language based on the content's language (for example: node/# is in English, so we should automatically add 'en' to the address; more or less a new language negotiation method). Thread with a discussion about this is mentioned somewhere above.

Concerning the prefix for the default language I was wrong. You'll only have front page under two URLs ('/' and 'prefix/'), but that's a bug.

How do I get in the choice of language through block "switch language" URL type "http://example.com/ru/node/" looks like "http://example.com/ru/"?

Please don't hijack issue queues... Your question would get a better response from the forum.

Is there any guess when there will be the next release of the module where redirecting bugs are fixed? Thanks for all your work.

subscribe

After having endless loop problems with different languages I applied patch presented here: http://drupal.org/node/216271#comment-1007577 and global redirect stopped working properly with new content. After applying the patch new pages that I created were not accesible with their path aliases. I can see them with node/[number] but not with the alias. I'm using Drupal 6.4.

After replacing the patched file with the original file the module seems to work normally. However pages I created when the patch was applied still remain accesible with only the node/[number]. node/[alias] leads to Page not found.

Anyone experienced same kind of behaviour?

Not that I experiance the same error but take a look at /admin/build/path/list and see if the questionable aliases are different to the others in some way. Aliases have languages too which can lead to the point that a node has an alias but can't be accessed via the alias. Probably doesn't relate to your problem but it might be worth looking at.

I don't see a way it could possibly interfere with the normal creation of aliases, would be interesting to learn what's wrong with yours. Do they work without Global Redirect (with the module disabled)? Could you give some more info about your setting (installed languages, language negotiation method, content language, aliases language, other related modules etc.).

I understand that you applied the patch against the 6.x-1.0 version. This should still work, but would be probably better to try with the 6.x-1.x version (patch already applied).

OT: The site I have been talking of doesn't use global redirect. I had the problem there because I like to have the admin interface in English for myself allthough the site is German by default (only. no /de/ /en/ etc.). Now the first few nodes I created to set up the basic menu structure recieved english url aliases resulting in the menu items linking to node/x instead the alias. When the url alias was typed in manually it gave back a 404. My guess is that these URLs were created due to the settings in my user account or maybe I started without activating the german language in first place. As I said this probably doesn't have to do with this issue but maybe it is worth mentioning.

I have installed one additional language, finnish. I looked my path aliases and some of them has english as language and some has all. I don't know what is the meaning of language related to path aliases. My language negotiation is set to none.

I also have applied a patch that is related to language negotiation method: http://drupal.org/node/222401#comment-844115

This seems similar case as yours, Daniel.
The patch related global redirect works. But when I apply patch related language (I want to have english for admin and finnish for others) the problems starts. Everytime I create a new page I get path alias node/[number] and referring with the node/title gives me Page not found. These pages have finnish marked as language.

What was your solution Daniel?

This isn't directly related to global redirect but I guess there are a lot of people who would want to have english for admin and some other language for others..

I don't really have a solution and I've given up trying to get the interface language I'd like via Drupal 6 core. So I don't have the patch applied anymore. I'll take a look at http://drupal.org/project/preserve_language maybe that does what the patch does without the url aliases problem: http://drupal.org/node/222401#comment-1086160

Has this been fixed I just activated global redirect and had the endless loop problem on my db upgraded from 5.0

@deverman: Yes this has been fixed. Anyway you might be seeing a related error so usually you should should open a new support request issue and link here.