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
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.