Translations

Translations for themes and plugins are relatively new and there have been a number of questions about them. Here’s an overview of how the process works, using plugins as an example.

  1. Plugin authors receive an email in advance of their plugin being imported into translate.wordpress.org with a general estimate (“next week”). The email also mentions if no text domain was found or if there was a text domain mismatch. The WordPress.org plugin directory has the translations import mechanism currently enabled for all plugins. The update will happen for the plugin at the time of the next commit.
  2. For a plugin to be imported properly and take advantage of language packs, it must have a text domain that matches its slug (e.g., a plugin with the “akismet” slug must have a text domain of “akismet”) and must not have more than one text domain.
  3. Additionally, if the plugin already ships language files (.mo), these will be imported into translate.wordpress.org.
  4. When the time comes, the plugin is imported into translate.wordpress.org.
  5. Once a translation reaches 95% in translate.wordpress.org, a language pack will be generated. This is per-locale, not per-plugin. That is, if Akismet is fully translated into Romanian (95%), a language pack will be generated for Romanian.
  6. Once a plugin has been imported and the relevant language packs have been generated, plugins can remove the language files from their package (and from SVN).

Overall, this is how the import works.

FAQ FAQ

But you might have some questions. Here’s some answers to frequent questions.

How do I internationalize my plugin? How do I set a text domain? How do I internationalize my plugin? How do I set a text domain?

Please follow the instructions in the plugin developer handbook to internationalize all your strings, taking careful note to have a “Text Domain:” in your plugin header that matches the slug of your plugin.

Top ↑

How does the translation system import strings? Do I need .po/.pot files? How does the translation system import strings? Do I need .po/.pot files?

The translation system looks through all PHP files in a plugin and finds each gettext call, including __() and _e(). For this reason, .po/.pot files are not needed to import, however they’re a great way of ensuring your entire plugin is completely internationalized.

Top ↑

For better performance, I use multiple load_plugin_textdomain() calls to enable only the strings I need, when I need them. How do I do this with language packs and translate.wordpress.org? For better performance, I use multiple load_plugin_textdomain() calls to enable only the strings I need, when I need them. How do I do this with language packs and translate.wordpress.org?

Short answer: You don’t.

Long answer: You don’t have to! WordPress is entirely performant for languages. Some plugins have thousands of strings and experience no issues at all. Further, WordPress itself uses thousands of strings and has no issues. The language pack system will only generate one language pack per plugin, so you will need to remove the multiple calls and multiple text domains, if they exist.

Top ↑

When are language packs generated for each locale? When are language packs generated for each locale?

Language packs are only generated when a translation is complete (aka, reaches 95%).

Top ↑

When you say complete, does that include the associated Readme project as well? When you say complete, does that include the associated Readme project as well?

No. Only the strings that apply to the plugin’s code must be translated for language packs to be generated.

Top ↑

What are the benefits of language packs? What about translate.wordpress.org? What are the benefits of language packs? What about translate.wordpress.org?

Language packs are great for users and great for plugin authors.

First off, language packs are great for plugin authors because the plugin author no longer has to ship language files. When WordPress needs a language file for a theme or plugin, it automatically downloads the relevant language file. With translate.wordpress.org, plugin authors also do not need to worry about setting up their own infrastructure for translations and can rely on a global community with dozens of active locales.

For users, language packs enable smaller plugin download sizes and give users the ability to translate the plugin into their language directly on translate.wordpress.org.

Top ↑

What if I don’t want to be imported into translate.wordpress.org? What if I don’t want language packs? What if I don’t want to be imported into translate.wordpress.org? What if I don’t want language packs?

Eventually, all active plugins will be imported into translate.wordpress.org. Just as there is not an option for plugins on which version control system they can use on WordPress.org (you must use SVN), there is no option on getting imported into translate.wordpress.org.

That said, plugins can opt-out of language packs for languages they wish to ship by continuing to ship language files. That’s right, if a plugin does nothing, they will automatically opt-out of language packs from translate.wordpress.org and any benefits therein. Plugins must remove the language files from their package to participate in language packs.

Top ↑

When you import my plugin, what happens to my existing translations? When you import my plugin, what happens to my existing translations?

Existing translations (that is, .mo language files) are imported into the translation system during the initial import. They are not imported again as the expectation is that translations will take place on translate.wordpress.org in the future.

Top ↑

I have my own translation system and a great team of translators. Can I bring them over? I have my own translation system and a great team of translators. Can I bring them over?

Absolutely! On WordPress.org, anyone with an account can translate any project into any language. These translations must then be approved by translation editors (previously called validators).

If you have a trusted set of translators and would like them to become translation editors for your plugin, the easiest way to bring them over is to make a post on make/polyglots with your request. The polyglots handbook has a great overview of how to do this. You can also see the list of requests so far.

Top ↑

Who can translate my plugin? Who can translate my plugin?

Anyone! Our GlotPress installation (translate.wordpress.org) is open to anyone with a WordPress.org account. However, just because anyone can translate, doesn’t mean their strings will get approved.

Our translation system has varying levels of permissions with General Translation Editors (GTE) at the highest level. These GTEs can approve strings for any project in their locale. Beneath them are Project Translation Editors (PTE), which can only approve strings within a project, for their locale. For example, if they have been given permission to approve strings for Akismet, they can only approve strings for Akismet in their locale and not for other plugins or other locales.

Top ↑

I’m a plugin author. How do I become a project translation editor for my plugin? I’m a plugin author. How do I become a project translation editor for my plugin?

The only way to become a translation editor for your plugin is to request access using the method above. However, we strongly recommend that the polyglots team does not add a plugin author to every locale. The ultimate goal of translate.wordpress.org is to enable translators from around the world to translate plugins, themes, and WordPress. Plugin authors should not be expected to speak 155 languages (and counting), but should instead be able to trust the translation community.

Top ↑

Any and all warnings generated by translate.wordpress.org are logged and displayed in a channel on Slack (#polyglots-warnings). It is strongly recommended that you keep an eye on your plugin in this channel.

Top ↑

“This plugin is not properly prepared for localization.” – Help? “This plugin is not properly prepared for localization.” – Help?

You get this message on your plugin page at translate.wordpress.org and it usually means that something is wrong with the text domain. To get the details about a failed import please join the Slack team and switch to the #meta-language-packs channel. All imports are getting logged here. Search by the slug of your plugin to get the relevant results.