Miscellaneous developer changes in WordPress 6.6


Table of contents


Autosave

Allowed disabling autosave support for individual post types

[58201] added a way to allow disabling autosave support for individual post types. Not all post types support autosaving. By making autosave a post type feature, support can be more granularly handled without any workarounds or hardcoded allowlists. For backward compatibility reasons, adding editor support implies autosave support, so one would need to explicitly use remove_post_type_support() to remove it.

See #41172 for more details.

Bundled Theme

Twenty Sixteen: Fixed mismatch of visual and DOM order of elements

Starting in Twenty Sixteen’s version 3.3 (released with WordPress 6.6), the site information links remain below the social navigation at any screen size. Before that, the social navigation had displayed after the site information on larger screens, which created a mismatch between the visual order and the Document Object Model (DOM) order.

Site, Privacy Policy, and Proudly powered by WordPress links appear beneath three social icon links in the site footer
The two footer elements are stacked, now at screen widths larger than 910 pixels.

If you would like to have the two elements side-by-side, with the social navigation first, you could paste styles in a child themeChild theme A Child Theme is a customized theme based upon a Parent Theme. It’s considered best practice to create a child theme if you want to modify the CSS of your theme. https://developer.wordpress.org/themes/advanced-topics/child-themes/. or in the Customizer’s Additional CSS panel.

Check the instructions on how to do this
@media screen and (min-width: 56.875em) {
	/*
	  1. Reset the social navigation width.
	  2. Adjust margins to place site info along the right edge.
	*/
	.site-footer .social-navigation {
		width: auto;
		margin: 0.538461538em auto 0.538461538em 0;
	}
	.site-info {
		margin: 0;
	}


	/* Reverse the margins for right-to-left languages. */
	.rtl .site-footer .social-navigation {
		margin: 0;
	}
	.rtl .site-info {
		margin: 0.538461538em auto 0.538461538em 0;
	}
}
Three social icon links appear on the left side of the site footer, but Site, Privacy Policy, and Proudly powered by WordPress links are on the right.
Custom CSSCSS Cascading Style Sheets. could place the site information links on the right side.

See #60496 for more details.

Comments

Default length of time for comment author cookies has changed

[58401] changed the default length of time for comment author cookies from 0.95129375951 of a year to 1 year by taking advantage of the YEAR_IN_SECONDS constant. The comment_cookie_lifetime 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. can still be used to change this value.

See #61421 for more details.

Editor

Site Editor Patterns on Classic Themes

#61109 now directs a classic theme’s Appearance > Patterns menu to the site editor Patterns view (/wp-admin/site-editor.php?path=/patterns), providing a consistent pattern and template management experience regardless of theme type. For themes with block-template-parts support, the Appearance > Template Parts menu has been removed, with template parts now accessible under the site editor’s Patterns > Template Parts view.

Fluid Typography

Some theme.json presets require custom logic to generate their values, for example, when converting font size preset values to clamp() values.

The custom logic is handled by callback functions defined against the value_func key in WP_Theme_JSON::PRESETS_METADATA. The callback functions are invoked in WP_Theme_JSON::get_settings_values_by_slug().

In WordPress 6.6, settings of the current WP_Theme_JSON instance, are now passed to these callback functions. The permits callback functions to return values that rely on other settings in the theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. tree.

In the case of font sizes presets, it fixes a bug whereby the callback function — wp_get_typography_font_size_value() — was not taking into account settings values passed directly to the WP_Theme_JSON class.

External libraries

jQuery UIUI User interface library update

The jQuery UI library was updated to version 1.13.3. For more information on the changes included, see jQuery UI 1.13.3 release notes.

Login and Registration

New array arguments for wp_login_form

The wp_login_form() function has two new array arguments: required_username and required_password. Passing true to these arguments adds the ‘required’ attribute to the input fields.

$args = array(
    'required_username' => true,
    'required_password' => true,
);
wp_login_form( $args );

There is no change to the default field output.

See #60062 for more details.

Multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site

Custom ports for multisite site addresses

#21077 made it possible to install and operate a Multisite installation on a host name that includes a port number, and the corresponding #52088 added full support for this to the local development environment. This means it’s now possible to run Multisite on an address such as localhost:8889.

Update enabled mime types for new multisite installs

In #53167, the list of mime types that are enabled for upload were aligned to those enabled by regular sites by switching from a hard-coded list of types (that had become outdated) to using coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.’s get_allowed_mime_types function. This ensures that new multisite installs are up to date with the current mime types supported in core, including the recently enabled image/webp and image/avif types.

Note that, since this is only used to populate the schema for new networks, it will only affect newly created multisite networks – it does not change the allowed mime types for existing networks. To adjust the mime types allowed for existing sites, developers can continue to use an approach as follows for filtering the upload_filetypes option:

Script Loader

Obsolete polyfills dependencies have been removed

In [57981], now obsolete polyfills such as wp-polyfill, wp-polyfill-inert and regenerator-runtime were removed from the react script dependency in WordPress, as they are no longer needed in modern browsers supported by WordPress. Developers relying on wp-polyfill need to manually add it as a dependency to their scripts.

See #60962 for more details.

Script modules can now be used in the WordPress adminadmin (and super admin)

With #61086, script modules can now be used in the WordPress admin. Before WordPress 6.6, script modules were only available on the front end.

Toolbar

Search has a much later priority

In [58215], the search input on the front-end admin bar is added at a different priority. It was previously inserted at priority 4 and then floated to appear at the end of the admin bar. It is now inserted at priority 9999 to load at the end of the admin bar without CSS manipulation.

Extenders placing admin bar nodes after the search or replacing core search should take the new priority into consideration.

