Add get_admin_locale() that is separate from WPLANG / get_locale() / get_user_locale()

[apedog]

As a WordPress administrator and developer that works with RTL-language sites, I am intimately familiar with the frustration of dealing with mixed RTL/LTR texts. Even when done correctly the experience is frustrating and obstructs daily workflows. In small and major ways.

RTL and mixed RTL/LTR interfaces are a major obstruction to the user's experience. As a result, many administrators and developers of RTL sites prefer the backend to be in English - LTR only. The addition of get_user_locale(), allowing the user to set the backend-language in WordPress 4.7 was a great improvement in this regard.

However, notification mails sent by WordPress are still sent in the site locale language. As well as a myriad of plugins and options that default to site locale or mix them when translation texts are available for some but not for others. Plugin update logs (some translated, some not), The 'Edit Post' button in the toolbar, date formatting everywhere, etc.

Feature request:
Add an option to set the administration locale/language separately from the front-end locale/language and separate from the user locale/language. Using a function like get_admin_locale() and/or a constant.

[johnbillion]

Thanks for the report @apedog .

Just noting that there's a couple of plugins that provide this, ​https://wordpress.org/plugins/english-wp-admin/ and ​https://wordpress.org/plugins/admin-in-english/ come to mind.

I've seen this problem too and I think investigating the feasibility of this would be good.

[apedog]

Thanks :)
Plugins are a partial solution. They basically do what get_user_locale() provides natively. They're not much use since WordPress 4.7.

For example, they cannot help when other plugins use determine_locale() to generate text/logs. Especially if those other plugins don't operate with user_logged_in so they default to WPLANG

A recent example I had is Easy Updates Manager plugin that logs automatic updates (so no user_locale). Some of the updated plugins have translation strings and some don't - resulting in a mixed LTR/RTL report. There is no obvious way to tell EUM plugin NOT to use site locale when generating the report.

[audrasjb]

#58105 was marked as a duplicate.

[audrasjb]

This proposal was also discussed in #58105, which was marked as duplicate.

I second this proposal: being able to set up different languages on the back-end and front-end is a needed feature.

While I'm all for the "decision not option" principle, I think this is a very important feature for many websites, and declaring a good language/locale on front-end is mandatory for accessibility purpose.

Adding accessibility focus. See #58105 for full context.

[audrasjb]

In my opinion, we need a new "Site language" setting, separated from "Admin default language".

[Marc4]

I see some favorable opinions about separating the back-end and front-end strings with the ultimate goal of being able to have different languages in back-end and front-end, both from core and accessibility, but it seems that we are stuck in a merged ticket from three years ago.

What would have to be done, or what teams would have to communicate in order to do this? Do we agree to make this effort?

Replying to audrasjb:

In my opinion, we need a new "Site language" setting, separated from "Admin default language".

[swissspidy]

So, I see how sending admin notification emails in the site language might be confusing if the recipient (which could be an agency for example) does not speak the language. I see the value in changing the preferred locale for those. However, for everything else it seems like this would just confuse users.

Let's say my site language is es_ES and my user language is de_DE. Now I change the admin language to fr_FR. Where would I even see that?

[Marc4]

@apedog commented on the notification emails issue, but I am not help with this.

My ticket https://core.trac.wordpress.org/ticket/58105 has the same purpose, to have different languages in back-end and front-end, and that's why it was merged here. Maybe I should have written there?

In my ticket attached an image where the language selector could appear, for back-end and front-end, I don't know if you are referring to that.

Replying to swissspidy:

So, I see how sending admin notification emails in the site language might be confusing if the recipient (which could be an agency for example) does not speak the language. I see the value in changing the preferred locale for those. However, for everything else it seems like this would just confuse users.

Let's say my site language is es_ES and my user language is de_DE. Now I change the admin language to fr_FR. Where would I even see that?

[swissspidy]

Yes I see where you added the language selector, thanks.

My question is just: when you select the language, what happens? What is now displayed in this new language?

Right now the user language is used for the admin, the site language for the frontend.

Is the suggestion that this new field would be used for the admin _as long as the user has not changed their language_?

That sounds a bit confusing to me, as per my example above: Let's say my site language is es_ES and my user language is de_DE. Now I change the admin language to fr_FR. What is now displayed in fr_FR?

[Marc4]

I can't understand what sense it would make for a user to have three languages active at the same time as you indicate in your example. So I can't imagine what would happen in that situation. If you are referring to two or more different users, I deal with it below.

If you mean that it makes no sense to have "Site", "Dashboard" and "User" languages, I agree with you, there should only be "Site" and "Dashboard", but now we get into the user roles and the languages associated with them.

