CHILD_TEXT_DOMAIN constant prevents strings being detected

[nickcernis]

Current behaviour

The use of the CHILD_TEXT_DOMAIN constant prevents detection of strings by tools such as Loco Translate.

Some translation tools statically analyse files for translation, so CHILD_TEXT_DOMAIN is never parsed by PHP to become 'developers'.

• https://markjaquith.wordpress.com/2011/10/06/translating-wordpress-plugins-and-themes-dont-get-clever/
• http://ottopress.com/2012/internationalization-youre-probably-doing-it-wrong/
• https://developer.wordpress.org/plugins/internationalization/how-to-internationalize-your-plugin/#text-domains (note red “do not use variable names” warning)

Loco Translate detects only four strings in the theme when trying to create a template file, for example (the ones in stylesheet header) – all of the strings passed to __() are missing:

Expected behaviour

CHILD_TEXT_DOMAIN is replaced with a string literal such as 'developers', so that translation tools can detect all strings for translation.

If I find , CHILD_TEXT_DOMAIN and replace with , 'developers', Loco Translate can then find the strings when building the .pot file:

To reproduce

1. Install and activate Loco Translate.

2. Create a blank folder named 'languages' in the 'developers' directory. (The theme should probably include this by default, perhaps with a blank index.php inside so it's saved by git?)

3. Visit Loco Translate → Themes → Developers → Create Template.

4. Click the “Create template” button:

   

The developers.pot template file will be created in the theme's language directory. You can view it directly and count the strings, or see how many strings were detected by clicking “Edit Template” next to the Developers theme in Loco Translate:

11 strings should be found, but you'll only see 4 if the text domain constant is used.

[hellofromtonya]

Thank you, Nick. You are correct. If you want to automatically generate the theme's .pot using one of the existing tools on the market, then using a variable or constant won't work. Why? Because these tools use gettext and do not run PHP. It's a UNIX util.

However, I'm teaching a different way of building themes and plugins to be both modular and configurable. That means we need a different way to generate the .pot file. Once we have that file, then the translators can do their job to present the interface and generate the .po files.

New Approach

With this new ModularConfig approach, we will build the .pot for the translators to use.

There's a flaw in the architectural methodology of making developers have to duplicate code over and over again just for building the .pot file. With Modular approach, the idea is to build your code such that you greatly minimize or eliminate having to edit the code within that module. Rather, you pass a configuration file to it for the specific implementation(s).

I'll be teaching and covering that within the next Theme Development A-Z course and am teaching it now in the Plugin Development A-Z course.

I know it's a departure and different. But I'm working to teach folks how to save themselves a lot of time and costs to flourish and grow their careers and businesses.

Notes are needed

I will write an article about it and make a note in the labs for to ensure that folks know that you cannot build a .pot file automatically with the current tools like Poedit.

Thank you for pointing out that I need to make this clear for folks.

Cheers,
Tonya

[nickcernis]

I really like your config-based approach, and I can see how generating the pot file with gulp or similar might work around the general advice in the WordPress community not to use a variable/constant.

For what it's worth, Poedit found all strings using the “Translate WordPress theme” option even with the constants in place; it was just Loco that struggled to do the same.

[hellofromtonya]

Thanks, Nick. That's awesome you ran the test with Poedit for me. Thank you so much! I really appreciate you taking the time and digging into it.

Yes, I was going to teach folks both Poedit and Gulp task to build the .pot file. I'll then build a module and hands-on lab to teach folks how to do it and shrink down their code for reusability.

Cheers and thanks again! :)