Example: Assign different priority based on WordPress version

$priority = ( version_compare( $GLOBALS['wp_version'], '6.6-alpha', '>=' ) ) ? 4 : 9999;
add_action( 'admin_bar_menu', 'wpadmin_toolbar_test_link', $priority );
/**
 * Add a node to the WP admin toolbar.
 *
 * @param object $wp_admin_bar WP Admin Bar object.
 */
function wpadmin_toolbar_test_link( $wp_admin_bar ) {
	$wp_admin_bar->add_node(
		array(
			'parent' => 'top-secondary',
			'id'     => 'mylink',
			'href'   => '#',
			'title'  => __( 'My Link' ),
		)
	);
}

See #60685 for more details.


Props to @swissspidy, @jorbin, @johnbillion, @audrasjb, @joedolson, @ironprogrammer, @ramonopoly, @jonsurrell, @sabernhardt, @jdy68, @afercia and @juanmaguitar for their contribution and/or reviews.

#6-6, #dev-notes, #dev-notes-6-6

Internationalization improvements in 6.6

Various internationalization (i18n) improvements are in WordPress 6.6, and this developers note focuses on these.

Enhanced support for only using PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. files

WordPress 6.5 shipped with a completely new localization system with improved performance, which uses .l10n.php files in addition to .po and .mo files. This system was slightly enhanced in 6.6 to better support scenarios where only these PHP translation files exist, but not the others. This specifically applies to wp_get_installed_translations(), which is used to check which translations are installed, and the Language_Pack_Upgrader for updating translations.

See #60554 for more details.

New lang_dir_for_domain 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.

A new lang_dir_for_domain filter has been added to WP_Textdomain_Registry, allowing plugins to override the determined languages folder when using just-in-time translation loading. This is mostly useful for multilingual plugins.

See #61206 for more details.

Additional context for the load_translation_file filter

The load_translation_file filter was introduced in WordPress 6.5 to support changing the file path when loading translation files, regardless if it’s a PHP or an MO translation file. In 6.6, the 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. is passed as an additional argument to this filter, bringing it more in line with similar i18ni18n Internationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill. filters.

See #61108 for more details.

Props to @audrasjb and @juanmaguitar for review.

#6-6, #dev-note, #dev-notes, #dev-notes-6-6, #i18n

Merge Proposal: Preferred Languages

Almost 8 years ago the Preferred Languages feature project was kicked off in response to a feature requestfeature request A feature request should generally begin the process in the ideas forum, on a mailing list, as a plugin, or brought to the attention of the core team, such as through scope meetings held for each major release. Unsolicited tickets of this variety are typically, therefore, discouraged. in #28197. Right now it is probably the oldest active feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins.. Over time there were numerous updates, bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes, and even a complete refactor. Preferred Languages was always built and maintained with the goal in mind to merge it into coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. one day. Now the time is finally right to do so.

Purpose & Goals

As a quick reminder, Preferred Languages replaces the existing languages dropdown with a supercharged version that lets you select multiple preferred languages. WordPress then tries to load the translations for the first language that’s available, falling back to the next language in your list otherwise. Without this, WordPress would just fall back to English (US) in such cases, which is not a great experience. Such a UIUI User interface is a pretty standard feature that can be seen for example also in operating system and browser settings.

Preferred Languages UI, showing the list of selected languages on the settings page.
Example of the Preferred Languages UI on the settings page

Note: Preferred Languages works for both the site language (can be set at Settings -> General) and the user language (can be set in the profile).

Project Background

You may wonder why it took such a long time. Since the project’s inception, a lot has changed in WordPress. For example, GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ happened. That’s why Preferred Languages saw a complete rewrite using the same ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. components that also power the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor. With Gutenberg we also saw the introduction of JavaScript localization, which required further iterations to Preferred Languages. Then there was a need for merging incomplete translations, reducing the chances that you see missing strings in English. However, merging translations was very bad for performance, as it involves loading lots of translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. files. In WordPress 6.5 we finally completely replaced the localization library with a more performant solution that natively supports loading multiple files at once. So this last remaining blockerblocker A bug which is so severe that it blocks a release. is now finally resolved!

Internationalization and localization is a core part of WordPress and relevant for more than half of all users. That’s why this functionality belongs natively into WordPress core and not in a (canonical) plugin. Merging Preferred Languages into core would allow the fallback logic to run much closer to where translation loading happens, reducing the risk for bugs and pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party incompatibilities. Plus, the UI impact is minimal, as it simply expands an existing language dropdown with additional features.

Implementation Details

