Hi, Dixit Justin B Rye, le 12/09/2015 : >Assuming I can get write access, how do I minimise the pain? I could >split the changes into: > > a) fixes for the English that shouldn't affect translations (e.g. > correcting Germanic uses of "respectively", objectless "allow", > etc.) > 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; > 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! > >But while I know a few basic svn commands (which is more than I'll ever >understand of git), it's not clear to me whether doing (a), (b), (c), >and (d) as successive commits would let translators benefit from them >being separate. The fuzzy strings will appear only after re-generating po & pot files. No need to do several commits. I think you can keep your original patches. >Would I need to learn how to do fancy stuff like >branches and merges? I don't think so. For orthographic changes, you could grep all the po-files and modify the original string, this would prevent the fuzzy to appear. Or manually unfuzzy some translations after re-generating. But if you feel uncomfortable with this, don't do it : translators are used to this. It's just a matter of Ctrl-U / Ctrl-Down ! Baptiste
Attachment:
pgp2LYN3SEBBD.pgp
Description: OpenPGP digital signature