Provide a distinct administration user interface language option

Old Issue, but it's a good question - admin in different language? Available, or move to D8?

Should this live in contrib? If so please set to closed(fixed).

Marked #263887: Ability to set language of administrative backend as a duplicate.

Looks like http://drupal.org/project/admin_language sets one global admin language for the whole site. Is that generally accurate? Thinking about this, it sounds like this would be per-user, so that a multilingual site can be managed by people in their own language. I assume the problems solved here include that the language changes when you hit a node that you want to translate for example, from where admin links would get to keep that modified language, that is not desired. I agree it is probably easy to implement per site instead of per user though, given that if we implement per user, it becomes a problem to display the admin language selector to some people on their profile but not to others. It is hard to tell generally if someone has "some kind of admin access" or not.

Maybe we should think of this as a second session language provider that only applies to admin pages (with a block specific for that to let admins set it?). Blocks don't work well with the Seven theme though... Well, just thinking out loud here :)

Marked #744656: No translations for admin interface and #289114: Set different presentation language for Admin only as duplicates. There is clearly *lots* of interest in this.

Subscribing.
It should also be possible to hide the admin language from "Language settings" on the user edit account form if the admin language is not one of the "public" languages. And if the site is a single language site where the admin language is different from the default language, it should be possible to hide "Language Settings".

Retitling to better explain the feature request. I've pinged @wulff (the admin_language module maintainer) if he would be interested in integrating some of the module functionality in core. Looking at the code, it seems to be doing numerous other things, like optionally forcing language neutral nodes and path aliases which definitely sound unrelated.

As I was writing in #1036212: Use hook_language_types_info() instead of hook_init() in D7, I think the admin language provider is the way to go too: it could set the default admin language using the user setting and falling back to the default admin language.

Where it gets tricky is that it would change the content language as well with our current default fallback method in core, so we'd need to expose those settings somehow to let people disconnect content from interface, which is the primary goal of this feature anyway.

The provider should be defined to be assignable only to the UI language. To actually take advantage of this we should make content language negotiation enabled by default in D8: node translation, if present, could exploit it through the tnode/1 feature we were speaking about in the last months.

@plach: it does sound like a usability problem if we need to expose both interface and content language config separately in D8, that does not sound like good news. However, I see that trying to not inherit to content language if it was picked by the admin language one would be a bad case of special casing that we should not pursue. Hm.

This should be already possible in D7 core: just enable the User language detection method on top of the URL one.

Tagging for language negotiation too.

Anybody want to work on this?

Tagging with sprint.

The last submitted patch, admin-user-interface-language-option-322995-28.patch, failed testing.

The patch looks pretty good to me, I have a small observation:

The language_negotiation_include() function is implemented by the language module, which is not a required core module, so I think this will generate a fatal error on the sites that have the language module disabled.

After a talk with Gabor, I think a better idea would be to just remove the language_negotiation check from the #access, so then you do not need to include the file anymore. The user_access call should also be called with the user account parameter. Also, you can move the "user_access('access administration pages')" into the #access and then the code will be just more straightforward.

Looks good to me now.

But, I think we now have another issue: the user_preferred_admin_language() function generates code duplication, because the almost exactly same code and comments can be found in user_preferred_language(). One solution would be to juse use the user_preferred_language() in both cases, and add a parameter, so you will end up in having something like:

Then, inside the function, depending on the $type parameter, we will have to use (preferable in the most clever and flexible way) the right attribute. A good approach would be to use the $type parameter in a way that if you will add another type of language in the future, then the code in the user_preferred_language() should not change.

removed the user_preferred_admin_language() function and added a new parameter for user_preferred_language()

also needs tests!

checked the rest of the core, user_preferred_language() is all the time called with 1 parameter, so no issue there.

But the default parameter NULL is a good idea.

tags

Can this get a screenshot?

Schnitzel explained it to me, looks like we just need to fix some of the labeling.

http://drupal.org/files/admin%20%7C%20drupal8.jpg
On the account page, we want to remove the description and clarify the label a bit. This because "Admin Language" isn't very clear, people don't know what the "Admin" is. Therefor we suggest changing it to:

"Administration pages language"

This also means that we need to change Language, to "Site Language".

http://drupal.org/files/Languages%20%7C%20drupal8.jpg
Almost all the labels here are overly descriptive, it could probably be something like:

Language from the URL(Path prefix or domain)
Language from the requestion/session paramter
Account language setting.
Language from the browser's language setting.
Account administration pages language setting.
Default site language (English)

We have to figure out whether we want setting or preference, I am not sure what the standard is.

I find the description a bit odd:

alternatives:
- Site language setting of the user.
- Site language setting of the user's account.

- "Language setting of the user for the administration pages"
- "Administration pages language of the user"

only for authenticated users

Site language (without a capital L)

Lets rename this negotiation methods in follow-up issue.

Why not just use isset($langauges[$user->preferred_language])?

isset($type) is more accurate.

follow up for texts: #1756122: Better Names and Description for Language Negotiations

thanks! fixed with using the same schema for update and install

sorry missed it before

better switch to using new Language()

dito

looks good, RTBC when green

Rebased against 8.x HEAD is much smaller now. Its only one submit handler (language_admin_add_form_submit) for predefined and custom languages.

the new patch is better now, so RTBC!

The last submitted patch, admin-user-interface-language-option-322995-60.patch, failed testing.

#1688144-19: tnid does not updated to zero after node delete maybe related?

Thanks for the rerolls.

Added a site builders' change notice for this at http://drupal.org/node/1776768 - CHANGELOG.txt patch forthcoming from rvilar.

Automatically closed -- issue fixed for 2 weeks with no activity.