Re: proofreading the installation-guide
Baptiste Jammet wrote:
>> At this stage what I'd *like* to be able to do is submit half a dozen
>> different patches for different types of recurring problem - one to
>> tidy up the <command>s and <package>s, one to fix up the outbreaks of
>> un-English grammar, one to correct the capitalisation of titles, and
>> so on. Unfortunately each of these patches would trample on all the
>> others, so it would be pointless unless I could be confident that each
>> one would be applied promptly while I was generating the next one, and
>> that doesn't look likely.
[...]
>> Has anyone got any useful advice?
>
> Ask for write access on alioth ?
> I (as a translator) am a little afraid about all the fuzzy strings we
> will get. And need to discover the very subtle variations. So I don't
> want to wait the end of the release cycle !
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. Would I need to learn how to do fancy stuff like
branches and merges?
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: