Very strange i18n behaviour - Follow up

Perhaps I was a bit premature. The solution suggested in http://drupal.org/node/70547 does fix the problem. It seems to be a sensible solution and not a "cludge". But I'm still wondering if this is the 'official' solution to the problem. This change is not in the current CVS version.

It works but only when it wants to. Strange!!!!!

I implemented the following changes as recommended in the above threads
- 'site_frontpage' in settings.php
- page.inc
- template.php

On my local test site it seemed to fix the problem immediately. Returning to the home page from a node retained the currently selected language. This worked from the breadcrumb as well as the logo.

My internet site seemed 'stubborn' but after playing around with many settings it worked ther as well.

I was just about to close this chapter and move on to something else, when I noticed that the problem was no longer fixed. The old behaviour was still active. Namely, from a german node returning to home page brought up the default english page. I have no idea why.

Now my test site is back to the old behaviour.

I have no idea what's going on. My hunch is that i18n is actually working with these changes but something in the menu system and or caching may be causing a problem.

It would be nice if someone could address this problem who has more knowledge of the overall arcitecture.

Thanks

Andy Potter

Ok things are not as bad as it seems.

The Problem I had was that I was logged in to my Drupal site as a user. The i18n module forces the fornt page to revert to the preferred language of the current user even if another language has been chosen.

Suppose User-A has a preferred language of english but uses the language switcher to switch the site to german. The entire site will now be rendered for User-A in german, except for one exception. As soon as User-A returns to the page the language is switched back to english.

This makes some sense. The whole point of a preferred language is that the site adopts this language whnever the user logs in. However, it would be nice if the site would stay in a language, when a user requests it.

The problem is how do you distinguish between the following two cases:

• The user comes to the drupal site from "outside", starting a new session but perhaps through cookies still logged in.
• The user is browsing within a drupal site and clicks on a link to go back to the front page but intends to browse further.

My impression is that the current logic of i18n does not distinguish between these two cases and assumes that every visit to the front page requires tha language to be set as if it is a "first" visit.

A possible solution would be to override the preferred language setting of a user when the user uses the language switcher. This state would remain active as long as the user is logged in. Even when they are logged in over a long persiod of time through use of cookies. When the user logs out this setting would be set back to the preferred setting from the user configuration.

-------

Is anybody reading my posts???????????

Well it's good to know that I'm not talking with the wind. ;)

I've had a look at your solution and it does work. The thing I'm uncertain about is if it is conceptually the right place to make such a change. Does it fit with the overall architecture and concept of Drupal? Does a change like yours cause side-effects somewhere else? Do the changes I have made fix and/or create problems in other areas? I don't know. And I don't know enough about the entire system to make that decision.

The reason I was so concerned earliar is that I thought the strange behaviour was occuring for all users. Once I discovered that it behaves differently (i.e stays in one language) for anonymous users I was relieved.

I'm fairly satisfied with the i18n/translation module now. It took a little getting used to but It is now very useful and powerful. The problem I've brought up here, I would now classify as an unpleasant glitch. Most of the time a registered user will browse the site in their preferred language anyway and thus never come across the problem. I'm planning on leaving the code as it is. Maybe something will pop up in the future that requires a change. I'll just wait and see. In the mean time maybe the developer(s) can decide on which approach is best and include that in future releases of the module.