1

I am trying to translate an existing site.

I've used i18n before successfully so I'm not totally new to it. Now to my problem…

I can create content fine in different languages the problem occurs when I try to access languages (other than the default, without path-prefix) with a path-prefix. I keep getting a 404.

URL Aliases

Example:

Their system-path counterparts:

Any ideas about what might cause this?

Please note that this is a Drupal 6 install.

6
  • You are creating seperated nodes, instead of translating them, correct?
    – Letharion
    Commented Jan 5, 2012 at 13:31
  • Deleted the node and re-added as a translation just in case. Commented Jan 5, 2012 at 13:39
  • Does that help? I was about to post an answer that depends on that solving the problem.
    – Letharion
    Commented Jan 5, 2012 at 13:45
  • If you use the "Redirect" module, try to update to the latest dev version or just disable it to see if this probably causes the error?
    – Lance
    Commented Jan 5, 2012 at 13:45
  • @Letharion No it didn't help. Commented Jan 5, 2012 at 13:50

3 Answers 3

2

In reply to your fix you posted in language_initialize. It's very strange that the first arg would be empty.

So now that you've added in your changes, http://www.hillsongconference.co.uk/se/home works. However, this should be exactly the same as http://www.hillsongconference.co.uk/?q=se/home and you will see that this brings in the 404 error (whereas q=/se/home doesn't).

So I'm worndering if the htaccess file has been edited? As this is how Drupal converts the arguments in the url path to $_GET['q']. The Drupal .htaccess file also strips out leading slashes, to insure the first argument isn't empty.

You've hacked core now, which is a terrible no-no. Even if you are never going to update this site, it still needs to be fixed out of principle!

If you are running a nginx setup the correct rewrite (to not include the slash) is rewrite ^/(.*)$ /index.php?q=$1 last; not rewrite ^(.*)$ /index.php?q=$1 last;

1
  • I know amending core is the big no-no I simply did it as a last resort. I never use .htaccess (running a nginx setup here). Brilliant answer! I should have spotted this in the beginning. The config I'm using have been used on many of our sites and only now when attempting multilingual did a problem surface. Commented Jan 6, 2012 at 13:42
0

As far as I know, in Drupal 6 it is not possible to assign the same alias to two different nodes. When requesting /home the system retrieves the first internal path it encounters (/node/1) in the url alias database table and shows it (works correct for English). However, when requesting /se/home it also retrieves that same internal path (/node/1) and checks if the node's language (en) matches the prefix (se). Because this ain't true, you'll encounter the 404.

I see two possibilities. 1) Change the url alias for swedish home to something else, i.e. "start".

2) Use a view to display the node. Views keep the same url for all languages while you can use a language filter to only show nodes of the current language, i.e. the view at /home shows English nodes while /se/home (as a view) only shows swedish nodes.

1
  • This is correct normally, but not with i18n. The home page is a multilingual variable, so will be loaded accordingly for different languages.
    – Chapabu
    Commented Jan 5, 2012 at 16:45
0

Ok everyone. I've had to go into core to figure this out. I'm back and I survived the trip.

I found out what is going wrong, no idea how any multi-lingual site works with this bug in it.

File: language.inc (function language_initialize)

The problem is this line and the loop beneath it.

$prefix = array_shift($args);

Because $args is an array of parts made after imploding $_GET['q'] the first string in that array is always going to be empty let me explain that with a picture:explode()

That essentially means that the language will never be detected and the path will instead be treated like it's english "/se/home/". Fixed it by adding an extra $prefix = array_shift($args); just after it.

4
  • 1
    Hmmm... although your explanation makes sense at first glance, I am wondering if you have an error in your path. I would make sure the value of $_GET['q'] is not //se/home. I think you would get this if you entered /se/ as path prefix, for example. I am totally not sure, I am posting on a hunch. It just seems funny a mistake like this would slip by thousands of users. Commented Jan 5, 2012 at 17:49
  • @stefgosselin I do think my case is very unique. Not sure what is causing it. I've used i18n without any issues before. The path is actually /se/home and I could only solve it this way. I haven't entered anything wrong like that, I would have spotted that before diving into source code. (I even created a new drupal instance on another server just to be sure I didn't mess the basics up.) Commented Jan 5, 2012 at 20:02
  • Ok, the path is /se/home, is there any way you can have se/home? The only thing I can think of is if you have slashes in the textfield value where you configure the domain prefix. I am curious on this as I use I18N quite a bit and never encoutered this issue, may try to reproduce your issue this weekend if time allows, out of curiosity. Happy coding friend, thanks for the feedback. Commented Jan 6, 2012 at 6:23
  • I have done this without problems on a Drupal 6 site (for paths created by views). Maybe your problem is the way the language selection is handled.
    – googletorp
    Commented Jan 6, 2012 at 12:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.