Text Domain Shouldn't be a Variable

[devinsays]

Variables for the text domain seems like a great idea, but it causes issues.

See: https://twitter.com/nacin/status/194635610785447938

From Otto: "that text domain must be a plain string. Not a variable. Not a define."
http://ottopress.com/2012/internationalization-youre-probably-doing-it-wrong/

And Mark Jaquith:
http://markjaquith.wordpress.com/2011/10/06/translating-wordpress-plugins-and-themes-dont-get-clever/

Let me know if you'd like a pull request for this.

[danielantunes]

Really! I didn't attempt it.

[grappler]

Hi Devin,

I am not completely convinced.

The original idea came from Mark. From the blog post.

GNU gettext also needs to parse out the strings in order to provide your blank translation file to your translators.

The way I have experienced it, it is not necessary. When I generate a pot file either with poedit or makepot.php I do not need to enter the Text Domain. The pot file generation is constrained to the folders. WooCommerce has two pot files one for back end text and one front end. This is done by restricting the pot generation to certain folders.

The makepot file.
https://github.com/woothemes/woocommerce/blob/master/i18n/makepot/makepot.php#L68-L81
As you can see here there is only one text domain.
https://github.com/woothemes/woocommerce/blob/master/woocommerce.php#L12
https://github.com/woothemes/woocommerce/blob/master/woocommerce.php#L569-L593

The text domain is then defined by the plugin and at the same time the location of the .mo file.

This is a snippet from 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. And trust me, you don’t want to be manually managing your translation files… we have a better solution coming.

This post was written on October 6, 2011 just under two years ago. At the moment only the plugins have a method to generate a pot file on WordPress.org, themes do not.

I have never studied programming so I don't know much about future proofing software. One question that that I ask is "Do you really support something that does not exist and there is no concrete plan to build it."

If there was to be an issue for such an automated process the boilerplate could easily be updated just like if there was a new feature in the core that plugins could use.

Wysija have an automated solution for packing the plugin with the latest translations.
https://github.com/Wysija/packzip

And they also use variables for their textdomain.
http://plugins.svn.wordpress.org/wysija-newsletters/tags/2.5.1/core/base.php
search for transstring

Variables for the text domain seems like a great idea, but it causes issues.

My question to your statement: "Please show me an example of code where an issue occurs?"

Edit: I would also like to add the link of those who are also not convinced.
scribu: http://markjaquith.wordpress.com/2011/10/06/translating-wordpress-plugins-and-themes-dont-get-clever/#comment-99787
Nikolay Bachiyski: http://markjaquith.wordpress.com/2011/10/06/translating-wordpress-plugins-and-themes-dont-get-clever/#comment-99789

[Japh]

+1 on this ticket.

If Otto, Nacin, and Mark all say a particular way to do it, I'm inclined to follow that. They have good reasons for suggesting we build plugins and themes this way too. (all linked above)

[devinsays]

You could be right @grappler. I was reposting the advice I've read from Otto, Mark, and Nacin. I didn't realize there was a contrary opinion from Scribu, Nickolay and Tadlock.

If makepot.php and poedit can handle the translations fine with a variable- it seems like all the bases are covered at the moment. If a new programmatic translation tools come out, I agree, it would be easy to update.

But since this is intended to be a boilerplate of best practices, it's probably worth having the discussion. If translation tools come out that will cause everyone to need to update their plugins, is it worth the time/effort saved by having a variable textdomain?

[tommcfarlin]

This has actually been a point of discussion very early on in the first iteration of the boilerplate. As we all know, it boils down to:

• Is it okay to use a variable as the text domain
• Should we use a string for the text domain

Because different people have differing opinions on this and different tools manage this stuff differently, perhaps the best thing to do is provide a level of documentation about this based on YMMV on the tool that you use?

[tommcfarlin]

If makepot.php and poedit can handle the translations fine with a variable- it seems like all the bases are covered at the moment. If a new programmatic translation tools come out, I agree, it would be easy to update.

For now, I think we're going to move forward with using a variable for the plugin domain.

If someone raises an issue about or has the inability to translate the strings with his/her tools, then we can update this.

I can also update the README and the documentation so that users know what tools we recommend they use for translation.