Use preferred language on per-user basis instead of global setting [#1239204]

Problem:
Currently, the module only allows one administration language to be set. In the event that there are multiple administrators, this language is used for all of them, even if some don't understand it (or would simply prefer something else).

Proposed solution:
Use the user's own preferred language (from user settings) instead of a single global setting. This could be optional - just add a radio button somewhere that defines whether to honor the global setting or to fetch the language from user settings.

So, essentially (I know this isn't the way it should be done, but I'm not yet familiar enough with the API to do it properly), in admin_language.module.php, instead of:

admin_language_init(){
...
$admin_language = variable_get('admin_language_default', 'en');
...
}

use something like this:

admin_language_init(){
...
global $user;
$admin_language = $user->language;
...
}

Comments

Comment #1

wulff CreditAttribution: wulff commented 5 August 2011 at 14:02

Assigned:

Unassigned

» wulff

This feature has been ported from the D6 version of the module. Please test the D7 development snapshot which will become available within the next 12 hours.

Comment #2

LarsKramer CreditAttribution: LarsKramer commented 5 August 2011 at 23:17

To implement this, I don't think we should set admin language to the same as user language. An admin might want to see normal content pages in the default language (for example Danish) but admin pages in English.

I think a better option would be to include a new fieldset on the user edit forms where people with the Select administration language permission can select their admin language.

We might as well include the other options in this fieldset to make all options per user.

Comment #3

ataimist CreditAttribution: ataimist commented 8 August 2011 at 08:06

The feature does not seem to work. The settings page is fine, but the language cannot be selected in user settings. The label ("Default administration language - Select the default language to use for all administration pages. See the administration language settings for a list of affected pages") is visible, but the actual form element is missing. I get the following error message, no matter how many cache flushes and reloads I do:

Notice: Undefined index: #title_display in function form_pre_render_conditional_form_element() (line 2991 in file /includes/form.inc).

So I would guess that there's something wrong with _admin_language_user_form_add_language_select(), but I can't spot it.

Comment #4

ataimist CreditAttribution: ataimist commented 12 August 2011 at 08:45

Well, the #title_display notice seems to disappear if '#title_display' => 'before' is added to the form definition ($form['locale']['admin_language']) in _admin_language_user_form_add_language_select(), but this does not fix the problem of missing radio buttons / select element (unsurprisingly, as it's only a notice anyway).

I did some debugging, but couldn't find anything wrong with the form definition - the options are defined properly, as is the element type and default value.

Here's the HTML I get:

<div class="form-item form-type-radios">
  <label>Default administration language </label>
 <div class="form-radios"></div>
<div class="description">Select the default language to use for all administration pages. See the <a href="/fi/admin/settings/language/admin_language">administration language settings</a> for a list of affected pages.</div>
</div>

So something somewhere knows that it should be printing radio buttons but isn't doing it :)

Comment #5

wulff CreditAttribution: wulff commented 22 August 2011 at 09:20

As far as I can tell, this was caused by the radios widget being added too late in the process.

Please check the upcoming dev snapshot, which contains a fix for this issue.

Comment #6

ataimist CreditAttribution: ataimist commented 12 December 2011 at 09:17

Sorry about the long radio silence. There's still something wrong with this setting, but it's difficult to say why that is.

Let's start with the selection on the user page. The radio buttons are now there, and they correctly list the languages in use. However, the 'Default administration language, currently [default administration language]' button always claims that the default admin language is English, no matter what is actually chosen in admin/config/regional/language (the similar 'Default site language' button works, however). It also appears to be impossible to actually change this setting - 'Default administration language' is always selected when the user setting page is loaded, so it seems that any changes made are not saved (though this might simply be a case of setting the wrong radio button as selected - I know, I've been there).

Now, that might be the root of the problem - perhaps the selection is simply not saved, and everything stems from that. We've been seeing rather weird behaviour, however - at times, it almost seems like the language being used is next to random (on a settings page, you might see the description in language A, but the form is in language B). For example, when creating a new view, the 'Create new view' page initially displays in language A, and when you click the submit button, the (same) page changes to language B and you have to submit it again (there's probably some AJAX trick at work here). Admin menu also seems to switch languages whenever it wants to, just to mess with me (...though it's possible that this is simply a case of translated strings not being available for a particular language) :)

Good work so far, though - I'm guessing these problems all stem from the admin language not getting set (or read) correctly somewhere.