Sometimes the simplest questions can lead you down the biggest rabbit holes.
A few weeks ago, I asked our team, “What is the best way to translate WordPress plugins?“
We need an answer because we've been growing quickly here at PublishPress. More users are asking if our plugins are available in different languages.
The technical side seemed relatively straightforward. This post by Daniel Pataki is an excellent introduction. But some points were unclear to me:
- How do we accept translations from users?
- What about the Pro versions of the plugins?
- Which folder should the translation files be stored in?
- What kind of files should we use?
So I decided to download some of the most popular plugins and see what they did. That only made it more confusing. I choose 10 popular plugins at random and looked at how they are translated.
#1. Yoast SEO translations
The Yoast SEO team use multiple .json files that are installed in your site's main /wp-content/languages/ folder.
They also have .mo and .po files added to the /wp-content/languages/plugins/ folder.
Why have different translation files? It is because WordPress requires
.mo files for translating PHP files, but it requires a
#2. WP Forms translations
The WP Forms team use .mo and .po files that are installed in your site's main /wp-content/languages/plugins/ folder.
This is the WP Forms guide to translations. They don't appear to have an option to contribute translations outside of WordPress.org.
#3. Advanced Custom Fields translations
The Advanced Custom Fields team use .mo and .po files that are installed in the /wp-content/plugins/advanced-custom-fields/lang/ folder.
This is their getting started guide. They run everything through Github, with a private repo for the Pro version.
#4. Ninja Forms translations
The Ninja Forms team use .mo and .po files that are installed in the /wp-content/plugins/ninja-forms/lang/ folder.
#5. Elementor translations
The Elementor team use .mo and .po files that are installed in the /wp-content/languages/plugins/ folder.
The main translation documentation is available here. They recommend that everyone contribute translations on WordPress.org. I couldn't find any details on translating Elementor Pro add-ons.
#6. WooCommerce translations
The Ninja Forms team mostly use .json files but also have some .mo and .po files that are installed in the /wp-content/languages/plugins/ folder.
This is their translation documentation. All the translations run through WordPress.org. For WooCommerce extensions, it's up to each developer. For example, SkyVerge have their own translation framework.
#7. Beaver Builder translations
The Beaver Builder team use .mo and .po files that are installed in the /wp-content/languages/plugins/ folder.
Beaver Builder don't use the GlotPress installed on WordPress.org, but instead have set up their own GlotPress system.
#8. Advanced Gutenberg translations
The Advanced Gutenberg team mostly use .mo and .po files but also have .json files that are installed in the /wp-content/languages/plugins/ folder.
They have their own integrated extension tool that allows you to translate inside the WordPress admin area.
#9. Wordfence translations
The Wordfence team have no translations available on WordPress.org and no translation documentation that I could find.
#10. The Events Calendar translations
The The Events Calendar team use .mo and .po files that are installed in the /wp-content/languages/plugins/ folder.
The world of WordPress translation is messy, and particularly for plugins with a Pro version. My 10 random plugins had 10 different approaches:
- Some developers store their translations in the /wp-content/languages/ folder. Others keep it inside their plugins folder.
- All developers use .mo and .po files but many also rely heavily on their own frameworks and .json files.
- For the free versions of plugins, WordPress.org is standard. However, many developers seem to think the system is slow and bureaucratic.
- For Pro versions, Github, Transifex, WPML and GlotPress are all options but there are custom tools too.
- The documentation for translations was almost always poor, or just missing.
Overall, this was a worthwhile exercise. There is no “best practice” when it comes to translating plugins. Everyone is doing their own thing. So I don't feel too bad about not having a clear and reliable system for translating PublishPress plugins yet.
After this research, our plan at the moment is to host all the translation files on Github. If you have any better ideas, I'd love to hear from you.