TYPO3 Core

This is not a bug, its a feature (sry, i just wanted to use this phrase somewhere)

As a admin you only set up the default BE-language of a user.

The user->setup->language Setting overwrites this setting and takes precedence. This setting is usually availible for the user itself.

How to reproduce:
- Set up a user-record with english as default lang in the user record.
- Log in as this user and change user->setup->language to german > The Users Backend Language will be german
Modify (as admin) user-record language to english > Language will still be german if you log in as this user because user>setup->language is still german, which takes precedence.
- Log in an this user and change user->setup->language to english -> The Users Backend Language will be english.

Creating a user-record as admin only sets the default language. The user itself can overwrite this if he wants to. Changing the default to some other value will not have any effect.
This is expected operation. If this does not work for you, it is a bug. Please post a sequence how to reproduce. Otherwise this bug should be closed.

If you don't think this is a usefull feature, then please post a scenario how this should be handled from your point of view. I must admit, the actual handling might be confusing, but its a intended feature so far.

I looked closer and now found the two language-fields: user->default-lang and user ->setup ->language

I'm sure I never set user->setup->language, because I never use it.
being admin I always change user->default-lang. This might be not intended by programmer but it works till now.
As you elucidate the priority I think something seems to has changed the user >setup>language. The question is: what changed the value as I am sure I haven't changed it by myself? and other user are not in the system yet.
I have not all TYPO3-log-records since the beginning, but I can only find changes for the field default-language (is setup->language logged at all?)

as for the feature: it seems a good practise, but maybe the editing of default-language should be disabled if the setup-language is set (or a warning may occur)
At least there should be a mention of the precedence in the help-text of the default-language.

Hey,
I was wondering about the same thing on the devlist about 4 days ago. I think we should merge both fields to only use the "lang" field in the DB. Why?

Well... if an admin ADM creates a new user XY and sets german as default, the BE for XY should be displayed in german. When the user wants to change it, XY can modify that language parameter to whatever he wants. So, ADM only sets the initial language (= default right now, which does not work) and XY can modify it. What do you think?

I think we should work with that once we redo the task center module.

Some customer stumbled across the same problem. Actually they tried as admin to set the language for their existing users. But afaik they couldn't (without switching to the user and changing it there).

Problem was that the user previously logged in, modified his details and clicked "save", which saved the "overridden" value English for his language. Chancing the default-language to German didn't help since he had this override-value set.

Problem was furthermore increased since admin denied the user access to the user-settings-menu. The user couldn't change his overridden langauge-value again and admin couldn't change it as well in the user-admin (only the default-language).

Since in this special case at the same time "limit user to German" was finally selected the user was unable to do anything (!) in the backend. He only was allowed German, couldn't change his language away from English but was not allowed to see e.g. an RTE in any other language than German.

Suggestions:
- User should have a "neutral"-setting for language in his user-details where the default-language then takes precedence.
- Admin should have the possibility to not only change the default-language but also the effective language.
- In case the current selected language is not available it should imho at least fall back to the first allowed/available language to make the backend usable again.

PS: experienced that behaviour with 4.2.6 so it looks like that's still present in current releases

Yep, still true in 4.2 and 4.3. I'll try to come up with a merge solution for 4.4.

I still encountered the same in 4.4.2. Exaclty the beavior as by Stefan Neufeind descriped.

Just encountered this problem on 4.7