Plugin authors: did you know that you can allow translators to localize the plugin details that show up in the plugins list in the WordPress administration area? Your plugin’s name, description, and so forth? Well you can! It’s actually really simple to do and all you need to do is add one or two additional plugin headers to your file.
The first is
Text Domain and this is the text domain for your plugin, i.e. the first argument that you are passing to
The second one is
Domain Path and is optional. It’s only needed if you store your translation files in a subfolder inside of your plugin’s folder.
Here’s an example
load_plugin_textdomain() call from one of my newest plugins:
load_plugin_textdomain( 'add-descendants-as-submenu-items', false, dirname( plugin_basename( __FILE__ ) ) . '/localization/' );
That loads translation files from a subfolder called “localization” inside of my plugin’s folder. This turns into the following plugin header:
Plugin Name: Add Descendants As Submenu Items Plugin URI: http://www.viper007bond.com/wordpress-plugins/add-descendants-as-submenu-items/ Description: Automatically all of a nav menu item's descendants as submenu items. Designed for pages but will work with any hierarchical post type or taxonomy. Version: 1.1.0 Author: Alex Mills (Viper007Bond) Author URI: http://www.viper007bond.com/ Text Domain: add-descendants-as-submenu-items Domain Path: /localization/
An extra line break isn’t needed nor is the extra spacing but I added both just for aesthetic reasons.
And that’s it! WordPress will then attempt to translate the plugin’s name, URI, description, author, author URI, and version fields. I personally only include the plugin’s name and description in my translation template files though as I don’t feel translators need to localize the other fields.
If you need help generating a translation template file for your plugin, log into WordPress.org and then visit the “Admin” tab on your plugin’s page on WordPress.org. You can generate a POT file for your plugin there.
i think this example is not the best, why you create redundant data, the string for translation in the comment of the plugin and also in the function to load translation files. I think ist geat to use the function get_plugin_data() to read the value fomr the comments of the plugin and the return value for TextDomain to the function and also to the strings inside the source of the plugin to read the textdomain. What do you mean to this idea?
Because my way is significantly faster. You don’t want to have WordPress use regex to parse the plugin header on every page load. Speed is more important than not having to type out a string twice. I mean, how often is it going to change? The answer of course is never.
I think, you have right in the topic speed, but not in the topic for clean coding. Before WP add the value to the comment, i have small dicuss on the dev of WP. I think, WP should create an solution for this, not the user to write plugins. Current is an option for the devs of plugin, at first he writes cleaner code or faster plugins. 😉
Actually, you can add spaces between header words:
No need to squish them together.
Whoops, you’re correct and infact I think that’s required to work. I was referencing the mapped keys instead of what it was parsing for in
Post fixed. 🙂
Pingback: Translating WordPress Plugin Details ? Viper007Bond.com | Wordpress Plugin Gratis
I tried to do the same for a theme but it did not work, any suggestions?
This example would be more complete with your PO file. I’m assuming the translation keys should be “Plugin Name”, “Description”, etc?
This post is 5 years old and out of date. Plugins are now translated via https://translate.wordpress.org/