I18N Improvements in 6.2

Various internationalization (i18n) improvements are in WordPress 6.2, and this developers note will focus on these.

Make it easier to switch to a user’s localeLocale A locale is a combination of language and regional dialect. Usually locales correspond to countries, as is the case with Portuguese (Portugal) and Portuguese (Brazil). Other examples of locales include Canadian English and U.S. English.

A while back, WordPress 4.7 introduced user admin languages and locale switching. With every user being able to set their preferred locale, it’s crucial to use locale switching to ensure things like emails are sent in that locale. That’s why you would see a lot of code like switch_to_locale( get_user_locale( $user ) ) in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and in plugins.

Not only is this very repetitive, it also causes limitations when used in combination with things like the Preferred Languages feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins., where one would like to fall back to another locale if the desired one is not available.

To improve this, WordPress 6.2 provides a new switch_to_user_locale() function that takes a user ID, grabs the user’s locale and stores the ID in the stack, so that at each moment in time you know whose locale is supposed to be used.

Together with this enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature., the WP_Locale_Switcher class has been updated to filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. both locale and determine_locale with the switched locale. This way, anyone using the determine_locale() function will get the correct locale information when switching is in effect.

Core already makes use of this new function, and plugins and themes are of course encouraged to do so as well.

See #57123 for more information.

wp_get_word_count_type()

In #56698, the locale’s word count type (i.e. whether they count words or characters), has been made part of the WP_Locale class.

Previously, to get that information, plugins and themes had to do something similar as core and use code like _x( 'words', 'Word count type. Do not translate!' ). All such translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. strings in core have already been replaced with the new wp_get_word_count_type() function (which is a wrapper around WP_Locale::get_word_count_type()). So if you have been using those translation strings in your code, you can now switch to this new function too!

Install new translations when editing your profile

Ever since the aforementioned user admin language feature was introduced, users have been able to change their preferred language in the user profile by choosing from the list of already installed languages. New languages could only be installed via the General Settings page.

Starting with WordPress 6.2, you don’t have to go to the settings page anymore if you quickly want to change your user language to a new one—if you have the necessary capabilities to install languages of course, which by default only admins have.

See #38664 for full context.

Translator comments for screen reader strings

In r55276 / #29748, all translatable strings intended for screen readers have been marked as such via translator comments.

This aims to provide better context for translators and make it easier to determine that some strings contain hidden accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) text and are not displayed in the UIUI User interface.

Props @ocean90 and @webcommsat for reviewing this post.

#6-2, #dev-notes, #dev-notes-6-2, #i18n