Make WordPress Core

Opened 2 years ago

Last modified 2 years ago

#49971 new feature request

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

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


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.

Change History (3)

#1 @swissspidy
2 years ago

  • Component changed from General to I18N

#2 @johnbillion
2 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, and come to mind.

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

#3 @apedog
2 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.

Note: See TracTickets for help on using tickets.