Language Packs Proposal

The Language Pack

A language pack must consist of the .mo file for a theme or plugin. This may be in the form of a zip (or otherwise compressed) for reasons of transfer speed.

  • Should a language pack also consist of the .po file?
  • Or: How do you tell language packs apart?

The burning question here is that there needs to be a way to ascertain from the filesystem what version a language pack is. This could be done by md5’ing the .mo file and keeping track of each iteration on WordPress.org. Alternatively, a .po file’s headers can be used, or there will need to be a third file to store metadata.

Alternatively, WordPress keeps track of the whole thing based on what it has downloaded and placed, which means WordPress would be oblivious to any language files installed via the filesystem. Seems less than ideal.

For core, a language pack will actually be a localized partial build. While it takes a cue from the existing partial builds system, it will need to handle core po/mo files and translation changes in the startup WordPress files (i.e. WP_I18N_* in wp-load.php), readme.html, wp-config-sample.php, and anything else in /dist that we still consider valid (such as licencia.txt).

The Theme/Plugin Developer

The plugin developer will internationalize the plugin, including the Text Domain plugin header, and text domains used throughout the code.

  • For version 2, we may be able to handle text domains for the plugin developer.

The domain must match the plugin slug. This can be enforced on a pre-commit hook if translation functions are identified.

The WordPress.org User and Translator

The plugin page will list the languages available for the plugin. It will do this by looking for the .po/.mo files in the plugin, and also by cross-referencing GlotPress. The translator will be able to click “Translate this plugin in your language,” which will take them to an instruction and setup page in GlotPress. There are three situations we will need to handle:

  • The language does not currently exist in GlotPress. (Propose it on wppolyglots?)
  • The plugin does not currently exist in GlotPress. Create it automatically.
  • The language set has not been added to the plugin. Create it automatically.

The user will then be able to translate the strings for the plugin. Per the instructions, once translated, it will enter a queue for the language team.

The Language Maintainer

The language maintainer will be able to go to a screen with every plugin currently in the system, sorted by the percentage translated. (This screen will need to be paginated.) When a user hits 100% on a plugin, the language team (Editors in Rosetta) will be emailed to approve the translation set.

  • I don’t see a reason why the plugin developer also can’t approve a translation set, which had been occurring before. After all, they have more incentive than the language maintainer.

The WordPress User

The user is given the following prompt on the Dashboard/Updates screen:

Your language files are out of date. [Update]

That’s it. The user will not be given a breakdown. They are simply offered an opportunity to update the language files for their plugins, themes, and core, at once.

On any plugin, theme, or core update, we will also trigger a full update of all language files that are out of date, automatically.

  • If wp-content/languages/plugins and wp-content/languages/themes are properly writeable, we could potentially stream individual .mo and .po files directly into place on cron, without needing to ask for FTP credentials. This would be the first step for truly automatic updates.

WordPress Core

The theme, plugin, and core update checks will be updated to also receive translation data. This data will then be parsed and stored in the individual update_* transients. A single function call, get_language_updates(), will then pool the data for core access, to determine if updates are necessary.

The data returned will consist of a URL to the .mo and .po files (for plugins and themes) and a partial build package (for core).

The data sent will consist of the plugin and theme versions, and the revision of the individual language files (ascertained by reading the .po files).

On plugin activation/deactivation, and theme activation, we should keep track of what language packs will need to be loaded. On load, we can then loop through this option and load the textdomains.

WordPress.org API

The WordPress.org API will need to be updated for plugins, themes, and core. GlotPress will be checked to ascertain, for the plugin’s current stable version (ignoring people who have not updated), whether the language files have changed, according to the data passed from core.

If so, the proper data will be served back to core — essentially, an object of plugin slugs, mo/po URLs, version and revision numbers, etc.

  • It may be easier to do one language API call (or three language API calls) rather than piggybacking on the core, theme, and plugin calls.

Burning Questions

  • How do we support multiple languages, such as a multisite installation?
  • What does a plugin or theme language pack actually look like?