Make WordPress Core

Opened 5 years ago

Closed 12 days ago

Last modified 11 days ago

#49971 closed feature request (wontfix)

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

Reported by: apedog's profile apedog Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: I18N Keywords: has-patch
Focuses: ui, rtl, administration Cc:

Description

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.

Attachments (1)

ux-text-site-language.png (14.8 KB) - added by Marc4 19 months ago.

Download all attachments as: .zip

Change History (29)

#1 @swissspidy
5 years ago

  • Component changed from General to I18N

#2 @johnbillion
5 years ago

  • Focuses accessibility removed
  • Type changed from enhancement to feature request

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.

#3 @apedog
5 years ago

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.

#4 @audrasjb
20 months ago

#58105 was marked as a duplicate.

#5 @audrasjb
20 months ago

  • Focuses accessibility added

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.

Last edited 20 months ago by audrasjb (previous) (diff)

#6 follow-up: @audrasjb
20 months ago

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

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


20 months ago

#8 in reply to: ↑ 6 @Marc4
19 months ago

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".

#9 follow-up: @swissspidy
19 months ago

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?

#10 in reply to: ↑ 9 @Marc4
19 months ago

@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 exist 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?

Version 1, edited 19 months ago by Marc4 (previous) (next) (diff)

#11 follow-up: @swissspidy
19 months ago

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?

#12 in reply to: ↑ 11 ; follow-up: @Marc4
19 months ago

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?

Last edited 19 months ago by Marc4 (previous) (diff)

#13 in reply to: ↑ 12 @apedog
19 months ago

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.

#14 @knutsp
19 months ago

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.

#15 @Marc4
19 months ago

@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.

:)

#16 @swissspidy
19 months ago

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.

#17 @swissspidy
19 months ago

#58326 was marked as a duplicate.

#18 @apedog
19 months ago

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.

#19 @swissspidy
19 months ago

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

Last edited 19 months ago by swissspidy (previous) (diff)

This ticket was mentioned in PR #4515 on WordPress/wordpress-develop by @swissspidy.


19 months ago
#20

  • Keywords has-patch added

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

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


17 months ago

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


17 months ago

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


14 months ago

#24 @joedolson
14 months ago

  • Focuses accessibility removed

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.

#25 follow-up: @swissspidy
8 weeks ago

Related new change in #61518 / [59128], added in WordPress 6.7:

Every time an email is sent to the administrator email address (admin_email), WordPress checks if a user with the same email address exists. If so, the email is sent in that user's locale.

#26 @swissspidy
12 days ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

It feels like the change in 6.7 mentioned above addresses the situation originally reported here. Adding a separate admin locale option would just increase complexity and confusion, so closing this as a wontfix for now.

#27 in reply to: ↑ 25 @apedog
11 days ago

Replying to swissspidy:

Related new change in #61518 / [59128], added in WordPress 6.7:

Every time an email is sent to the administrator email address (admin_email), WordPress checks if a user with the same email address exists. If so, the email is sent in that user's locale.

How does core handle multiple emails?
ie. when (admin_email) is a comma-separated list of emails.

Re: wontfix
Can I hook onto the administration email and filter the user whose locale settings are used? Or even set the locale programmatically - independent of any user?
ie. Achieving the same results with a plugin - control over the language/locale used in emails.

#28 @swissspidy
11 days ago

ie. when (admin_email) is a comma-separated list of emails.

That's not really supported in general...

Can I hook onto the administration email and filter the user whose locale settings are used? Or even set the locale programmatically - independent of any user?

Sure, yeah that should be possible. It might be tricky to find the right filter for each email, but in theory building that in a plugin should be possible. If needed, you could open a new ticket to suggest adding new filters or hooks or so.

Note: See TracTickets for help on using tickets.