__() function as in PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher and therefore don’t have to learn anything new. WordPress can take it from there.
- Use that POT file to write the exact same internationalization functions in a “fake” PHP file that can be scanned by the WordPress.org translation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. platform. This will result in PO and MO files containing all of your plugin’s translations.
wp_add_inline_script(). Ideally you’d only load the ones needed by that specific script as you don’t want to print thousands of strings in that inline JS when you only need a few of them.
An example of that process can be found in my demo Gutenberg I18N Block plugin.
At this point you might want to go back to good old
wp_localize_script() and simply keep using that for internationalization purposes. I don’t blame you.
The platform uses a script called makepot.php to scan PHP files all across the WordPress.org ecosystem, i.e. core, meta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress., and all default themes. In addition to regular Gettext function calls it also scans plugin and theme file headers. Being included in many other libraries, makepot is a widely used tool. Most recently, its functionality was ported to a WP-CLI command to make string extraction easier to use.
Can we simply use that Babel plugin on WordPress.org? What happens to makepot.php? What are the implications for all the developers out there not hosting their projects on WordPress.org? Not everyone uses the Babel transpiler, and certainly not everyone wants to use two separate tools just to extract some internationalization functions.
Loading only specific set of translations
All translations for a plugin or theme are stored in one single PO / MO file per locale 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.. Loading these translations is a slow process. We’ve made some improvements in that regard over the years, for example by introducing just-in-time loading of translations in WordPress 4.6.
However, if you only need a handful of translations for a single script in your plugin, it does not make sense to load the entire MO file which can be dozens of kilobytes in size. There’s currently no way to load only a specific set of translations in WordPress. This is something that came up in Gutenberg before, see issue 6015.
GlotPress doesn’t know about the text domain, but it does know a string’s source file. What if it would export one JSON file per source file it has scanned? This way WordPress has full control over the translations and one could specify which JSON files need to be loaded for a specific module.
The big drawback here: a single module might consist of dozens of source files. Having one JSON file for each of those is not going to scale well.
Don’t do anything fancy. Sticking with a JSON file already guarantees that a plugin doesn’t unnecessarily load all the translations needed just in PHP. So the file size is definitely smaller. Still, this file alone can be very large for an application like Gutenberg.
Keep one single JSON file for all translations, but use some PHP code to only ever pass the strings to a module / script handle that it actually needs. However, there’s probably no real benefit in doing so.
Easily load translations
Up until WordPress 4.6, developers needed to use
load_theme_textdomain() to make sure translations are properly loaded. Now, you only need to use the various translation functions and the rest just works. The only requirement is that your translation files reside in
wp-content/languages. This is usually the case when your project is hosted on WordPress.org.
Imagine having a plugin
wp_enqueue_script( 'foo-script', plugins_url( '/foo-script.js' , __FILE__ ) );
Ideally, all you’d need to do to translate it is calling a function like
load_js_textdomain( 'foo-plugin' ). WordPress would then do all the heavy lifting.
However, other options might exist, and this solution would need to be tested in the wild with bigger projects like Gutenberg.
Ideally, we hold a separate JS I18N meeting with all the teams primarily involved: #core-i18n, #core-js, #core-editor, #meta-i18n and #cli. Everyone is welcome to attend though 🎉
I suggest the following date for such a meeting: Tuesday, May 8 15:00 UTC. Of course I’m open for other suggestions. The Slack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel would be #core-i18n.
If you have any questions or concerns about this post or the overall topic, please leave a comment below.