Partial pot-update: trivial changes only

[stevecotton]

These are typo-fixes and minor grammar improvements to the English text,
which don't change the meaning of the text and therefore shouldn't set
the fuzzy flags on their respective translations.

This is a hand-edited subset of the changes that a full pot-update would make.
The plan once this is reviewed is to update the .po files with the changes in
these .pot files, but to filter out any added fuzzy flags when commiting them
to Git. A normal pot-update can then be run, which will add fuzzy flags for the
string changes which weren't included in this PR.

What comes after this

The intended followup to this is in https://github.com/stevecotton/wesnoth/commits/dry_run_fuzzyless_po_update_1_16 .

The SConstruct files are set up so that rules for building .po files are only
added if pot-update, update-po or update-po4a is given on the command
line; also update-po only builds files whose language is additionally given
on the command line, for example scons update-po de. The command line to
trigger this without triggering an update of the .pot files too is thus:

scons update-po `cat po/LINGUAS`

Don't commit all the changes, instead avoid adding the fuzzy flags, by using
add -e and filtering out all lines that are +#, fuzzy or that begin +#| .
Warning: this drops you into Git's editor, probably a vi-based one.

git add -e

One translation should still have the fuzzy flags - en_GB is likely to have
the same typos and grammar mistakes as en_US.

git add po/*/en_GB.po

[stevecotton]

Using pofix was suggested in the forum thread, but it doesn't seem capable of the task.

One known issue is illustrated with the line that I'm commenting on here. Pofix, as it currently exists, works on a line-by-line basis, so using Pofix for this one would be three lines with a high probability of false positives on "them.", and an absolute dependence on the translators' tools' word-wrap settings.

Yes, it could be adapted to fix that specific issue, which would reduce the number of strings that need to be added to it to around 120 for this release alone. My gut feeling is that, if I try to do it with Pofix, I'm going encounter more issues; so my question to anyone suggesting continuing with that tool is to ask "have you thought through the problems, rather than just saying that we already have a tool?".

[ivanovic]

If pofix.py handles the stuff for about 90% of the cases that is already a huge win especially since it works around any stupidity / old files on the translators side. And yes, it will not be a 100% solution but better than trying to fix things manually and after getting the next update seeing that it was a moot try.

[stevecotton]

What would make it a moot try? Is it stuff that would be helpful to consider even when using pofix?

[soliton-]

(I may be missing something but it looks like you would rewrite "evaded them." to "them." not the other way around.)

Certainly pofix is not perfect and can surely be made more robust or even a new tool could be made to do a better job. It just was enough so far that nobody bothered. I wouldn't expect big problems after 10 years of use but certainly hundreds of string changes in a stable version were not done before (and is the real issue here).

I think with "moot try" Ivanovic means changes done by hand (or just once anyway) that will be overwritten the next time someone sends in a translation update based on old po files.

[ivanovic]

Why not just use utils/pofix.py?

Usual approach:

1. Add string change to original files
2. Add change to pofix.py (as small part as "unique"! beware of linebreaks in po files! keep in mind that it does apply the changes to all files, not just the ones listed as "pot files" in there...)
3. Apply change to all po and pot files using pofix by running pofix with the pot files and po files as parameter
4. Run a pot-update and check if you created any fuzzy strings (if everything went right: you did not)

This helps especially since translators can continue with their old files and they will magically be updated when they send them in without adding fuzzy strings for grammar and typo fixes.

[stevecotton]

Run a pot-update and check if you created any fuzzy strings (if everything went right: you did not)

These instructions do not seem to have been checked against a real pot-update, because if they had been then there would have been more info about the fuzzies that are expected, both from the trivial changes that couldn't be pofixed and the non-trivial changes. I still get the gut feeling that, if I work on adding most of these changes to pofix, more issues are going to arise afterwards.

[soliton-]

Run a pot-update and check if you created any fuzzy strings (if everything went right: you did not)

These instructions do not seem to have been checked against a real pot-update, because if they had been then there would have been more info about the fuzzies that are expected, both from the trivial changes that couldn't be pofixed and the non-trivial changes.

Seems pretty clear to me that Ivanovic is not talking about fuzzy strings you expect at all. It's about the strings added to pofix. The point is to check if pofix worked as intended.

[stevecotton]

Seems pretty clear to me that Ivanovic is not talking about fuzzy strings you expect at all.

Given steps 1 and 2, I think Ivanovic is talking about a change such as #4868 (46d8f2d), where 1 line was changed in a WML file and in the same commit 1 pair was added to pofix.

Why not just use utils/pofix.py?
...
This helps especially since translators can continue with their old files and they will magically be updated when they send them in without adding fuzzy strings for grammar and typo fixes.

The first part is the workflow needed to get these strings into pofix, which I've done for #6638. To find out where the word-wrapping happens, I believe the simplest workflow is

1. Run pot-update and take a diff.
2. Hand-edit the diff down to the changes that are eligible for pofixing.
3. Continue to hand-edit the diff down to the changes that are unambiguous when viewed as single lines, and cut words off the start and end to accommodate possible word-wrap changes
4. Pair them up and convert those pairs to the format for the script.

The commit that's forming this PR isn't some additional work, it's intermediate file created at the end of step 2. Getting here is less effort, fixes more strings (because I didn't have to filter out the ones that couldn't be single lines), and is less likely to accidentally match the another string (which might be added later, but will still be active in the pofix tool).

especially since [pofix] works around any stupidity / old files on the translators side

Old files might happen, but it'll affect individual files.

[stevecotton]

I'm not going to merge this, explanation is in https://r.wesnoth.org/p673256 .

@CelticMinstrel has added some useful comments in #6638 for anyone using this as a reference list while translating.