Object dump import patch cleaning tool

[AaronVanGeffen]

The object string dumper and loader scripts introduced in #27 have greatly simplified the workflow for object translations. However, the barrier of entry for use by most translators is still too big. Recent work by @tupaschoal has been working towards making an automated workflow, bridging the Objects and Localisation repositories. However, the holdup has been that Python's method of serialising JSON differs in output from what is already present (#93). Rather than writing our own encoder, I propose the following solution.

I have written a simple Python class, PatchCleaner, that uses the unidiff package to disregard changes that arise in patches due to the formatting changes mentioned. In short, this means it only picks up the changes we need. I have added a heuristic to pick up on cases where a trailing comma was added to a line with an irrelevant language. This needs some field testing, but in my brief testing it has worked well.

The workflow is still suboptimal -- and the script doesn't take language and patch file as its arguments yet:

./language_dump.py -l nl-NL -d nl-NL_dump.json
$EDITOR nl-NL_dump.json
./language_load.py -l nl-NL -i nl-NL_dump.json
git diff > patch.diff
git stash
./language_clean_patch.py | git apply    # no arguments yet, sorry
git commit -m 'Updated object strings for nl-NL'

Again, this removes any need for cherry-picking the diff manually. This cherry-picking gets particularly cumbersome for rides and large scenery objects. Indeed, with this script, this workflow can now be completely automated!

As an aside: personally, I like to order the dump files before working on translations. We can avoid complicating language_dump.py by using jq to this end:

jq 'to_entries | sort_by(.value."reference-name") | from_entries' \
    < nl-NL_dump.json \
    > nl-NL_dump.json

[tupaschoal]

This looks like a very good start, easy enough to follow the code and, from a quick glance, might actually do the trick. Nice job!

Some notes:

• I've added it to the project for proper tracking
• It doesn't seem hard at all to make this support target language, target file and input file

[tupaschoal]

Looks great to me

[tupaschoal]

In the future we should probably have all scripts source the languages from a single place

[AaronVanGeffen]

Yes, definitely. I was also thinking we should probably move the language*.py tools into a Python package of some sort. Another item for the to do list…