Re: proofreading the installation-guide
Hello,
Getting back to this discussion, sorry it took so long for finding out
the time to do it.
Justin B Rye, on Sat 12 Sep 2015 15:23:44 +0100, wrote:
> Assuming I can get write access,
That shouldn't be a problem, just tell us your alioth id.
(I'm not an admin there, so somebody else will have to do the addition)
> how do I minimise the pain? I could split the changes into:
As mentioned in the thread, splitting will not help translators, so you
can split any way makes sense to you.
You can however help minimizing the pain for translator by fixing .po
files as appropriate (and splitting commits may be useful for yourself).
> a) fixes for the English that shouldn't affect translations (e.g.
> correcting Germanic uses of "respectively", objectless "allow",
> etc.)
I.e. changing the english text, which will make the translations fuzzy
for no reason. In that case, you can either:
- fix the english text
- fix the english version in the corresponding .po files *exactly* the
same way, so that po update will be a no-op
or
- fix the english text
- update the translations (see doc/translations_po.txt, "Updating your
translation")
- drop the "fuzzy" keyword and outdated text from the modified entries.
The latter method will update the english version exactly the same way
automatically. Depending on the state of the translation, it may also
fuzzy other things, which is to be expected and commited. Christian,
perhaps an experimented translator could do a po update commit, so that
any po update that Justin before his changes is a no-op, and thus po
updates after his changes will only include his changes? Also, is there
perhaps an msg call to do the no-op unfuzzying in an easy way?
> b) fixes that affect everybody in a clearly parallel fashion, such as
> correcting "dhcp" to "DHCP";
> c) similarly, changes to the docbook, like introducing <package> in
> place of <classname> for packages;
In these cases (language-independent changes), the translations need
to be updated. Ideally you'd just do the change in english, as well as
in all translations (and in the english counterpart in the case of po
files), so that again translators won't have further work to do.
> d) (optional extra) content updates - for instance Appendix C3 claims
> "an older home machine might have 32MB of RAM and a 1.7GB IDE
> drive"... wow, even the first PC I cobbled together from junk
> parts in the nineties was significantly better than that!
In that case, it may be hard to fix the translations. For those where it
is easy (fixing numbers, which AIUI are in all languages written with
arabic numbers), this is the same as b) and c). For other cases, you can
commit your change. Christian, do you think he should update po files
and commit the fuzzied result, so that further po updating will be
no-ops?
> But while I know a few basic svn commands
Translation management is actually a po issue, not an svn issue :)
Thanks,
Samuel
Reply to: