1) The add-textdomain.php file is not in the WP Core repository, so posting a patch for it on this trac is not appropriate.

As the i18n trac has never been used, I don't see anything wrong with having that on the core trac.

2) Patches that only fix coding standards violations are frowned upon, since they cause code churn, without much to show for it.

The changes proposed is in a script which alters existing files, the result of the script does not match the WordPress.org coding standards, as such, It's not just adding a missing space to an existing script.

I like the idea, and I tried it, but it has too many knock-on effects that cause new violations on otherwise well-formatted code like empty array declarations:

$urls = array( );

and multi-line function calls:

$body = wp_remote_retrieve_body(
wp_remote_get(

We could add conditionals, but that starts to add too much noise to the code. This script's purpose is just to add text domains - but it shouldn't introduce new coding violations so that a dev who took their time to clean the code before adding text domains doesn't have more work to do.

21616.2.diff​ is a first pass at this, and is open to suggestions on all aspects.

To check my change was working correctly, I needed some tests. To be able to test sensibly, I neede to be able to just process a string of PHP code, and not individual files, so I needed some refactoring. If this means this diff should go on to a new ticket, which can this fix this ticket, let me know.

The general approach was to make use of the native counter ($index) when looping through the array of tokens, so we can check if the previous token before the closing ) was an instance of whitespace (using coding standards). At the moment, I add a single space to the current token, and strip whatever whitespace was on the end of the previously processed tokens. There's a case where the previous whitespace might have been a line break, not a single space, so this bit could be improved.

With the check of the previous token possible, it becomes a matter of string manipulation to get the desired output.

One thing I did need to change, was to hold on echoing until the file had been completely processed (so that I could remove a previous token during the processing) instead of echo-ing one token at a time. I'm not sure if this will cause any BC behaviour changes.

The new functions are documented, but given a wider ticket scope, I'd refactor process_tokens() even further (and look at making it a protected method).