Site interface language switching per user setting is broken

Tested with different language negotiation settings and is not displaying the correct language.

This patch defaults to user prefered language on language initialization.

Edited: woops, accidently cross updated and somehow I unassigned it.

Hass: this seems to be RTBC. The "None" language negotiation mode means:

The default language is used for site presentation, though users may (optionally) select a preferred language on the My Account page. (User language preferences will be used for site e-mails, if available.)

(Directly copied from the on-screen help.) Move your site to a different language selection mode where user settings are considered if you'd like to have user settings considered for the interface language.

Hoh, I mean RTFM, not RTBC.

I am definitely not fighting :)

As I have said, that setting only sets the default site interface if in the mode which supports that. There is only one mode where user settings are considered at all: the path with fallback mode. In any other mode, the user language is not user to decide on the interface language, and even if the path with fallback mode, it is only used if the user did not tell the site in any other way to use a language (eg. by using a direct path to a page with a specific language, eg. http://example.com/en/home displays the English version regardless of the user setting).

This means the user page form item description is misleading and we should componentize it and build it up based on what setting the site uses. Bug in locale_user() confirmed. The proposed patch does not go towards fixing this though.

hass: the idea is that the user understands the language she sees the register form in, or otherwise would not register. She gets the email with that language.

Changing strings is not an extremely good idea now that we are in string freeze, unless we fix translatability or critical bugs with the change. This was always language settings, and depending on the site setup, professional sites will surely have a form alter hook to align this to the expected title (which depends on the language negotiation mode and possibly site policies).

(#11 and #12)

Altered 'description' on user form depending on 'language negotiation' settings.
It will only refer to site language when this setting has any effect on it.

Feel free to postponed it as per string frozen status.

We should not even think about linking to admin/settings/language/configure and admin/settings/language in user facing text. They will not have access to that page and they should not have to anyway.

Thanks Gábor.
Without linking.

Thanks hass. Removed.

patching file modules/locale/locale.module
Hunk #2 FAILED at 225.
1 out of 2 hunks FAILED -- saving rejects to file modules/locale/locale.module.rej

Thanks Gábor, there is some new code patched. Redone.

Most of the new help text for locale went away from "site interface" languages, toward a "site presentation" language, for good or bad.

And, most of the form descriptions (with some fields on the user edit form as notable exceptions) just restate the thing, instead of using a construct like "Sets the " thing.

So I wonder if this should be something like:

-      '#description' => t('Sets the default site interface and e-mail language for this account.'),
+      '#description' => ($mode == LANGUAGE_NEGOTIATION_PATH) ? t("This account's default language for e-mails, and preferred language for site presentation.") : t("This account's default language for e-mails."),

Actually, "default" language sounds odd when your talking about a setting on a single account, but I suppose this value can be overridden in a number of instances, so "default" is correct, AFAIK.

Keith: your suggestion looks more consistent indeed.

Thanks Keith, patch updated with the new description.

Thanks, committed.

Hmm ok there is patch, its been over a year and it hasnt gone into drupal? i have d6.8 now and problem is still here? how can this be possible?

Ok patch is not working, i mean code in patch is in module, but i have the same problem as ppl year ago. I change users language but it stays default!?

I installed Drupal 6.10 , added secondary language and set the default language to English.
then i created a new user and logged in with it and changed its language to the secondary language.
I was expecting to see the secondary language as user interface language, but nothing happened and the language is still English!

If i'm not missing something It seems that the issue still exists.

Similar problem - Still not resolved in 6.11

Two languages installed, English - Default, German - Second.

New User language preference is German, but on login of this new user, interface menu's still remain in English. As soon as user clicks on Deutsch Language selection the interface does change German Language. Should not it happen automatically on login ?

Else the site functionality is working perfectly with all menus and content switching as desired except for this automatic interface language switching as per users default settings.

Any help would be welcome :-)

Same problem here, subscribing

also experiencing the same behaviour. Subscribing

This is the expected behavior of Drupal 6, in which the interface language is controlled by the URL.

RE. #33

Is this going to change in Drupal 7?

Even if it's the "expected behavior of Drupal 6" it isn't the expected behaviour of Drupal 5 users and it's really making it much more difficult to develop and admin a Drupal site in a non-English language.

Not fixed in 6.13 :-)
Is it in 6.14?...

I'm afraid this won't be fixed in Drupal 6, not for a long time at least. Look at what Damien Tournoud wrote in #33. This is unfortunately the "expected behavior of Drupal 6".