The UI is built using TypeScript and React and the @wordpress/* npm packages also used for Gutenberg. This makes for a consistent look & feel and will make it easy to integrate it into any revamped WordPress adminadmin (and super admin) UI. The back end parts were developed in such a way that merging them into core eventually is as straightforward as possible, so a patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. can be developed relatively quickly.

Preferred Languages has been tested in production websites over numerous years by thousands of users. It works in all major browsers supported by WordPress, follows 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) best practices, and gracefully falls back to the old single language dropdown if JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. is disabled.

Contributors and Feedback

While I (@swissspidy) have been the lead developer of the plugin, valuable input and contributions have come from others in the community.

This is a proposal and is subject to revision based on your feedback. If you haven’t already tried out the plugin, please download and install it from WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ or the comfort of your WordPress admin. You can review the current code and leave feedback at the project’s GitHub repository or in #core-i18n on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

All feedback will be collected over the next couple of weeks. After that, the received feedback will be discussed and next steps determined. The goal is to work on and land a patch quickly to ensure that the feature gets plenty of testing in WordPress trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision..

Props to @ocean90 for reviewing this post.

#6-6, #feature-plugins, #feature-projects, #i18n, #merge-proposals, #polyglots, #preferred-languages

I18N Improvements in 6.5 (Performant Translations)

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

New localization system with improved performance

Over the past year, WordPress contributors have meticulously analyzed performance of the existing i18ni18n Internationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill. system in WordPress and ultimately created a new Performant Translations feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. that provided a completely overhauled system with significantly better performance. After thousands of betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. testers and a merge announcement late last year, this new library is now included in WordPress 6.5! See #59656 for all the details.

The Performant Translations pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party is still useful and will continue to be maintained to build on top of the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. solution with a distinct additional feature. As is already the case today, the plugin will automatically convert any .mo files to PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher files if a PHP file does not currently exist. This is useful for sites where translations are not coming from translate.wordpress.org or only exist locally on that server.

This new library is faster at loading binary .mo files and uses less memory. It even supports loading multiple locales at the same time, which makes locale switching faster. In addition to that, it supports translations contained in PHP files, avoiding a binary file format and leveraging OPCache if available.

The new library is so fast, in fact, that it paves the way for the Preferred Languages feature plugin to merge translations of multiple locales by default starting with WordPress 6.5.

While this is in large part a silent and backward-compatible under-the-hood change, there are still a few things to be aware of:

New .l10n.php translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. file format

When downloading language packs from WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/, there will be a new .l10n.php file in addition to the .mo and .po files you are already familiar with. If an .mo translation file has a corresponding .l10n.php file, the latter will be loaded instead, making things even faster and use even less memory.

This is a progressive enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature., so if there’s only an .mo file but no PHP file, translations will still be loaded as expected. However, the opposite is also true! So you can theoretically use only .l10n.php translation files in your project and features such as the just-in-time translation loading continue to work. Right now, WordPress still expects corresponding .po and .mo files for things like update checks. However, this limitation will be addressed in the future, see #60554 for more information.

Note: if you don’t see any .l10n.php translation files in wp-content/languages yet, it might be that the language pack hasn’t been updated in a while, i.e. there were no new translations.

Here’s an example of a PHP translation file as supported by WordPress 6.5:

<?php
return [
'project-id-version' => 'WordPress - 6.5.x - Development',
'report-msgid-bugs-to' => 'polyglots@example.com',
'messages' =>
[
'original' => 'translation',
'contextEOToriginal with context' => 'translation with context',
'plural0' => 'translation0' . "\0" . 'translation1',
'contextEOTplural0 with context' => 'translation0 with context' . "\0" . 'translation1 with context',
'Product' => 'Produkt' . "\0" . 'Produkte',
],
];

Note: EOT here stands for the “End of Transmission” character (U+0004, or "\4" in PHP). It’s the same delimiter as in gettext used to glue the context with the singular string.

Generating PHP translation files

If you would like to generate these PHP translation files yourself, version 4.0 of GlotPress, the plugin that powers translate.WordPress.org, already supports the new .l10n.php format.

In addition to that, WP-CLI 2.10.0 (i18n-command 2.6.0) provides a new wp i18n make-php command to create these PHP files from a given .po file. Examples:

# Create PHP files for all PO files in the current directory.
$ wp i18n make-php .

# Create a PHP file from a single PO file in a specific directory.
$ wp i18n make-php example-plugin-de_DE.po languages

If you are developing a WordPress plugin that deals with translations, you can also use the new WP_Translation_File class to convert an .mo file into a PHP file. Example:

$contents = WP_Translation_File::transform( $mofile, 'php' );
if ( $contents ) {
file_put_contents( $path_to_php_file, $contents );
}

New filters to customize this behavior

If you would like to disable the support for PHP files for some reason; for example, if you don’t have any yet in your project and want to prevent the extra file lookup operation, you can use the new translation_file_format 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. to change the preferred format (default is php) like so:

add_filter(
'translation_file_format',
static function () {
return 'mo';
}
);

The existing load_textdomain_mofile filter can still be used to filter the .mo file path for loading translations for a specific text domain. However, it only works for .mo files. To filter the path for a translation file, be it a .l10n.php or a .mo file, use the new load_translation_file filter.

Working with the $l10n global variable

Previously, when loading translations, WordPress would store an instance of the MO class in the $l10n global variable. With WordPress 6.5, this will be an instance of a new WP_Translations class that acts as a shim with similar characteristics. If your project directly works with this global variable or the MO class in some way, this is an area to keep an eye on.

Cached list of language file paths

This another slight performance improvement but unrelated to the new localization library covered above.

In places such as get_available_languages() and WP_Textdomain_Registry, WordPress used to directly use the glob() function to retrieve all .mo files in a specific directory. This is important for just-in-time translation loading and generally knowing which translations are installed. However, on sites with a large number of language files, the glob() operation can become expensive.

Because of this, a new caching mechanism was introduced in #58919 / [57287]. The file lookup is now handled centrally in WP_Textdomain_Registry and stored in the object cache in the translations group, with the cache key having the format cached_mo_files_<hash>, where <hash> is the MD5 hash of the scanned directory, e.g. wp-content/languages. The cache is cleared whenever language packs are updated.

Also, the lookup now also scans for .l10n.php files in addition to .mo files, in case only the former exist on a site.

More questions? Please let us know

If you have any questions, please leave a comment below or file a new ticket on Trac under the I18N component if you’ve encountered any bugs.

Props to @joemcgill, @stevenlinx for review.

#6-5, #dev-notes, #dev-notes-6-5, #i18n

Merging Performant Translations into Core

The coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. performance team spent a lot of time this year looking into the performance of the i18ni18n Internationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill./l10nL10n Localization, or the act of translating code into one's own language. Also see internationalization. Often written with an uppercase L so it is not confused with the capital letter i or the numeral 1. WordPress has a capable and dynamic group of polyglots who take WordPress to more than 70 different locales. system in WordPress, after proving that loading translations had a significant hit on response time. This led to an in-depth performance analysis, followed by a dedicated Performant Translations feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. offering significant performance boosts for all WordPress sites with zero configuration. Thousands of sites successfully tested the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party under a wide variety of conditions. Now, the team believes the solution is ready for inclusion in WordPress core.

What it does

Performant Translations is powered by a new, lightweight i18n library that is faster at loading binary MO files and uses less memory. It even supports loading multiple locales at the same time, which makes locale switching faster. In addition to that, it supports translations contained in PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher files, avoiding a binary file format and leveraging OPCache if available. If an MO translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. file has a corresponding PHP file, the latter will be loaded instead, making things even faster and use even less memory. In raw numbers, this is how great the optimization is with this approach:

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.ScenarioMemory UsageLoad Time
en_USDefault15 MB159 ms
de_DEDefault29 MB217 ms
de_DEPerformant Translations17 MB166 ms

These numbers were taken by testing the Performant Translations plugin against WordPress 6.5-alpha-57028 with the Twenty Twenty-One theme and a few active plugins. As you can see, memory usage and load time overhead are reduced to a minimum.

Next steps

The core performance team has opened #59656 to track merging Performant Translations into core in time for the next 6.5 release. A pull request is already available and currently undergoing code review. Once that is completed, it will be ready to be merged into trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. where the library will be able to see even wider testing.

There is also a Meta patch ready for serving PHP files as part of language packs shipped by translate.wordpress.org, building upon a GlotPress PR. Both are in need of code review right now. While these two changes unlock the full power of Performant Translations, they are not blockers for the core merge and could even land later.

The Performant Translations plugin will continue to be maintained even after a core merge to build on top of the core solution with a distinct additional feature. As is already the case today, the plugin will automatically convert any MO files to PHP files if a PHP file does not currently exist. This is useful for sites where translations are not coming from translate.wordpress.org or only exist locally on that server.


Thank you to @mukesh27, @westonruter for reviewing and helping with this post.

#core, #i18n, #performance

WordPress core is now using Playwright for all browser-based tests

Early last year, a plan was outlined to phase out all Puppeteer usage across WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ step by step. Since then, a lot of progress has been made:

  • The @wordpress/e2e-test-utils-playwright package has become more mature and already provides many useful utilities that cover the needs for core and Gutenberg.
  • The @wordpress/scripts package, which is widely used in the ecosystem, now not only supports Puppeteer but also Playwright, making it straightforward for projects to migrate their existing setups.
  • The majority of e2e tests in Gutenberg have already been migrated from Puppeteer to Playwright, as can be seen in this tracking issue. This includes all performance tests.

Now, another major milestone has been reached: all browser-based tests in WordPress core now use Playwright! This includes end-to-end (e2e) tests, performance tests, and visual regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5. tests. See #59517 for full details.

How does this affect contributors?

As mentioned in the original proposal, Playwright makes it easier to write stable tests. Thanks to a built-in test runner with superior debugging tools, auto-waiting, and advanced selectors support, Playwright offers the tools necessary to write tests that are easy to understand and cause less headaches because of random timeouts or similar. It also supports many browsers out of the box, which will help strengthen the end-to-end test coverage in core.

Since Playwright is originally a forked version of Puppeteer, it offers a very similar APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways., so contributors writing and debugging tests should be familiar with the way things work.

If you want to get familiar with Playwright, check out Gutenberg’s migration guide as well as the official Playwright documentation. The migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. guide can be used to migrate Puppeteer-based tests from unmerged patches/PRs to the new setup.

End-to-end tests are still run using npm run test:e2e, with npm run test:e2e -- --ui running them in an interactive mode for easier debugging.

Playwright support was just added recently, so you might need to run npm install first to ensure the latest dependencies are installed.

Note: If you previously ran visual regression tests using npm run test:visual, the storage location for visual snapshots was changed from tests/visual-regression/specs/image_snapshots to tests/visual-regression/specs/snapshots. You can safely remove the files from the old folder if they show up in version controlversion control A version control system keeps track of the source code and revisions to the source code. WordPress uses Subversion (SVN) for version control, with Git mirrors for most repositories..


Props to @mamaduka for reviewing this post.

#e2e-tests, #gutenberg, #playwright, #puppeteer

Call for Testing: Performant Translations

The coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. performance team recently conducted an in-depth i18n performance analysis. It showed that localized WordPress sites load significantly slower than a site without translations. The blogblog (versus network, site) post presented and compared multiple solutions to this problem, and now the team would like to test the most promising approach at a wider scale using a dedicated pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party.

Introducing the Performant Translations plugin

What it does

The Performant Translations plugin uses a new approach to handle translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. files in WordPress, making localization blazing fast. The primary purpose of this plugin is to allow broader testing of these enhancements, for which the goal is to eventually land in WordPress core.

This plugin helps to make localized WordPress sites faster by replacing the traditional MO translation files with PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher files, which are much faster to parse. Plus, PHP files can be stored in the so-called OPcache, which provides an additional speed boost.

If your site is using a language other than English (US), you should see immediate speed improvements simply by activating this plugin. No further action is required.

The Performant Translations plugin is available for download on WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ or directly from your WordPress adminadmin (and super admin).

What to test and expect

Since the Performant Translations plugin requires no configuration, all that’s needed to benefit from its speed improvements is to activate the plugin.

To verify that something has changed, you could use a tool like Query Monitor or an external tool for testing server response times. In Query Monitor, the page load time and memory usage should drop quite a bit after plugin activation:

In Query Monitor you will also see how translations are loaded from PHP files from now on:

Query Monitor development tools, showing a list of text domains

While the plugin is mostly considered to be a betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. testing plugin, it has been tested and established to a degree where it should be okay to use in production. Still, as with every plugin, you are doing so at your own risk.

It’s also worth noting that the plugin has been successfully tested with common multilingual plugins, such as WPML, Weglot, TranslatePress, MultilingualPress, and Polylang. It also works fine with Loco Translate and 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..

Should you choose to stop testing the Performant Translation plugins, uninstalling it will remove all of its traces.

Provide your feedback

If you encounter any issues or simply have questions about the plugin, please leave a comment below or open a new support topic. In addition to that, contributions can be made on GitHub.

The performance team’s goal is to get as much feedback as possible and further refine the approach so that it can ultimately be proposed to be merged into WordPress core 6.5. That means testing will last for a few months at least.

+make.wordpress.org/test/

#call-for-testing, #core, #feature-plugins, #i18n, #needs-testing, #performance

I18N Performance Analysis

A recent in-depth performance analysis of WordPress core showed that loading translations had a significant hit on a site’s server response time. Given that more than half of all WordPress sites use a language other than English (US), the performance team identified this as an area worth looking into more closely. The team spent the last couple of months exploring this in more detail and the results are now shared in this blogblog (versus network, site) post.

This is merely an analysis of the current i18ni18n Internationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill. system in WordPress with some proposed under-the-hood performance improvements. No decisions have been made on any of these proposals.

Context

Initial benchmarks showed that the median loading time for a localized site can be up to 50% slower than for non-localized sites, depending on which themes and plugins are being used. This was measured using both the wpp-research CLI tool and also a dedicated benchmark environment (as elaborated in the Comparison section towards the end).

The WordPress i18n system is based on gettext, which uses source .po (Portable Object) files and binary .mo (Machine Object) files for storing and loading translations. It is not using the C gettext APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. itself but a custom userland implementation that works without any external dependencies.

In addition to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. itself, each pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and theme has its own translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. file, which has to be loaded and parsed on every request. Loading and parsing all these translation files is an expensive task.

In the past, various solutions have been discussed and explored to improve the i18n performance of WordPress. A non-exhaustive list:

  • Use a more lightweight MO parser
  • Improve translation lookups by using the hash map in MO files (e.g. with DynaMo)
  • Caching translations in the object cache
  • Caching translations in APCu (an in-memory key-value store for PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher)
  • Other more elaborated forms of caching (e.g. per request)
  • Using the native PHP gettext extension
  • Use a custom PHP extension to handle the MO file parsing)
  • Using lazily evaluated translation calls (see #41305 for details)
  • Using a different file format than .mo files, e.g. plain .php files

A more recent discussion touching on all of these solutions can be found over at the wordpress/performance repository. It’s a great way to get some context on this topic.

For this analysis, many of these solutions were looked at, focusing on their advantages and disadvantages. At the end of this post there is a comparison table with some much needed numbers as well, based on custom-built benchmarks.

Solutions

Solution A: Use different file format

Use a different file format for translations instead of .mo files to avoid the overhead of loading and parsing binary files.

Design considerations

With this solution, translations will be stored in plain .php files returning an associative array of translation strings. Whenever a .php file is available, it will be preferred over the .mo file, which is still used as a fallback. The rest of the architecture remains the same.

When a localized WordPress site downloads language packs from the translate.wordpress.org translation platform, it downloads .po and .mo files containing all the translations. This will be modified to include .php files. GlotPress, which the platform is built on, will be updated to support this new output format. Additionally, WordPress core itself could be modified to generate PHP files whenever they are missing.

In theory, nothing is faster in PHP than loading and executing another PHP file. .json, .ini, or .xml would all be much slower.

Proof of concepts using the PHP files can be found at swissspidy/wp-php-translation-files and swissspidy/ginger-mo.

Benefits

  • Initial benchmarks show consistent significant performance improvements
  • Relatively trivial to implement
  • Maintains backward compatibility thanks to graceful fallback
  • Makes it easier for users to inspect and change translations (no need to compile .po to .mo)
  • Avoids loading and parsing binary .mo files, which is the main bottleneck
  • Lets PHP store translations in OPcache for an additional performance benefit
  • Battle-tested approach in the PHP ecosystem (for example in Laravel)

Caveats and risks

  • Requires not only changes to WordPress core, but also tools like GlotPress and WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/
  • Adds maintenance overhead by introducing a new file format on top of the existing one
    • As shown by the proof of concept, the overhead is minimal
    • In the long term, .mo support could be deprecated
  • Security considerations due to essentially executing remotely fetched PHP files
    • Not really different from downloading plugins/themes from WordPress.org
    • WordPress considers translations to be trusted
    • Hosting providers could be blocking PHP execution in wp-content/languages
    • Could potentially use checksum verifications or static analysis at install time to detect anomalies

Effort and timeline

The proof of concept using PHP files is in a very solid state already. There are also examples for changes to WP-CLI (PR) and GlotPress (PR). This makes it suitable for a feature project to expand testing with very little effort required. Even a core merge would be very straightforward in a relatively short time, potentially already in Q4 2023. The security aspect when using PHP files could be a potential blockerblocker A bug which is so severe that it blocks a release., so it’s important to loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. in the WordPress security team and hosting providers early on.

More time is required to test other file formats and compare results.

Solution B: Native gettext extension

Use the native gettext PHP extension written in C when available, instead of the custom built-in parser in WordPress.

Design considerations

WordPress has always used a custom MO file parser, because the native gettext extension is not necessarily available on the server. With this solution, the existing system is adapted to use the extension whenever available and falling back to the custom implementation if not.

This has been previously explored in #17268 and implemented in WP Performance Pack and Native Gettext. These implementations can serve as inspiration for the initial design. They all work similarly in that they symlink or copy the translation files to a new directory structure that is compatible with the gettext extension.

As of July 2023, around 66% of all localized WordPress sites have the gettext extension installed, according to information from the WordPress update requests.

Benefits

  • Significant performance improvements for eligible sites
    • Initial benchmarks show that loading time and memory usage basically do not differ from non-localized sites

Caveats and risks

  • The gettext extension is not commonly available
    • Smaller incentive to implement and lower impact overall
  • Requires locales to be installed on the server
    • Servers rarely have many installed locales
      • Locales often need to be compiled first and take up a lot of space
      • WordPress on the other hand supports over 200 locales
    • Potential clashes with the custom locales WordPress supports
      • For example, locales like pt_PT_ao90, de_DE_formal or roh might not even be supported
    • Outreach to hosting providers would be necessary
  • Adds maintenance overhead by essentially adding a second gettext implementation
  • Poor API
    • Requires setting environment variables (such as LC_MESSAGES and LANGUAGE), which might not be possible or cause conflicts on certain servers/sites
  • Requires symlinks or hard file copies
    • Symlinks might not be possible on the server; copying all translation files means doubling disk usage
  • Translation files are cached by PHP, thus any translation change requires restarting the web server
    • There are workarounds such as cache busting using random file names or fstat, however they might not work on all environments
  • Has not been tested on a wider scale, despite being discussed for years

Check out the code of WP Performance Pack and Native Gettext to get a better idea of the extension’s poor API.

Effort and timeline

While there are existing implementations that could be leveraged for this solution, further field testing is required to assess whether the extension actually works under all circumstances. Given the limitations around the poor API and requirements for installing locales, it does not seem like a viable solution at all.

Solution C: Cache translations

Cache translations somehow to avoid expensive .mo parsing.

Design considerations

Cache translations either on disk, in the database, or the object cache to avoid expensive .mo file parsing on subsequent requests. This can be done in a generalized manner or also on a per-request basis to only load translations required for the current URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org.

Many different caching strategies have been explored in various forms in the past, each with their own pros and cons. Some could even be combined. Defining the exact implementation requires further exploration and testing, which warrants its own exploration post.

Benefits

  • Caching translations after one time .mo parsing potentially improves performance for future requests

Caveats and risks

  • Caching using persistent object cache (e.g. Memcached, Redis) or APCu:
    • Not available on most sites, making this not an ideal solution
      • Availability according to data from WordPress update requests:
        • Memcached: ~25%
        • Redis: ~25%
        • APCu: ~6%
    • Can potentially significantly increase cache size or exceed cache key limits
  • Database caching:
    • Moves the problem from disk reads to database reads
    • Can potentially significantly increase database size
    • Alternatively, use sqlite as a cache backend
      • Untested approach
      • Available on around 90% of sites
  • Disk caching:
    • Not always possible, depending on server environment
    • Still causes file reads, only with fewer or other files
  • Multiple cache groups (e.g. per-request or frontend/adminadmin (and super admin) split)
    • Smarter cache logic to only load translations that are needed for the majority of requests
    • Can potentially significantly increase cache size
    • Unlikely that different requests use very different translations
  • Cache retrieval adds overhead
    • Exact performance gains depend on implementation method and need to be measured first
    • No performance gains with cold cache
    • Cache invalidation logic TBD

Effort and timeline

Given the existing solutions in the ecosystem, the engineering effort itself would not be too big, but the right caching implementation (e.g. disk cache or object cache) needs to be evaluated first.

However, the right caching strategy probably does not exist because of all the different hosting environments. Since it’s unrealistic for core to support multiple types of caching, this solution seems better suited for plugins rather than core.

Solution D: Lazily evaluated translation calls

Use lazily evaluated translation calls to reduce the number of function calls in certain cases, leading to improved performance.

Design considerations

The idea of lazily evaluated translation calls has been first discussed in #41305. It enables avoiding string-specific expensive translation lookups until the translations are actually needed, by passing around proxy objects.

In other words: beyond just-in-time loading of translation files (which WordPress already does), this would add just-in-time lookup of individual strings in the translations. Check out this proof of concept to get a better picture.

It can be integrated essentially in two ways, both of which are explained on the core ticketticket Created for both bug reports and feature development on the bug tracker.:

  1. Change all translation calls to be lazily evaluated by default
  2. Make this opt-in, either with new function arguments or new functions altogether

Benefits

  • Reduces the number of translation lookups, in some scenarios drastically
    • On a regular home page request there are ~60% less translation calls, saving around ~10ms (as measured by XHProf)
  • As a side effect, solves UXUX User experience issues such as #38643

Caveats and risks

  • Depending on implementation this either breaks backward compatibility or risks not gaining enough adoption
    • Documentation, tooling, and developer education can help mitigate this to a certain extent
    • Adoption could be done gradually, e.g. starting with an opt-in approach and eventually making it the default
  • Likely will not have a significant impact on typical frontend page loads, as it’s mostly useful for areas like the REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. schema output, where a lot of translation calls are made without actually using the translations
    • Needs analysis in more scenarios to measure impact
    • The REST API schema already has a workaround by using a cache in a static variable
  • Does not improve situation for actually loading translation files
  • Initial testing shows that this actually hurts performance due to the additional thousands of proxy objects being created

Effort and timeline

Gradual adoption would mean a multi-year effort to establish lazily evaluated translation calls, while enabling this by default is a significant backward compatibility break that could affect thousands of plugins and themes in the ecosystem. And since it does actually slow down performance in some cases, this solution is not a great candidate for implementation.

Solution E: Optimize/Rewrite existing MO parser

Refactor the existing MO parser in WordPress to be more performant.

Design considerations

Completely overhaul the existing MO translation file parser in WordPress with performance in mind. For example by using Ginger MO, WP Performance Pack, or other existing solutions as a base.

While for instance Altis DXP (Human Made) have actually replaced the existing MO parser with a custom-made PHP extension written in Rust, such an approach is obviously not feasible for core. The new solution needs to be written in userland PHP.

Initial testings with an updated fork of Ginger MO show some noticeable speedups and lower memory usage. It also supports multiple translation files per text domain and multiple locales loaded at once, which could prove beneficial for improving the 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. switching functionality in WordPress core.

Besides that, plugins like WP Performance Pack and DynaMo have implemented partial lookups using the MO hash table or binary search, avoiding reading the whole file and storing it in memory. That slightly reduces memory usage and performance.

Benefits

  • Can be used without necessarily introducing another file format
  • Opens up potential performance enhancements in other areas, i.e. locale switching
  • Mostly maintains backward compatibility

Caveats and risks

  • Still a risk of breaking backward compatibility

Effort and timeline

There already is a working proof of concept for this solution, but more testing is required to further refine it and improve its backward compatibility layer. With such an effort being an ideal candidate for a feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins., this could be achieved relatively quickly in a few months.

Solution F: Splitting up translation files

Split translation files from plugins and themes into smaller chunks to make loading them more efficient.

Design considerations

Depending on the project’s size, translation files can be quite big. That’s why WordPress itself uses separate translation files for the admin and everything else, so that not too many strings are unnecessarily loaded.

This strategy could be applied to plugins and themes as well. Either by allowing them to use multiple text domains (which would require developer education and changes to tooling), or by somehow doing this automatically (exact method TBD)

Benefits

  • Faster loading times due to loading smaller files

Caveats and risks

  • Risk of breaking backward compatibility
  • Opt-in approach requires tooling and distribution changes and risks slow adoption

Effort and timeline

Further research is required to evaluate this properly.

Comparison

At first glance, solution A (PHP translation files) is a relatively straightforward enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. that maintains backward compatibility and shows promising improvements. However, it does not only require changes to core itself, but also to the translation platform. The security aspect remains a risk, although discussing it early on with stakeholders and gathering more testers would help mitigate it.

Leveraging the native gettext extension as in solution B shows stunning results, but the lack of availability and the non-ideal API are a concern. Still, it’s a progressive enhancement that cannot be ignored. Especially since it could pretty much eliminate the need for additional caching as in solution C.

Caching already loaded translations as in solution C does not eliminate the root cause of the i18n slowness, but can speed up subsequent requests. Unfortunately, persistent object caches or APCu are rather uncommon (though we do not have exact data on the former yet, see #58808), and implementing more complex types of caching (e.g. per-request caching) would require significant exploration effort before becoming a viable option.

Lazily evaluated translation calls (solution D) can shave time off translation calls in some situations, but overall actually decrease performance. While it could help solve some actual UX issues in core, the backward compatibility and adoption concerns make it even less of a suitable solution.

Existing plugins like Ginger MO and WP Performance Pack show that the existing MO parser in WordPress can be further improved (solution E).

Benchmarks

Now to the most interesting part: the hard numbers!

These benchmarks are powered by a custom-built performance testing environment using @wordpress/env and Playwright. The environment has been configured with some additional plugins and the PHP extensions required for some of the solutions. Tests have been performed against the 6.3 RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). by visiting the home page and the dashboard 30 times each and then using the median values.

You can find the exact setup in this wp-i18n-benchmarks GitHub repository.

BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Theme

LocaleScenarioObject CacheMemory UsageTotal Load Time
en_USDefault15.60 MB133.58 ms
de_DEDefault29.14 MB181.95 ms
de_DEGinger MO (MO)19.24 MB159.18 ms
de_DEGinger MO (PHP)16.98 MB138.14 ms
de_DEGinger MO (JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML.)19.24 MB153.39 ms
de_DENative Gettext15.99 MB142.12 ms
de_DEDynaMo19.62 MB157.93 ms
de_DECache in APCu50.37 MB181.51 ms
en_USDefault15.67 MB121.53 ms
de_DEDefault29.01 MB167.67 ms
de_DEGinger MO (MO)19.11 MB147.19 ms
de_DEGinger MO (PHP)16.85 MB127.97 ms
de_DEGinger MO (JSON)19.11 MB144.43 ms
de_DENative Gettext15.86 MB129.19 ms
de_DEDynaMo18.57 MB133.46 ms
de_DECache in APCu50.30 MB170.19 ms
de_DECache in object cache29.07 MB173.19 ms
Benchmarks using the Twenty Twenty-Three block theme

Classic Theme

LocaleScenarioObject CacheMemory UsageTotal Load Time
en_USDefault15.35 MB120.79 ms
de_DEDefault28.79 MB172.10 ms
de_DEGinger MO (MO)18.85 MB145.68 ms
de_DEGinger MO (PHP)16.56 MB124.73 ms
de_DEGinger MO (JSON)18.84 MB140.78 ms
de_DENative Gettext15.58 MB128.26 ms
de_DEDynaMo19.24 MB146.09 ms
de_DECache in APCu50.13 MB167.28 ms
en_USDefault15.19 MB107.26 ms
de_DEDefault28.59 MB154.30 ms
de_DEGinger MO (MO)18.64 MB133.21 ms
de_DEGinger MO (PHP)16.37 MB112.94 ms
de_DEGinger MO (JSON)18.64 MB128.94 ms
de_DENative Gettext15.38 MB115.11 ms
de_DEDynaMo18.10 MB120.72 ms
de_DECache in APCu49.99 MB151.82 ms
de_DECache in object cache28.65 MB156.36 ms
Benchmarks using the Twenty Twenty-One classic theme

Admin

LocaleScenarioObject CacheMemory UsageTotal Load Time
en_USDefault15.42 MB139.83 ms
de_DEDefault31.92 MB187.76 ms
de_DEGinger MO (MO)20.07 MB164.94 ms
de_DEGinger MO (PHP)17.09 MB139.66 ms
de_DEGinger MO (JSON)20.06 MB160.87 ms
de_DENative Gettext15.95 MB143.43 ms
de_DEDynaMo20.58 MB166.79 ms
de_DECache in APCu58.13 MB190.38 ms
en_USDefault15.66 MB112.69 ms
de_DEDefault31.84 MB164.26 ms
de_DEGinger MO (MO)19.99 MB140.70 ms
de_DEGinger MO (PHP)17.01 MB118.52 ms
de_DEGinger MO (JSON)19.98 MB138.49 ms
de_DENative Gettext15.87 MB120.01 ms
de_DEDynaMo19.73 MB120.26 ms
de_DECache in APCu58.07 MB162.41 ms
de_DECache in object cache31.86 MB164.28 ms
Benchmarks visiting the WordPress admin

Conclusion

Finding the right path forward means weighing all the pros and cons of each solution and looking at both horizontal and vertical impact, i.e. how much faster can i18n be made for how many sites.

When looking at all these factors, it appears that a revamped translations parser (solution E) could bring the most significant improvements to all localized WordPress sites. Especially when combined with a new PHP translation file format (solution A), which Ginger MO supports, the i18n overhead becomes negligible. Of course the same risks associated with introducing a new format apply.

On top of that, a revamped i18n library like Ginger MO could also be combined with other solutions such as caching or dynamic MO loading to potentially gain further improvements. However, those routes have yet to be explored.

Next steps

The WordPress performance team wants to further dive into this topic and test some of the above solutions (and combinations thereof) on a wider scale through efforts like the Performance Lab feature project. We are looking forward to hearing your feedback on this analysis and welcome any additional comments, insights, and tinkering.

Deadline August 6, 2023

After the deadline passes, the performance team will discuss the received feedback and determine next steps.


Thank you to @flixos90, @westonruter, @joemcgill, @spacedmonkey, and @adamsilverstein for reviewing and helping with this post. Thank you to @nbachiyski, @ocean90, @akirk, @rmccue, @dd32 for providing valuable insights and context.

#core, #i18n, #performance

I18N Improvements in 6.3

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

Allow to short-circuit load_textdomain()

In #58035 / [55928], a new pre_load_textdomain 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. was introduced. This is useful for plugins to develop and test alternative loading/caching strategies for translations. This brings consistency with the existing pre_load_script_translations filter for JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. translations.

Improvements to just-in-time translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. loading

In #58321, it was reported that _load_textdomain_just_in_time() was firing too often if no translations were found for a given text domain, which typically is the case on site running English (US).

[55865] addresses this issue, which resulted in some minor performance improvements.

Props to @spacedmonkey for technical review, to @stevenlinx for proofreading.

#6-3, #dev-notes, #dev-notes6-3, #i18n

Preferred Languages: Help test the latest version

Since the last update on the Preferred Languages feature plugin, a lot of work has been accomplished both on the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party side and in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. to make the solution more robust in a variety of ways. Today, I want to provide a bit more details on these accomplishments, which resulted in the recent release of Preferred Languages 2.0, advancing the project a huge step closer towards a core merge proposal

But first, make sure to check out the previous update:

Improved Stability, Fully Rewritten

Over the last year, a lot of work has gone into making the plugin more stable by adding more tests and fixing bugs. This includes improving compatibility with other plugins and making translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. merging and 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. switching more robust. As a result, pure unit testunit test Code written to test a small piece of code or functionality within a larger application. Everything from themes to WordPress core have a series of unit tests. Also see regression. code coverage is near 100%, with end-to-end tests adding another layer of confidence.

With WordPress adding several i18ni18n Internationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill. improvements in WordPress 6.1 and 6.2, the Preferred Languages plugin is now fully compatible with WP_Textdomain_Registry and switch_to_user_locale(). The minimum required WordPress version has been bumped to 6.1 as a result.

Certainly the biggest change, however, was the full refactoring of the UIUI User interface itself. The whole JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. portion of the code base was over 6 years old and using jQuery and jQuery UI. But not anymore! The UI has been completely refactored to use ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/., with the same components that also power the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor. In the process, drag & drop sorting functionality was removed to simplify the UI, and 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) has improved, but otherwise everything looks mostly the same.

How to help

So, what’s next? The latest version of 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. needs more eyes testing it and providing feedback.

One big remaining question mark is the concept of translation merging. By default, if there are only some missing strings in a selected locale, these would be displayed in English. But with translation merging, the missing strings will be taken from the locale next in line instead. While this works great, it could be a tad slow due to the way translations are loaded in WordPress. Any help addressing this potential performance concern would be greatly appreciated.

Note: The merging feature can be enabled with add_filter( 'preferred_languages_merge_translations', '__return_true' );.

Active development is taking place on GitHub. If you want to get involved, check out the open issues and join the #core-i18n channel on Slack.

Props to @ocean90 for reviewing this post.

#feature-plugins, #feature-projects, #i18n, #polyglots, #preferred-languages