Check for proper usage of translation functions

[westonruter]

I had read that variables were discouraged from being used in the i18n functions. I assumed this was just to discourage them from being changed. Well, it's actually because some automated i18n tools will tokenize the PHP files to extract the textdomain from PHP without actually evaluating the file. See @markjaquith's blog post Translating WordPress Plugins and Themes: Don’t Get Clever.

So a sniff should be written which makes sure that translation functions have a text domain which is a literal string. The sniff should also ensure that variables are not being used for the text to be translated, or inside of the text to be translated.

[GaryJones]

Another article covering the same topic: http://ottopress.com/2012/internationalization-youre-probably-doing-it-wrong/

[westonruter]

I think this was accidentally closed.

[GaryJones]

Strings that span multiple lines may get highlighted as false positive e.g.:

<?php esc_html_e( 'Long line
of text', 'foo' ); ?>

Both give "The $text arg must be a single string literal, not 'Long line of text'."

[westonruter]

@GaryJones interesting. PHP tokenizes that single string literal into two separate T_CONSTANT_ENCAPSED_STRING tokens with content 'Long line and of text'

[westonruter]

It seems we need to merge two tokens of type T_CONSTANT_ENCAPSED_STRING that appear next to each other in $argument_tokens.

[GaryJones]

I guess that merging would need to be done for context args and so on too, not just the string being internationalized.

<?php _x( 'Post', 'Holds the
fence up', 'text-domain' ); ?>

[westonruter]

@GaryJones how's #545?

[GaryJones]

@westonruter #545 tested on my real and made-up code, and the error no longer appears. 👍