A discussion that I keep coming across with i18n in WordPress is the use of variables and constants for text domains. Everyone keeps on linking to Mark Jaquith’s post “Translating WordPress Plugins and Themes: Don’t Get Clever” and Otto’s post “Internationalization: You’re probably doing it wrong” Here are some quotes from Mark’s post:
GNU gettext is not a PHP parser. It can’t read variables or constants. It only reads strings.
True but it does not matter as you can still can create a POT without knowing the text domain. I have made a POT with Poedit and makepot.php while having a variable for a text domain.
Mark mentions at the bottom of the post:
Well, it won’t break your plugin, but it could make it harder to be used with automated translation tools.
From the comments:
…this will work when doing once-off manual generation. But if you want to, say, automate the generation across, say, the entire WordPress.org plugin repository, you’re going to need to know the text domain programmatically.
I don’t agree. Makepot.php from WordPress tools uses the folder structure to build the pot. It does not care what text domain that is being used or if even a text domain is being used. WordPress has been creating new POT files for every version using makepot.php and WordPress core does not have any text domain. If I had to create a pot file for every plugin on WordPress.org plugin repository I would simply create a script that would run makepot.php on every plugin folder.
Otto has mentioned that a text domain should not use variable or constant because it would not work with the new language packs. When I asked him what code WordPress.org would use to generate the POT files, he said through the makepot.php code.
@grapplerulrich through the makepot.php code.
— Samuel Wood (Otto) (@Otto42) March 9, 2014
I do not see a reason why using the text domain to generate the POT files is better when doing mass generation. A couple issues I see arising when doing this is when a plugin/theme has multiple text domains or has an incorrect text domain. So not to cause cross contamination of strings the system would still need to search only the folder of the specific plugin which would also work with the current makepot.pot and text domains that are variables or constants
Conclusion
Even though I do not agree with Mark and Otto on their reasoning I would not recommend using variables and constants for the text domain. I do see that at times that constants and variables do make sense but all of the pros and cons do need to be well thought through. The reasons why I would recommend using a string for the text domain are:
- The text domain should constant and not changing.
- It takes the same amount of time to write a constant or variable for the text domain as for a string.
- Having strings across multiple classes can add extra code.
- You see straight away which plugin the text domain belongs to and reduces the risk of bugs.
- You can also use tools like grunt-checktextdomain to check if the text domains are all valid.
- The text domain should be used for future POT generation because a plugin might need multiple text domains. More on this in my next post.
Update 1: It is a must to use a string for the text domain if you want to support language packs when hosting your plugin/theme on the WordPress.org responsitory.
The correct answer here is that the textdomain must be a constant and it must be the slug of the theme or plugin.
The reason for this is because of Language Packs. As we implement them on WordPress.org, and separate the translation files from the plugins/themes themselves, then we need to have these be both sane and easily discoverable. If you have the text domain be a variable, or be something other than the slug, then there is no way to guarantee that the WordPress.org API will be able to send you the correct translation files.
Yes, technically you can make the text-domain any thing you please. It doesn’t matter from a code standpoint. Where it matters is from an organizational and new development standpoint. We’re trying to simplify languages all around. You have no good reason to use anything other than a string constant for textdomain. It doesn’t help you in any way to use a variable, or a define. It gives you no benefits whatsoever.
Please, just follow the advice as given. Make everybody’s life easier.
Please can you elaborate how this will work? I am just unable to get my head around how/why the whole system relies on the text domain. I have spent a lot of time trying to understand it and think of different possibilities.