Display warnings for invalid text domains about i18n-command

[swissspidy]

I say not scanning because is very fast and there isn't a verbose parameter to see what file is scanning to see if is working well.

Listing every file would result in a looong list :-) However, you should see some additional information when using the --debug flag. For example:

Debug (make-pot): Destination: /path/to/glossary-by-codeat//languages/glossary-by-codeat.pot (0.086s)
Debug: Could not parse file admin/includes/CMB2/js/jquery-ui-timepicker-addon.min.js: Unterminated string (line 5, column 0) (4.927s)

That means you should probably add --exclude=admin/includes/CMB2/

(note to self: we should fix that // in the output there).

---

The actual problem with your plugin is this:

You're using GT_TEXTDOMAIN as a text domain and not a normal string. This doesn't work.

Citing the plugin developer documentation available at https://developer.wordpress.org/plugins/internationalization/how-to-internationalize-your-plugin/:

Do not use variable names or constants for the text domain portion of a gettext function. Do not do this as a shortcut: __( 'Translate me.' , $text_domain );

So instead of __( 'Translate me.' , GT_TEXTDOMAIN ); you should always use __( 'Translate me.' , 'glossary-by-codeat' );

Why? Tools like this command and also WordPress.org do not execute PHP. They only parse it. They do not know what the value of GT_TEXTDOMAIN is.

You define Text Domain: glossary-by-codeat. That's what you should use in your code as well.

GT_TEXTDOMAIN is not much shorter than glossary-by-codeat. There's no real benefit in using that.

If you want to ensure you're always using the correct the same string, I'd use PHPCS to check this. See https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/wiki/Customizable-sniff-properties#internationalization-setting-your-text-domain

tl;dr: If you want to get all strings in your plugin, don't use use GT_TEXTDOMAIN, or alternatively run this:

wp i18n make-pot glossary-by-codeat --exclude=admin/includes/CMB2 --ignore-domain

[Mte90]

Thanks for the info.
For the constants is a way to organize better the code and avoid a lot of plain stuff but I can remove it without problems and replace with the slug.

For exclude stuff yes I already know just iIwas wondering why wasn't extracting nothing.
Maybe add a check to help for this cases because I am not the only one doing that that where there aren't strings there is an error?

[swissspidy]

Maybe add a check to help for this cases because I am not the only one doing that that where there aren't strings there is an error?

Interesting thought!

We already print warnings about wrong translator comments (see #33), so this could build upon that.

We just have to decide how to best implement this. I don't have a huge problem with just failing silently right now, as constants shouldn't be used. But I see how a small warning can be helpful.

Right now, the library we use for extracting strings from PHP ignores all constants, and the text domain is null in this case.

(If you'd use __( 'Translate me' ), the array key won't be set at all. When using a constant, it's set to null)

For us, this could be an indicator that a constant was used and that we should print a warning for that string.

Otherwise we'd need to fork the existing class and extend the relevant parts with our own logic.

Interestingly, the library has an option to say "if you see constant X, replace it with string Y". So __( 'Translate me.' , GT_TEXTDOMAIN ); will be handled as if it were __( 'Translate me.' , 'glossary-by-codeat' );.

However, I don't think we should expose that feature. --ignore-domain is good enough. Also, we don't have this in the JS extractor.

[Mte90]

Agree maybe add only a check that see if there are constants or the pot file is empty can be the most easiest solution.

[GaryJones]

• https://github.com/stephenharris/grunt-checktextdomain
• https://github.com/felixzapata/gulp-checktextdomain

(Sadly, neither have their logic extracted into a basic node package)

These packages check for invalid and missing text domains, so there is prior art here in terms of useful behaviour.

[swissspidy]

WPCS now has a utility to fix text domains: https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/releases/tag/1.2.0

[javorszky]

The utility sniff in WPCS actively changes files from what I can read.

New WordPress.Utils.I18nTextDomainFixer sniff which can compehensively replace/add text-domains in a plugin or theme.

I would also love some functionality that gives me a list of instances where a domain is either missing, or is different to the one configured in the plugin header. I would want to manually review / change / ignore those, in case I'm using a library, or have another, genuine reason for using a different domain.

For now the grunt-checktextdomain remains, but would love to replace that with something like wp i18n checktextdomain.

If you're open for that to be included, I can extract the js code and implement that subcommand.

[swissspidy]

I would also love some functionality that gives me a list of instances where a domain is either missing, or is different to the one configured in the plugin header. I would want to manually review / change / ignore those, in case I'm using a library, or have another, genuine reason for using a different domain.

That's what WPCS does. It gives you a list and allows you to fix the issues automatically if you want to.

Feel free to look into how we could do these checks in this command instead. It would probably need to be written in PHP though, not JavaScript.

[javorszky]

It would probably need to be written in PHP though, not JavaScript.

I can tackle that part. :)

I'll check out the WPCS bit first. Thanks!

[swissspidy]

Closing for now as I think this is better handled by using tools like PHPCS and ESLint.