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. 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 authors receive an email in advance of their plugin being imported into translate.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/ 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 plugin or theme translation reaches 90% of the strings from the code translated and approved in translate.wordpress.org, a language pack for the plugin and target language will be generated. That is, if Akismet is fully translated into Romanian (90%), a language pack will be generated for Romanian. If there is a language pack since before, then any changes to the source strings or the translations will trigger generation of a new language pack, even if the count of translated strings is below the threshold.
  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 SVNSVN Apache Subversion (often abbreviated SVN, after its command name svn) is a software versioning and revision control system. Software developers use Subversion to maintain current and historical versions of files such as source code, web pages, and documentation. Its goal is to be a mostly compatible successor to the widely used Concurrent Versions System (CVS). WordPress core and the wordpress.org released code are all centrally managed through SVN. https://subversion.apache.org/.).

Overall, this is how the import works.

FAQ

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

Top ↑

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 headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. that matches the slug of your plugin.

Top ↑

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

The translation system looks through all PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.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?

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?

See the description in the beginning of this page.

Top ↑

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?

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?

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.

Top ↑

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?

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?

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 (GTEGeneral Translation Editor General Translation Editor – One of the polyglots team leads in a geographic region https://make.wordpress.org/polyglots/teams/. Further information at https://make.wordpress.org/polyglots/handbook/glossary/#general-translation-editor.) 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?

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 teamPolyglots Team Polyglots Team is a group of multilingual translators who work on translating plugins, themes, documentation, and front-facing marketing copy. https://make.wordpress.org/polyglots/teams/. 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 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/. (#polyglots-warnings). It is strongly recommended that you keep an eye on your plugin in this channel.

Top ↑

How to handle “This plugin is not properly prepared for localization.” warning?

You may get this message on your plugin page at translate.wordpress.org and it usually means that something is wrong with the text domain. Please make sure you have read the developer docs on Text Domains and Loading Text Domain for plugins. Consider only supporting WordPress 4.6 and above which has improved the text domain loading.

To get more details about a failed import please join the WordPress Slack workspace 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.

Last updated: