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
