@nb Spacing fixed up.

Thank you for the contribution, @rmccue!

I am still thinking what would be the best way to enable/disable the plugin in different situations. See, for example #3 for another example of this problem.

Could you explain in what use case did you need to filter by domain?

Few notes about the code:

• It would be great if you don’t have to add the check_domain condition to each gettext function.
• Can we find more elegant method than a global?

Thank you for the contribution, @rmccue!

Thanks for the fantastic plugin! :)

I am still thinking what would be the best way to enable/disable the plugin in different situations. See, for example #3 for another example of this problem.

Yeah, I'm not too concerned about disabling on the fly. For me, it's a local development thing, so toggling one line in wp-config.php isn't a big issue.

Could you explain in what use case did you need to filter by domain?

Sure! When developing plugins, it helps to be able to visually check that you've included the correct domain in your translations. Pig Latin is great for finding untranslated strings, but not for checking that. It's really easy (and really common) to accidentally leave the domain out.

I also use Pig Latin to help visually check translation on projects with more than one text domain; for example, Happytables's dashboard has the domain dashboard, whereas the themes themselves have the domain frontend. Checking that these domains are correct is a hard job, since the code isn't always as separated as it should be.

• It would be great if you don’t have to add the check_domain condition to each gettext function.

I agree. The alternative is to pass it into translation2pig, which feels too deep in the stack to me. We could also refactor, but each function takes different parameters, so we can't necessarily do so.

• Can we find more elegant method than a global?

Alas, a global is the only way to get it to work with adding things into wp-config.php. Filters can't be added into the config easily. We could do it in a UI/option, but that's a lot of work for a fairly minor feature. :)

Pig Latin is great for finding untranslated strings, but not for checking that. It's really easy (and really common) to accidentally leave the domain out.

I agree. Though I not entirely agree that it should do that. In general add-textdomain.php is pretty good at this.

In your case, since one file has more than one domain using this tool might be tricky.

I don’t think we should include this change, because the majority of the users of the plugin won’t benefit from it.

However, I think it would be great if we add a filter, which will let you selectively disable the plugin – either based on domain, on an UI option, on the current environment (dev/translate/production), or on anything you’d like. Pull requests are, again, welcome :-)

FYI our team is often using the piglatin plugin to verify that we're internationalizing our plugins. But it of course doesn't catch problems when we accidentally leave off our textdomain from the i18n method calls (eg, when we do _e( 'some phrase' ); instead of _e( 'some_phrase', 'my_text_domain');).
So just an upvote for this pull request