I guess this means that the developers of Drupal 6 never worked or administrated a Drupal site in only one non-English language, since this behavior makes it all but impossible to develop on a site that non-English customers is watching at the same time. (I know, I shouldn't complain now, since I wasn't there when the new behavior was created for Drupal 6. But on the other hand, I would have assumed that a great and working feature of Drupal 5 wasn't removed in favor for a less flexible solution.)

There was work going on in TF #1: Allow different interface language for the same path for Drupal 7, but right now it seems like it won't happened.

@AdrianB: what's wrong with visiting the site with a "en/" prefix?

@Damien: in our case for example, we don't want to spread our (unique) content to different paths. We'd just like to give our users the possibility of choosing the language for the Drupal user interface, not the content. Simple need.

I've been misled by actual implementation which is not like many sites do. The good example mentioned in TF #1 is Google: you change the interface language but not the result of a query... It's the same for the other web systems we have here in our intranet: we can change the language of the menus but the content remains the same. It's a matter of user comfort.

Difference between User Interface and Content must be made.

Eric

PS: and it's a pity that even though we've installed all the Drupal language packages that we need, we can only use one :-(

PP: I'll follow up TF #1 from now

I'm experiencing something similar here.
The website (Drupal 6.15) has "German" as default language, but users may have the opportunity to change the interface language (from user/XY/edit).
Looking closer to the admin/settings/language/configure reveals that they are 4 possible values (from 0 to 3) for the language negotiation. After that, looking at the API language_initialize() shows that the there's not a chance that the part of code located after the switch($mode) statement will ever been processed (because $mode will always be set to a value between 0 and 3 - the setting form).

So to fix the problem, I used to set language_negotiation variable value to 4 (which is not possible from the settings form but fits perfectly my needs).

My 50 cents: this issue can not be defined as "by design" (too easy ;) ), this is a damn critical issue. And to fix it, it looks that it only needs to add an other options to the settings or re-think what happens during language_initialize() processing.

Interesting, according to your explanation it might be possible to add the missing option using hook_form via a module.

I have similar problem. Drupal 6.15

I need default language for non-registered users and Editors to be Bosnian but English admin language. I don't need content translation so I've set Language negotiation to None.

In includes/language.inc I've changed:

    case LANGUAGE_NEGOTIATION_NONE:
      return language_default();

to:

    case LANGUAGE_NEGOTIATION_NONE:
  if ($user->uid && isset($languages[$user->language])) {
    return $languages[$user->language];
  }
  else		
      return language_default();

I'm not a programmer so this could be buggy but in my case it works just as I need.

#42 not thoroughly tested but appears to work for D6.15. I'll tell you if I find something wrong

Thx nno!

BTW the mod has to be done at includes/language.inc line 22.

#42 works - here I've converted it into a patch - which patches includes/language.inc.

I find it a critical feature - I have develop who develop the site in English, and I need my customer to test the site in Hebrew in parallel, so it can't be tested without this patch.

Amnon
-
Co-Founder - Drupal Israel
Drupal 6 RTLization project founder.

Subscribing

I confirm patch #42 is working. Test was failed because different patch format had been used.

I've tried to make a correct patch. This is my first attempt so i may fail.

I've found a major bug in patch #42/#47: all path aliases would revert to node/123.

So it's currently unusable.

I also faced this problem, tried last patches from this topic on my Drupal 6.20 and it didn't work. I would very much like to get this issue fixed, unfortunately I'm not good at programming so I can't fix it myself... Is there any workaround possible?
Does Drupal 7 have the same issue with language selection?

@andrewju
I successfully applied patch from comment #47 to drupal-6.20. with
patch -p0

@lolmaus
Aliases indeed revert to node/xxx. I guess it has to do with the problem discussed on #347265: URL aliases not working for content not in default language.
A quick and probably incorrect fix that worked for my simple case (all the site is in russian) is to run the following sql query
update url_alias set language="";
This resets all the language specific aliases to become language neutral. I guess more correct would be to patch include/path.inc to fallback to site default language when user language specific alias is not found.

If you click in "view details" you will see the patch failed for this reason: "Ensure the patch applies to the tip of the chosen the code-base."

Meaning your patch wasn't against the latest 6.x-dev codebase.

You should also fix the patch filename

http://drupal.org/node/1054616
[description]-[issue-number]-[comment-number].patch.

I can't believe this never got even considered, it is, after all a very simple fix.

Attached is a re-rolled patch against dev, I also add a minor description change to the user's account change that it displays the description about the site language to LANGUAGE_NONE as well.

Let's see if this patch pass testings.

Oops, sorry, small correction.

This is still unfortunately a functionality change. When you pick no negotiation, that is what you get. We cannot unfortunately change functionality in a stable Drupal version like this. The problem is perfectly fixed in Drupal 7.

The kind of patch that needs to get into Drupal 6 was last posted in #23, to clarify the option's explanation for the users.

Not sure I understood your last comment. Patch #23 seems to have been accepted somehow, as something of what's there is now on the code. So, is there anything to be accepted that I can contribute. I know this can be considered a functionality change, but it may be also a bug. You would expect to be able to choose a default interface regardless of the negotiation. Anyway, I wonder if by choosing PATH even without it, it would work as I am hoping for, if so, maybe this patch is not really needed after all.

Anyway, if no work is needed on this issue or any further patch will be considered it may be good to just close this isue then.

Right, sorry. The description now properly explained how it works. This is as far as we can get in Drupal 6. There are way too many websites dependent on certain configurations working like they did in the past 3+ years that Drupal 6 is out, and we cannot just change behavior under them. Use the negotiation format applicable for your site, and you should be fine. Moving back to closed then as per #24.