Currently, a user who does not have an administrator role, can only select in the configuration section of his user, the languages that the administrator has previously registered on the website. The language selected by this non-admin user will be his personal "Dashboard Language", but he cannot change the front-end language. The "Site Language" option is being hidden from this user, because he does not have access to "Settings".

In order not to have three language options, in the case of an administrator user, he would simply not have the option to change the language of his user, since this language will be selected in "Settings > General". This is where the ticket image proposal would come in https://core.trac.wordpress.org/ticket/58105

Replying to swissspidy:

Yes I see where you added the language selector, thanks.

My question is just: when you select the language, what happens? What is now displayed in this new language?

Right now the user language is used for the admin, the site language for the frontend.

Is the suggestion that this new field would be used for the admin _as long as the user has not changed their language_?

That sounds a bit confusing to me, as per my example above: Let's say my site language is es_ES and my user language is de_DE. Now I change the admin language to fr_FR. What is now displayed in fr_FR?

[apedog]

Replying to Marc4:

I can't understand what sense it would make for a user to have three languages active at the same time.

I'd like to point out that this ticket is mostly relevant to RTL sites.
Having a dashboard language that is not the site language is meant to avoid mixed RTL/LTR reports (update mails sent out etc.)
Reports are not sent using a user's language. They are generated using the site's language. So they are commonly mixed RTL/LTR - which is simply unreadable.
Obviously, a user's settings should override the dashboard language settings for that user.

Example 1:
Hebrew front language. All visitors see a Hebrew RTL site.
English dashboard language. Default dashboard and report language is LTR (perhaps toolbar on front also).
Russian user language. Dashboard for specific user is Russian - overriding dashboard language for that user (and also admin-bar on front when logged in)

Example 2:
Hebrew front language. All visitors see a Hebrew RTL site.
English dashboard language. Default dashboard and report language is LTR.
Hebrew user language. Dashboard for specific user is Hebrew (same as front language). Default non-user specific reports/mail are still LTR and readable.

I don't think user roles should have separate language settings.
Front language.
Dashboard language.
User personal language.

in the case of an administrator user, he would simply not have the option to change the language of his user.

User should always have the option to tailor their personal experience using the site.

[knutsp]

Why not call this default admin language? As any user can have their own (admin) language, the only users affected by changing this new language setting for admin, are those with the their language set to admin default, and for new users. Or have I missed something?

What does this really have to do with RTL/LTR? That is an attribute of the language, right?

There will only be ONE language set for a (logged in) user, but the front will show in site language. The administrator will select a site (front end) language and a default admin language. Som reports (emails) goes to user, some to admin email. So either user language, or the new default admin language.

[Marc4]

@knutsp Are different things. I created a proposal #58105 which was merged with #49971.

I recently separated my proposal from @apedog to avoid this confusion.

The problem is that you are now mixing two tickets that have different causalities, and only perhaps, a common solution.

If anyone wants to follow @apedog's ticket they can keep the conversation going here. If anyone wants to contribute to the proposal to separate languages, they can do so here #58326.

:)

[swissspidy]

It seems to me that both tickets are about the same issue, let‘s close the other one as a duplicate.

The user language setting is not going away, nor is the regular site language setting.

A setting for the default admin language is useful for admin notifications and as a default if the user hasn‘t set one, so that sounds reasonable.

It requires some UX wording in the settings page to explain what it does.

The default admin language coukd only be changed by users with admin capabilities.

Also worth noting that new languages can only be installed by users with the same capabilities. Others can only choose an already installed langusge.

Hope that makes sense.

[swissspidy]

#58326 was marked as a duplicate.

[apedog]

What does this really have to do with RTL/LTR? That is an attribute of the language, right?

Mixed RTL/LTR texts are just a more acute instance of the mixed language issue. The formatting of tables/mails with mixed strings is just wonky.

Toolbar

If this ticket goes forward, attention should be given to toolbar language (and text-direction) when appearing on the front-end.
Logically toolbar should default to admin language (superseded by user language).
This would require special care - formatting-wise. ie. Entire toolbar should format LTR while not affecting RTL front-facing page.

[swissspidy]

Toolbar language is its own ticket with its own blockers, please follow #38643 for that

Right now this is just a proof of concept for a separate admin locale that's used for two things:

1. Fallback locale if the user has not selected one on their profile
2. Send notifications to the administration email address

Trac ticket: https://core.trac.wordpress.org/ticket/49971

[joedolson]

I'm going to remove the accessibility focus for now, because there isn't really anything for accessibility to do on this ticket for now. It can certainly have accessibility relevance in the future, so please add the focus back in if there are new interfaces showing up at some point. Right now, however, this is basically duplicating the site language settings from a UX perspective, and I don't think there's anything for us to do here.