Ability to change a user language back to site's language is missing

[ocean90]

Previously: #29783 and ​related discussion on Slack

In the admin (and via REST API #38528) it's currently not possible to set a user language back to site's language. get_user_locale() falls back to get_locale() only if the meta field is a falsy value.

wp_dropdown_languages() uses an empty string value for en_US which gets replaced with en_US in https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/user.php?rev=38705&marks=99-106#L99.

I'm not sure if there really needs to be a way for this so I'm moving this to 4.7 for a decision.

[ocean90]

38632.2.diff​:

• Removes the lang attribute since it's in the same language as the current page
• Uses site-default as the value for the site language
• Adds context to "Site Defaut"
• Ensures that English (United States) can be selected

[ocean90]

To do: REST API, see r39090 and r39096

[ocean90]

38632.3.diff​ adds the empty string to the locales enum. @joehoyle How does this look to you?

[joehoyle]

@ocean90 I think that would work, If you updated to '', I presume the locale would show as en_US in the response?

[ocean90]

@joehoyle No, it'd be the value of get_locale(), see 38632.4.diff​ and get_user_locale().

[joehoyle]

@ocean90 Hmm ok, my only concern with this is it's not easy to localize things for API clients when the majority of users are going to have the site's locale (that's by default anyway), which renders this field fairly useless in the case of the REST API. It seems like most of the time one would need to get the site's locale "global" setting rather than relying on this fields, as this field is going to be '' most of the time.

I'm tempted to suggest that the API's value for a user's locale should fall through to the site's default, so it's more usable for api consumers. Like settings, you could then send locale => null to the REST API reset it to it's default (site setting), under the hood this would just set it to an empty string of course.

[joehoyle]

After chatting to @ocean90 in slack - I think we are good here as far as the api is concerned, I had misunderstood the "default value" behaviour, as it is, actually set to the site's locale, in which case API consumers can just rely on this field always when showing user-specific locales.

[ocean90]

Can't I get a final review, @swissspidy? Thanks!

[swissspidy]

In 38632.5.diff​:

• Fix the order of sprintf() arguments
• Add docs
• Add unit tests for wp_dropdown_languages()

[swissspidy]

In 39169:

I18N: Add ability to change user's locale back to site's locale.

Previously there was no way to remove the user locale setting again, even though that might be desirable.

This adds a new 'Site Default' option to the user-specific language setting by introducing a new show_site_locale_default argument to wp_dropdown_languages().

Props ocean90.
See #29783.
Fixes #38632.

[ocean90]

In 39269:

Users: In edit_user() fall back to site's locale instead of en_US for invalid user locales.

See #38632, #29783.
Fixes #38798.

[ocean90]

In 39331:

I18N: In wp_dropdown_languages() rename the new show_site_locale_default argument to show_option_site_default.

This makes it consistent with arguments of other wp_dropdown_*() functions.

Props SergeyBiryukov.
See #38632.
Fixes #38871.