Plugin translation – do not use variable names for the text domain

$text_domain is a php variable. Your text domain should look like your theme or plugin name.

For example,

Theme name: “My Theme”
text domain: “my-theme”

Same goes for plugins.

Yeah, I know $text_domain is variable. It was a quote from WP documentation about translation.
I’m asking about constants.

It works as long as the constant is defined as a value that is in the translation files. Same goes for variables too. It doesn’t make it a good idea.

How is anyone but you supposed to know what the constant is defined as? How can someone correctly translate your plugin if all they have is the constant name?

What if someone hacks your plugin and defines a different value for the constant? Why would they think that would affect the translations? If someone were to alter the string in a __() function they should expect it to affect translations. Not so for constants.

What can go wrong? The constant will not be translated. Hardly the end of the world, but not good. Stick with fixed strings please ??

In case it wasn’t clear, these are all rhetorical questions, you have no obligation to answer them unless you want to discuss further.

Yeah, well “my-theme” IS a constant. So I don’t understand the point of your original query.

From the PHP manual:

The name of a constant follows the same rules as any label in PHP. A valid constant name starts with a letter or underscore, followed by any number of letters, numbers, or underscores. As a regular expression, it would be expressed thusly: [a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*

https://php.net/manual/en/language.constants.php

Guys, I think we don’t understand each other.

I mean something like this:

namespace Vendor\Plugin\PluginName;
define( __NAMESPACE__ . '\TEXT_DOMAIN', 'plugin-name' );
_e( 'Some text', TEXT_DOMAIN );

Is there something wrong with that?

Yes. Per the Codex:

If you’re translating a plugin or a theme, you’ll need to use a text domain to denote all text belonging to that plugin. This increases portability and plays better with already existing WordPress tools. The text domain must match the “slug” of the plugin.

The text domain is a unique identifier, which makes sure WordPress can distinguish between all loaded translations. If your plugin is a single file called my-plugin.php or it is contained in a folder called my-plugin the domain name should be my-plugin. The text domain name must use dashes and not underscores.

https://codex.www.ads-software.com/I18n_for_WordPress_Developers#Text_Domains

Slugs are lower-case. So use a lower-case text-domain.

This is not a limitation of WordPress, btw. WordPress uses gettext for translation.

I see what you mean now. I totally misconstrued what you were on about due to my apparent inability to comprehend plain English. Sorry.

As far as PHP is concerned it wouldn’t matter. The problem is potentially how the .pot files are generated. There’s a few different tools to do this, and I don’t know how any of them work internally, but it’s likely they parse your code without interpreting arguments, so by using a constant, the defined value will not be picked up by the tool. These tools assume the domain will be a simple string so you need to provide it like that.

If the tool you use correctly picks up only the translation strings of your domain when you use constants, I suppose it’s not a problem for you, but the portability of your code is still diminished and the use of constants is still not advisable.

What functionality are you gaining by using constants that a simple search and replace would not provide?

kjodle: I think this example fully supports WordPress guidelines. plugin-name is lowercase, doesn’t use underscore and meets name of the plugin (implicitly).

bcworkz – thank you very much, I use poedit for Windows, and it takes every single gettext function, even if it is without text domain. Of course I take care to use TEXT_DOMAIN constants everywhere.

Thank you very much, guys.

Hi all, I know it has been 6 months since the last entry in this thread, but I have a simple question, if anyone has had experience with WPML. Our custom theme uses a constant in place of the text_domain, and I have been reading all over the place that this is a bad practice. We have been having all kinds of issues in the past couple of years with our theme and WPML, especially when updating that plugin. Could this actually be related to using a constant instead of a literal string, as our text_domain? Thanks.

As far as WP operating correctly, a constant as text domain should be fine. The problem with constants comes up when generating .pot translation files. If your .pot files have all the appropriate strings in them, using a constant is apparently not a problem for however those files were generated.

It still sounds like there is an issue with your theme, but I doubt it’s related to a constant as text domain. If you’d still like to rule out constants as a problem, you could make a copy of your theme where all text domain constants are replaced by a string literal. It’s a little tedious to search/replace all theme PHP files, but it’s straight forward enough.

I expect it will not make any difference with your problems. I think this is something that needs to be addressed by whomever customized your theme. I know that is not always possible, which is unfortunate.

FYI, in these forums we ask people to start their own topic instead of tagging on to other’s. Some the reasons for this go away on old threads, but if nothing else it makes the forum stats more accurate.