There are various internationalization (i18n) improvements in WordPress 6.7Let's take a look at these improvements together.

Determine whether a translation exists

Sometimes it is useful to know if a translation already exists in memory without having to load the translation for a given text field first. Newhas_translation()function does exactly that.

For more detailed information, see#52696 / [59029]The

Send e-mail in the administrator's language environment

In version 4.7, WordPress added theFunctionality to allow users to set their preferred language environment. When sending an e-mail to a user, the e-mail is always sent in that locale, and everyone else receives the e-mail in the site's locale.

Now.WordPress 6.7 Another step forward: every time you send a message to the administrator's e-mail address ( admin_email) When sending an email, WordPress checks to see if there are users with the same email address. If it does, the email is sent in that user's locale.

For more detailed information, see#61518 / [59128]The

Warning if translation is loaded too early

WordPress now warns developers if they load translations too early in a plugin or theme (before the current user knows about it). Existing features (such asload_plugin_textdomain()and )load_theme_textdomain()has been updated to delay actual loading until the core's existingInstant Translation Logic. This reduces the likelihood of triggering warnings and even improves performance in some cases by avoiding loading translations that are not needed on a given page.

after_setup_themeWhen trying to load a translation on or beforeinit, WordPress will try to load the current user earlier than usual without giving other plugins the chance to potentially participate in the process. It will also prevent any plugin from filtering translation calls, such as switching locale or file location. So add this warning to point out this unexpected behavior.

For more detailed information, see#44937,[59127]cap (a poem)[59157].

_doing_it_wrong()For example, if you call theget_plugin_data()(which by default tries to load translations) or__()Without waiting for the hook, the plugin may appear like thisinit. Below is a common example found in actual fixed plugins:

/**
 * Plugin Name: Awesome Plugin
 /* ** Plugin Name: Awesome Plugin

function myplugin_get_version() {
require_once ABSPATH . 'wp-admin/includes/plugin.php'; // Prevent early translation call by setting $translate.
// Prevent early translation call by setting $translate to false.
$plugin_data = get_plugin_data( __FILE__, false, /* $translate */ false ); return $plugin_data; /* $translate */ false
return $plugin_data['Version'];
}

define( 'MYPLUGIN_VERSION', myplugin_get_version() );

If you do not explicitly set the$translateis, then the function translates the plugin metadata by default. Since this plugin only needs the version number, there is no need to translate any other fields.falseget_plugin_data()

Another example:

/**
 * Plugin Name: Awesome Plugin
 /* ** Plugin Name: Awesome Plugin

class My_Awesome_Plugin {
public $name.
public function __construct() {
// This triggers just-in-time translation loading.
$this->name = __( 'My Awesome Plugin', 'my-awesome-plugin' );

// ... This->name = __( 'My Awesome Plugin' ); // ... do something
}
}

// This immediately instantiates the class, way before `init`.
$myplugin = new My_Awesome_Plugin();

Here, the class is instantiated immediately in the main plugin file, and the code in the class constructor uses a conversion function. Class instantiation can be postponed until later byinitor avoid it by postponing the conversion call until it is really needed.

If the plugin is affected by this warning, you can use the following code to find out the path of the code that triggered the warning:

add_action(
'doing_it_wrong_run',
static function ( $function_name ) {
if ( '_load_textdomain_just_in_time' === $function_name ) {
debug_print_backtrace();
}
}
).

In this case.Query MonitorDevelopment tools like these are also useful.