Change Details

When writing the patch for T412421 I tested that I was doing something reasonably by running `export.sh` to produce an `en.json` file, and then running `generate.php` on the resulting en.json file as if it were a translation. Once T412421 is done, then the result of this process should, after filtering out cases where the "translation" is identical to the "proto-English" be identical to the builtin English translation as specified in the Phorge/Arcanist upstream. Any cases where it isn't are either bugs in my code (like T413529 - although that TODO dates all the way back to when Evan Priestley wrote the first version of rPHTR), errors in the upstream localization files, or non-canonical formatting in the upstream localization files which doesn't cause any harm but would be nice to fix. Ideally we should resolve all of these, and then write a test to make sure this roundtripping process continues to hold true.

When writing the patch for T412421 I tested that I was doing something reasonable by running `export.sh` to produce an `en.json` file, and then running `generate.php` on the resulting en.json file as if it were a translation. Once T412421 is done, then the result of this process should, after filtering out cases where the "translation" is identical to the "proto-English" be identical to the builtin English translation as specified in the Phorge/Arcanist upstream. Any cases where it isn't are either bugs in my code (like T413529 - although that TODO dates all the way back to when Evan Priestley wrote the first version of rPHTR), errors in the upstream localization files, or non-canonical formatting in the upstream localization files which doesn't cause any harm but would be nice to fix. Ideally we should resolve all of these, and then write a test to make sure this roundtripping process continues to hold true.

When writing the patch for T412421 I tested that I was doing something reasonablye by running `export.sh` to produce an `en.json` file, and then running `generate.php` on the resulting en.json file as if it were a translation. Once T412421 is done, then the result of this process should, after filtering out cases where the "translation" is identical to the "proto-English" be identical to the builtin English translation as specified in the Phorge/Arcanist upstream. Any cases where it isn't are either bugs in my code (like T413529 - although that TODO dates all the way back to when Evan Priestley wrote the first version of rPHTR), errors in the upstream localization files, or non-canonical formatting in the upstream localization files which doesn't cause any harm but would be nice to fix. Ideally we should resolve all of these, and then write a test to make sure this roundtripping process continues to hold true.