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.

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.

2 comments on “Why a string text domain is not a must”

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.

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.

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.