Introduction
There’s a lot of information around in lots of pages, but here is a QRG to go over your plugin.
Want to quickly test your the health of your plugin readme and main php files on the WordPress.org repository? Try http://wp-info.org/tools/checkplugini18n.php
As I presume you will put your plugin on wordpress.org, just localize your plugin and upload a (new) version to wordpress.org. If you upload for the first time and have existing .po/.mo files, then just include them and they will be imported into GlotPress.
All people can now start translating. When all online translation is performed and validated at least for 90%, a language pack is created. You can remove the .po / .mo files from your upload some versions later.
Note: Starting from WordPress 4.6, the primary translation will be the centralized one on GlotPress, if it’s not found there, local .po/.mo files will be used. For WordPress versions before 4.6 the local .po/.mo were first used and if not existing, the centralized ones were downloaded and used.
Advantages of translate.wordpress.org:
- Ease of translating without using a 3rd party program like Poedit
- Smaller download sizes for your plugins since you don’t need to include the translation files
- Ability to translate your plugin’s readme file
Full ‘official’ version for you as a plugin author can be found here: https://developer.wordpress.org/plugins/internationalization/how-to-internationalize-your-plugin/
Using SVN: https://wordpress.org/plugins/about/svn/
Check the Frequently Asked polyglots Questions on https://make.wordpress.org/polyglots/handbook/frequently-asked-questions/
For your contributors that want to help translating, the handbook is: https://make.wordpress.org/polyglots/handbook/tools/glotpress-translate-wordpress-org/
Readme.txt
- The readme.txt in /trunk should point to the correct ‘Stable tag‘. If you only work in trunk, add ‘Stable tag: trunk‘ (see https://wordpress.org/plugins/about/readme.txt). If you have set a stable tag in the readme.txt from /trunk, all other needed information is taken from the readme.txt in that stable tag (see https://developer.wordpress.org/plugins/wordpress-org/how-your-readme-txt-works/#how-the-readme-is-parsed)
- If you want to limit your plugin to 4.6 and up, make sure to add Requires at least: 4.6 in your readme.txt, then you can probably remove the Domain Path: line and no need for a load_plugin_textdomain
- !WARNING! There is a size limit of around 10k on this file. If your file is bigger, it might not be correctly parsed on the repository and so not showing part of info in the file. Proposal is to keep the Changelog in a separate (e.g. changelog.txt) file and keep only the last changelogs inside the readme.txt.
- Check the readme generator and validator .
Your plugin header
(If you want to limit your plugin to 4.6 and up, make sure to add Requires at least: 4.6 in your readme.txt, then you can probably remove the Domain Path: line)
=> The ‘Text Domain’ must match the slug of your plugin on wordpress.org ! <=
Header example:
/*
* Plugin Name: My Plugin
* Author: Plugin Author
* Text Domain: my-plugin
* Domain Path: /languages
*/
Strings
Make sure all strings are localized and have the text domain:
__( ‘Email addresses do not match!’ , ‘my-plugin’ )
Add comments
Make sure translators understand the string correctly, add enough information between /* and */ just before the function you call. This information will be clearly displayed on GlotPress.
/* translators: 1: WordPress version number, 2: plural number of bugs. */
_n_noop( ‘<strong>Version %1$s</strong> addressed %2$s bug.’, ‘<strong>Version %1$s</strong> addressed %2$s bugs.’ );
=> If translator comments are missing for strings with placeholders inside, WPCS will generate an error, see here ! <=
Load your textdomain
(no longer needed if running on WordPress 4.6. If you want to limit your plugin to 4.6 and up, make sure to add Requires at least: 4.6 in your readme.txt, then you can ommit this function)
function my_plugin_load_plugin_textdomain() {
load_plugin_textdomain( ‘my-plugin’, FALSE, basename( dirname( __FILE__ ) ) . ‘/languages/’ );
}
add_action( ‘plugins_loaded’, ‘my_plugin_load_plugin_textdomain’ );
Check the outcome
Commit your plugin.
All changed plugins get checked several times a day.
Check for your plugin slug on wordpress.slack.com in channels #meta-language-packs and #polyglots-warnings
If after some hours there is still no trace that your plugin has been taken into account OR if you get strange errors, add a whitespace or change a character in e.g. readme.txt in trunk and submit again to trigger the check again.
Translate online
If you already have some .po files locally, then note that you can upload them yourself so your contributors/validators do not start with an empty language:
- Go to the translation page of your plugin: https://translate.wordpress.org/projects/wp-plugins/my-plugin
- Choose the locale/language and then open the ‘Stable’ (or any other subpart)
- At the bottom of that page you will find a link to ‘import translations’. This will import all strings as ‘suggestions’, so you still need a PTE or GTE (see handbook) to validate the strings.
Then make publicity and ask your contributors to start translating online.
- You can contact the persons you know that already translated for you in the past and ask them to add their translation online
- Make publicity on your support forum or with a message inside your plugin (like on the settings page)
- See the polyglots handbook to give them validation (PTE) rights.
The link for the translation: https://translate.wordpress.org/projects/wp-plugins/my-plugin
Frequently Asked Questions
A plugin only uses trunk, is that correct?
A developer can decide to only have his plugin using trunk. This means that the ‘production’ version is taken from trunk. Personally I’m not in favor of it, because I see more negative then positive sides on it:
- Positive: If the developer has his development environment out of wordpress.org, there is only the need to upload once from the dev environment to wordpress.org and it becomes immediately available to all for use and for the translators
- Negative: A translator cannot translate dev, because the moment it goes on wordpress.org it is immediately production, so people already start upgrading to the new version while the translator still needs to translate the new strings
- Negative: There is no easy rollback in case the new version of the plugin does not work in your own environment because the previous version is no longer existing on wordpress.org
But … “I am the dev and I did not want this, I wanted to use stable !”. In that case, these are the actions:
- In the readme.txt that is in trunk, the Stable tag: probably says ‘trunk’ (so pointing to trunk), change it to your version, e.g. 1.4.3
- Make sure that you have all needed files under the version tag, e.g. https://plugins.svn.wordpress.org/my-plugin/tags/1.4.3
- Trunk will have your development version, the folder under /tags has your production one