Re: proofreading the installation-guide
Hello, Justin B Rye, on Thu 04 Feb 2016 09:48:05 +, wrote: > It's looking as though the only way this is going to be doable is if > I split it up into multiple runs with different methodologies: > 1) things like converting → and dhcp → DHCP > which ought to be introduced across the whole manual in one go > but are relatively easy to apply to the translations; > 2) semantics-preserving grammar-fixes etc. that I can introduce in > stages, chapter by chapter; > 3) other things, if I live long enough. That's the idea, yes. > But I'm rather confused by the way instead of per-chapter .po files > (like "trunk/manual/po/fr/post-install.po") some languages have > complete translated copies of the individual .xml files (such as > "trunk/manual/de/post-install/post-install.xml"). What's the > procedure for those? There is no procedure: the translators have to cope with what is happening. You can do 1) on them easily, 2) does not matter, and for 3) translators will have to perform the changes. It'll however be useful if you write in the changelog whether this is a 1), 2) or 3), i.e. whether they should just ack the change without more work, or not care about the change in the english version, or actually look at the change and perform corresponding changes. > >> 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? > > > > Yes, that's the better way, imho. > > Just to be sure: when people talk about "updating" a .po file, they > don't mean the stage of manually editing it to be up-to-date, they > mean running a particular .po-update script that handles the > importing of new strings, right? Yes. "Commit the fuzzied result" means commiting as they are left by the po-update script. Samuel
Re: proofreading the installation-guide
Christian PERRIER wrote:
> Quoting Samuel Thibault (sthiba...@debian.org):
> There is ("msgattrib --clear-fuzzy") but this will un fuzzy also what
> was fuzzy before, which is not intended.
>
> The real safe way is the first method:
>> - 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
>
> That may be painful to do if the changes in English text are
> complicated and end up being splitted on more than one line in the PO
> files (which will make a very painful "sed" operation to do)
They're frequently going to be that sort of complicated reshuffle, and
a long way beyond anything I'd trust to sed.
It's looking as though the only way this is going to be doable is if
I split it up into multiple runs with different methodologies:
1) things like converting → and dhcp → DHCP
which ought to be introduced across the whole manual in one go
but are relatively easy to apply to the translations;
2) semantics-preserving grammar-fixes etc. that I can introduce in
stages, chapter by chapter;
3) other things, if I live long enough.
But I'm rather confused by the way instead of per-chapter .po files
(like "trunk/manual/po/fr/post-install.po") some languages have
complete translated copies of the individual .xml files (such as
"trunk/manual/de/post-install/post-install.xml"). What's the
procedure for those?
[...]
>> 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?
>
> Yes, that's the better way, imho.
Just to be sure: when people talk about "updating" a .po file, they
don't mean the stage of manually editing it to be up-to-date, they
mean running a particular .po-update script that handles the
importing of new strings, right?
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
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 in > place of 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
Re: proofreading the installation-guide
Quoting Samuel Thibault (sthiba...@debian.org):
> 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?
There is ("msgattrib --clear-fuzzy") but this will un fuzzy also what
was fuzzy before, which is not intended.
The real safe way is the first method:
> - 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
That may be painful to do if the changes in English text are
complicated and end up being splitted on more than one line in the PO
files (which will make a very painful "sed" operation to do)
> > b) fixes that affect everybody in a clearly parallel fashion, such as
> > correcting "dhcp" to "DHCP";
> > c) similarly, changes to the docbook, like introducing in
> > place of 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?
Yes, that's the better way, imho.
signature.asc
Description: PGP signature
Re: proofreading the installation-guide
Baptiste Jammet wrote: > Dixit Justin B Rye: >> Assuming I can get write access, how do I minimise the pain? [...] >> 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. I don't have patches yet. This conversation is about whether I should start creating patches split by edit-type or by XML file. >> 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 ! It sounds to me as if dividing my patches by type won't benefit anybody unless I first turn my desktop into an unstable development machine so that I can run chunks of the package's build process and learn to fiddle with generated gettext files in the appropriate way. If that's the case, I might as well fall back on the achievable option of submitting patches split up by file. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
Re: proofreading the installation-guide
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 in >place of 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 pgplGrhNoZxII.pgp Description: OpenPGP digital signature
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 s and 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 in place of 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
Re: proofreading the installation-guide
Hi Justin, Dixit Justin B Rye, le 25/08/2015 : >Okay, these have become bugreports: > #794936 - claims it will use "CD-ROM" as cover-term then doesn't > #795944 - should call a RAID a RAID > #796662 - rethinking priorities > >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 s and 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. >Plan B is to proceed by dividing the sweep up into one generic >proofreading bugreport per XML file, or perhaps more manageably one >for every dozen or so XML files (which is still verging on being a >Mass Bug Filing). > >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 ! Your plan A is OK for me. Moreover, there were no objections on your wordings since several weeks, so (in my opinion) please go ahead. Thanks for proofreading the installation-guide. Baptiste pgpQouus_PLaW.pgp Description: OpenPGP digital signature
Re: proofreading the installation-guide
Justin B Rye wrote: First, the deep-rooted termininological issues that I'd prefer to have sane answers for before I start fiddling with details: * why is there so little mention of BD media? [...] * D-I seems to have standardised on the term MD devices [...] * is there any hope of getting rid of the crazy backwards jargon of low priority installs? [...] (Perhaps I should make these three separate bugreports?) Okay, these have become bugreports: #794936 - claims it will use CD-ROM as cover-term then doesn't #795944 - should call a RAID a RAID #796662 - rethinking priorities 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 commands and packages, 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. Plan B is to proceed by dividing the sweep up into one generic proofreading bugreport per XML file, or perhaps more manageably one for every dozen or so XML files (which is still verging on being a Mass Bug Filing). Has anyone got any useful advice? -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
Re: proofreading the installation-guide
Hi, Justin B Rye justin.byam@gmail.com wrote: So all cases of releasename-cap; in the English text are mistakes. Really if it's only for use in German we should have called it Veroeffentlichungsname;! No, it's not just for German! It gives _all_ translators the possibility, to spell the releasename as they want in their language. I just used German and how it's used in German, to explain the principle. Not much translators use that possibility though. Such as? There *aren't* any other languages that have mandatory initial capitalisation on nouns (and even German allows exceptions for brandnames like das iPhone or xkcd). There's not much else that you could automate, so I'd be interested to know who else finds it useful. A quick grep shows, that releasename-cap is used in: Korean Portuguese French Italian Czech German So guys, you are all wrong? Holger -- Created with Sylpheed 3.5.0 under D E B I A N L I N U X 8 . 0J E S S I E . Registered Linux User #311290 - https://linuxcounter.net/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150807152525.47d654217096fd071f442...@wansing-online.de
Re: proofreading the installation-guide
Justin B Rye, le Fri 07 Aug 2015 15:52:00 +0100, a écrit : It's not immediately obvious why we're going to the trouble of distinguishing command from classname (along with filename, prompt, literal, and who knows what else). I'm sure it's all lovely and semantic, but all we actually want is for them to be flagged as verbatim literal strings by appearing in the same nonproportional typeface. It makes a lot of sense to at least distinguish what the user types from what the computer prompted. It also makes sense, for package names, to put hyperlinks to package maintenance pages, or things like this. My 2¢ guesses, Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150807145928.gv3...@type.bordeaux.inria.fr
Re: proofreading the installation-guide
Samuel Thibault wrote: On to spending some time on answering this... Well, you may have noticed I'm rather taking the long view on actually getting started on stage one. Justin B Rye: First, the deep-rooted termininological issues that I'd prefer to have sane answers for before I start fiddling with details: * why is there so little mention of BD media? It seems to me that we should almost never say CDs and DVDs; we should settle on a cover-term like optical media and always use that. The one time it does mention BD-ROMS it claims that it's going to use CD-ROMs as a cover-term... but then it doesn't. Probably just lack of coordination between manual contributors. Cleaning up probably welcome indeed. So maybe this is the place to start, if I can produce a patch fully implementing the idea to go with my bugreport. * D-I seems to have standardised on the term MD devices, expanding MD as Multidisk Device (what, so they're Multidisk Device devices?); but officially md stands for Multiple Device. Besides, if what we're talking about is in fact a software RAID array, why don't we just call it that? Probably because it's called md in the linux kernel. Yes, that would explain how the mistake came to be made, but it's worth noting that even the kernel documentation for it (aimed at the most hardcore of techies) has always explained it in terms of RAID. Section 6.3.3.4 Configuring Multidisk Devices (Software RAID) might want to mention md somewhere, but not in the title - all that's really needed is a footnote explaining why the tool for setting up RAID is called mdcfg. (And since that isn't even true anywhere outside D-I, in a sane world we'd simply rename that module to raid. But that would require much more than just documentation patches.) * is there any hope of getting rid of the crazy backwards jargon of low priority installs? When you ask for Expert mode, you aren't lowering the priority of the install (i.e. declaring it less urgent); I agree that this is confusing because the intuition of most people will be the converse of what is meant. It's however not only in the manual that it needs to be fixed, but also in the installer itself. And it can be traced back to debconf, which uses a template named debconf/priority when what it means is debconf/filtering. But fixing that would cause havoc for every preseeding setup in existence, and probably every installed system with a debconf database. It's about as likely to be fixed as the misnomer templates. I'm currently looking for a way of patching over it in the documentation, but I'm not getting very far. (Perhaps I should make these three separate bugreports?) To classify discussion, that may help, yes (In fact, maybe the answers are or should be in a README somewhere?) Probably. The doc folder already has some information, additions is welcome. Actually I'd missed the doc folder in my svn checkout, which doesn't help! * Structure - some of the XML files seem to be unused relics, but it's hard to tell which... There is the svn version it is based on at the top of each of them. Looking at datestamps would flag the What is Debian page as unmaintained, while the subpages giving tips for Linux 2.2 on PDP-11 or whatever would escape my notice as long as they keep getting affected by global search-and-replace operations. All I want to do is search for filenames that are never referenced in other pages, but I need a version of grep that ignores commented-out text... * tag questions - e.g.: command is used fairly consistently for executables (like grub), and classinfo for some reason marks Debian packages (like grub-pc), but what do we do with GRUB? It depends on the context. When it is about the software in general, it should be the official name, which is GRUB. When it's a command to type, then command, when it's a package to install, then it's classname (not classinfo, apparently). Oh, yes, sorry, I don't know where I got classinfo from. But I know why I failed to remember classname! It's not immediately obvious why we're going to the trouble of distinguishing command from classname (along with filename, prompt, literal, and who knows what else). I'm sure it's all lovely and semantic, but all we actually want is for them to be flagged as verbatim literal strings by appearing in the same nonproportional typeface. * Should all titles be titlecase? Could we switch to sentencecase? A lot of people contributing to the manual are not native english speaker, that's probably why the casing :) I personally don't really mind, but I will probably always forget to stick to titlecase, if we choose that. I thought for a while that we were trying to follow a rule of titlecase for main titles, sentencecase for subtitles, but no, it's just slightly random. -- JBR with qualifications in linguistics,
Re: proofreading the installation-guide
Samuel Thibault wrote: Justin B Rye, le Fri 07 Aug 2015 15:52:00 +0100, a écrit : It's not immediately obvious why we're going to the trouble of distinguishing command from classname (along with filename, prompt, literal, and who knows what else). I'm sure it's all lovely and semantic, but all we actually want is for them to be flagged as verbatim literal strings by appearing in the same nonproportional typeface. It makes a lot of sense to at least distinguish what the user types from what the computer prompted. It also makes sense, for package names, to put hyperlinks to package maintenance pages, or things like this. My 2¢ guesses, prompt is only used for prompt#/prompt versus prompt$/prompt and promptboot:/prompt. Packagenames as hyperlinks to the PTS would be a nice idea, though it would require some work to tidy up uses of classname to the point where it can be relied on not to be a preseed parameter or D-I module name or something. Oh, maybe we could use the docbook 4.4 tag package: http://www.docbook.org/tdg/en/html/package.html;? That would certainly make it feel more useful. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150807155118.ga5...@xibalba.demon.co.uk
Re: proofreading the installation-guide
Holger Wansing wrote: Justin B Rye justin.byam@gmail.com wrote: So all cases of releasename-cap; in the English text are mistakes. Really if it's only for use in German we should have called it Veroeffentlichungsname;! No, it's not just for German! It gives _all_ translators the possibility, to spell the releasename as they want in their language. I just used German and how it's used in German, to explain the principle. Not much translators use that possibility though. Such as? There *aren't* any other languages that have mandatory initial capitalisation on nouns (and even German allows exceptions for brandnames like das iPhone or xkcd). There's not much else that you could automate, so I'd be interested to know who else finds it useful. A quick grep shows, that releasename-cap is used in: Korean Portuguese French Italian Czech German So guys, you are all wrong? If they're just using it to capitalise a brandname that we've decided is canonically uncapitalisable then it's just a question of whether they're doing it wrong or whether the decision was wrong for English in the first place. But if you take a proper look at the results of that grep, you'll see that every single case is a reflection of the same problem: there are a couple of files where the English text has randomly switched to using releasename-cap;, and those hits are just the places where the translators haven't changed it. So once my proofreading sweep has finished* and all the translations catch up, there should be no mentions of releasename-cap; except in places where it might as well be called Veroeffentlichungsname;. * assuming it ever gets started... -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150807145350.gb4...@xibalba.demon.co.uk
Re: proofreading the installation-guide
Hello, On to spending some time on answering this... Justin B Rye, le Sun 26 Jul 2015 13:15:18 +0100, a écrit : A month ago in #789604, Justin B Rye wrote: Hmm, well, I've never proofread the installation-guide as a whole. I ought to get round to doing that some time. I'm trying to work out where I'd start with this. I can see things that need fixing, but they fall into several different categories and I don't know if it makes sense to try to deal with all of them at once. Possibly not. I don't think it matters very much, though. First, the deep-rooted termininological issues that I'd prefer to have sane answers for before I start fiddling with details: * why is there so little mention of BD media? It seems to me that we should almost never say CDs and DVDs; we should settle on a cover-term like optical media and always use that. The one time it does mention BD-ROMS it claims that it's going to use CD-ROMs as a cover-term... but then it doesn't. Probably just lack of coordination between manual contributors. Cleaning up probably welcome indeed. * D-I seems to have standardised on the term MD devices, expanding MD as Multidisk Device (what, so they're Multidisk Device devices?); but officially md stands for Multiple Device. Besides, if what we're talking about is in fact a software RAID array, why don't we just call it that? Probably because it's called md in the linux kernel. * is there any hope of getting rid of the crazy backwards jargon of low priority installs? When you ask for Expert mode, you aren't lowering the priority of the install (i.e. declaring it less urgent); I agree that this is confusing because the intuition of most people will be the converse of what is meant. It's however not only in the manual that it needs to be fixed, but also in the installer itself. (Perhaps I should make these three separate bugreports?) To classify discussion, that may help, yes (In fact, maybe the answers are or should be in a README somewhere?) Probably. The doc folder already has some information, additions is welcome. * Structure - some of the XML files seem to be unused relics, but it's hard to tell which... There is the svn version it is based on at the top of each of them. * tag questions - e.g.: command is used fairly consistently for executables (like grub), and classinfo for some reason marks Debian packages (like grub-pc), but what do we do with GRUB? It depends on the context. When it is about the software in general, it should be the official name, which is GRUB. When it's a command to type, then command, when it's a package to install, then it's classname (not classinfo, apparently). * Should all titles be titlecase? Could we switch to sentencecase? A lot of people contributing to the manual are not native english speaker, that's probably why the casing :) I personally don't really mind, but I will probably always forget to stick to titlecase, if we choose that. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150807004553.gv3...@type.home
Re: proofreading the installation-guide
Holger Wansing wrote: No, not _all_ instances of releasename; have to be capitalised in German, for example in URLs they will have to stay lowercase. But I can use releasename; or releasename-cap; in my translation, where releasename; is used in English. So all cases of releasename-cap; in the English text are mistakes. Really if it's only for use in German we should have called it Veroeffentlichungsname;! But given that we're treating the name jessie as a special string that's entitled to ignore the usual English capitalisation rules (so that for instance it's still lowercase when it's sentence-initial), it's not clear why this verbatim status wouldn't also licence it to disregard the standard capitalisation rules of German. Unless rules stated in German are just intrinsically stricter! Mind you, there's no obvious reason (apart from the stiffness of developers' little fingers) for this habit of treating the lowercase form of the release name as canonical in the first place. Jessie is after all named after something that had a capital J, and even the announcement of the codename for Debian 8 spelled it that way: https://lists.debian.org/debian-devel-announce/2012/07/msg4.html Things would be a lot simpler if only we could standardise on the *capitalised* form. But then I suppose people would complain that that isn't what's in /etc/os-release... -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150804181120.ga10...@xibalba.demon.co.uk
Re: proofreading the installation-guide
Hi, Justin B Rye justin.byam@gmail.com wrote: Holger Wansing wrote: No, not _all_ instances of releasename; have to be capitalised in German, for example in URLs they will have to stay lowercase. But I can use releasename; or releasename-cap; in my translation, where releasename; is used in English. So all cases of releasename-cap; in the English text are mistakes. Really if it's only for use in German we should have called it Veroeffentlichungsname;! No, it's not just for German! It gives _all_ translators the possibility, to spell the releasename as they want in their language. I just used German and how it's used in German, to explain the principle. Not much translators use that possibility though. Holger -- Created with Sylpheed 3.5.0 under D E B I A N L I N U X 8 . 0J E S S I E . Registered Linux User #311290 - https://linuxcounter.net/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150804205051.0e86519a24091e175869c...@wansing-online.de
Re: proofreading the installation-guide
Holger Wansing wrote: Justin B Rye justin.byam@gmail.com wrote: Holger Wansing wrote: No, not _all_ instances of releasename; have to be capitalised in German, for example in URLs they will have to stay lowercase. But I can use releasename; or releasename-cap; in my translation, where releasename; is used in English. So all cases of releasename-cap; in the English text are mistakes. Really if it's only for use in German we should have called it Veroeffentlichungsname;! No, it's not just for German! It gives _all_ translators the possibility, to spell the releasename as they want in their language. I just used German and how it's used in German, to explain the principle. Not much translators use that possibility though. Such as? There *aren't* any other languages that have mandatory initial capitalisation on nouns (and even German allows exceptions for brandnames like das iPhone or xkcd). There's not much else that you could automate, so I'd be interested to know who else finds it useful. Fortunately none of this should matter for a proofreading sweep of the English. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150804194756.ga12...@xibalba.demon.co.uk
Re: proofreading the installation-guide
Justin B Rye, le Tue 28 Jul 2015 21:06:03 +0100, a écrit : Holger Wansing wrote: Justin B Rye justin.byam@gmail.com wrote: An interesting idea, but one that seems unlikely to work, especially given the way it's used in the text. For instance, there's a page welcome/what-is-debian-linux.xml, which is full of sentences like debian; was the first Linux distribution to include a package management system. It was mostly me changing Debian into debian; that days in 2010. If I remember correctly, it was initiated by a post of Frans Pop, who proposed that change. And the rationale was in fact, to get a manual, that can easily be turned from a Debian installer manual into a Ubuntu installer manual, for example. Whoever it is that's reworking the manual for the derivative is still going to need to go through the whole text changing the content. Yes, but most probably only once. The really-debian-specific text hasn't really changed much over years. The debian; entity seems liable to cost us more effort than it saves them (a single extra search-and-replace operation). Yes, but once in place, merges become trivial. That's the whole point of it. The architecture;, arch-title; and arch-kernel; entities are slightly oddly named Since I keep losing track and having to check again, I'll leave a note for myself here: architecture; = 32-bit PC, 32-bit soft-float ARM, etc. arch-title; = i386, armel, etc. arch-kernel; = Linux, KFreeBSD, etc. This, and also: Hendrik Boom wrote: So I suppose it would be reasonable to put a comment in the document source explaining this, perhaps where these macros are defined can probably find its way to common.ent indeed, patches (or simply, commits) welcome :) Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150804192735.GG3954@type
Re: proofreading the installation-guide
On Tue, Jul 28, 2015 at 09:06:03PM +0100, Justin B Rye wrote: Holger Wansing wrote: Justin B Rye justin.byam@gmail.com wrote: An interesting idea, but one that seems unlikely to work, especially given the way it's used in the text. For instance, there's a page welcome/what-is-debian-linux.xml, which is full of sentences like debian; was the first Linux distribution to include a package management system. It was mostly me changing Debian into debian; that days in 2010. If I remember correctly, it was initiated by a post of Frans Pop, who proposed that change. And the rationale was in fact, to get a manual, that can easily be turned from a Debian installer manual into a Ubuntu installer manual, for example. Whoever it is that's reworking the manual for the derivative is still going to need to go through the whole text changing the content. The debian; entity seems liable to cost us more effort than it saves them (a single extra search-and-replace operation). If that was the case, it would be a single search-and-replace operation for you, too. Just catch the ones you see while proofreading, leave the rest. The Debian derivative's people will catch the ones you miss, and you can someday, *when there's time to do it*, diff your source with theirs to find the rest. Of course, this is only for derivatives that use the same installer. And I can't see any particular pattern in when it's Debian installer, when it's debian; installer, and when it's d-i;. With the above been said, it should be as follows: In sentences which apply to Debian and also to its derivates, it should use debian; , while in sentences which only apply to Debian and not to the derivates, it should be Debian. It was also my intention to make it that way indeed, but: 1. I found out that the job was bigger than I first thought when taking it over, leading to mistakes. 2. due to the lack of manpower in the d-i team, especially the loss of Frans, the d-i manual guru (amongst other roles), there was probably not enough reviewing of that changes, and things may got overlooked. Oh, well, for now I'll plan on trying to get debian; into shape as part of my proofreading sweep - it would be easy enough to switch back from sometimes saying debian; to always saying Debian if we decide to give up on it. The debian-gnu; entity is effectively just shorthand for Debian GNU/arch-kernel; - confusing but handy. Wait, does it expand to Debian or debian;? The architecture;, arch-title; and arch-kernel; entities are slightly oddly named Since I keep losing track and having to check again, I'll leave a note for myself here: architecture; = 32-bit PC, 32-bit soft-float ARM, etc. arch-title; = i386, armel, etc. arch-kernel; = Linux, KFreeBSD, etc. but make sense as parametrisations, as do release; and releasename; as long as they're used for things that stay true for every release. (Oh, and I've just noticed there's a releasename-cap;, used instead of plain releasename; for no obvious reason in hardware/supported/arm.xml and nowhere else.) But there are also special entities for enterkey;, escapekey;, tabkey;, f10key;, and even ekey;! Most of these are only used once each - the rest of the time (and always for keys like F2 or space) it just uses keycap.../keycap. That entities like releasename-cap; enterkey; escapekey; tabkey; were created, to give translators a chance to follow the rules for their language there (for example, in German we write Jessie, Stretch or Unstable uppercase, while in English that's mostly lowercase: jessie, stretch, unstable) or to have tab key translated into Tabulator-Taste for German, for example. Sorry, I don't follow. Surely German needs *all* instances of releasename; to be capitalised? How does it help to have some of them replaced in the text with releasename-cap;? And why is it any easier to provide translations for tabkey; than for keycodeTab/keycode? Why would you need ones for f10key; and ekey;, but not keycodeF2/keycode or keycodeSpace/keycode? Hmm, I can imagine cases where the *English* version might benefit from having an entity indefinitearticle; that automatically selects either a or an depending on whether the following substituted-in word starts with a vowel sound! But let's not. Globally said, there may be several occurrences of above things not being perfectly consistent, because there are many editors for the manual these days, but there is no Frans Pop anymore, watching the changings and correcting things where needed. [PS included for convenience:] So I suppose it would be reasonable to put a comment in the document source explaining this, perhaps where these macros are defined, and making further changes as we discover the need and have time, possibly prompted by bug reports from Debian derivatives or forks, or
Re: proofreading the installation-guide
Hi, Justin B Rye justin.byam@gmail.com wrote: Hendrik Boom wrote: Justin B Rye wrote: * entity questions - when am I meant to say Debian and when is it debian;? This like many of these entities seems to have no obvious function other than to make the source harder to interpret... * The d-i; entity expands to debian-installer in bold verbatim lowercase. If that is in effect the brandname of the software project then presumably we shouldn't be talking about the d-i; - that ought to be the Debian installer. Presumably both of these parametrisations are for the convenience of Debian derivatives and forks. By making these macros, it's easier for the, and it'll be easier for us to merge downstream patches. An interesting idea, but one that seems unlikely to work, especially given the way it's used in the text. For instance, there's a page welcome/what-is-debian-linux.xml, which is full of sentences like debian; was the first Linux distribution to include a package management system. It was mostly me changing Debian into debian; that days in 2010. If I remember correctly, it was initiated by a post of Frans Pop, who proposed that change. And the rationale was in fact, to get a manual, that can easily be turned from a Debian installer manual into a Ubuntu installer manual, for example. And I can't see any particular pattern in when it's Debian installer, when it's debian; installer, and when it's d-i;. With the above been said, it should be as follows: In sentences which apply to Debian and also to its derivates, it should use debian; , while in sentences which only apply to Debian and not to the derivates, it should be Debian. It was also my intention to make it that way indeed, but: 1. I found out that the job was bigger than I first thought when taking it over, leading to mistakes. 2. due to the lack of manpower in the d-i team, especially the loss of Frans, the d-i manual guru (amongst other roles), there was probably not enough reviewing of that changes, and things may got overlooked. The debian-gnu; entity is effectively just shorthand for Debian GNU/arch-kernel; - confusing but handy. The architecture;, arch-title; and arch-kernel; entities are slightly oddly named but make sense as parametrisations, as do release; and releasename; as long as they're used for things that stay true for every release. (Oh, and I've just noticed there's a releasename-cap;, used instead of plain releasename; for no obvious reason in hardware/supported/arm.xml and nowhere else.) But there are also special entities for enterkey;, escapekey;, tabkey;, f10key;, and even ekey;! Most of these are only used once each - the rest of the time (and always for keys like F2 or space) it just uses keycap.../keycap. That entities like releasename-cap; enterkey; escapekey; tabkey; were created, to give translators a chance to follow the rules for their language there (for example, in German we write Jessie, Stretch or Unstable uppercase, while in English that's mostly lowercase: jessie, stretch, unstable) or to have tab key translated into Tabulator-Taste for German, for example. Globally said, there may be several occurrences of above things not being perfectly consistent, because there are many editors for the manual these days, but there is no Frans Pop anymore, watching the changings and correcting things where needed. Regards Holger -- Created with Sylpheed 3.5.0 under D E B I A N L I N U X 8 . 0J E S S I E . Registered Linux User #311290 - https://linuxcounter.net/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150728190027.b25aa6026e9dfb93eaeed...@wansing-online.de
Re: proofreading the installation-guide
Holger Wansing wrote: Justin B Rye justin.byam@gmail.com wrote: An interesting idea, but one that seems unlikely to work, especially given the way it's used in the text. For instance, there's a page welcome/what-is-debian-linux.xml, which is full of sentences like debian; was the first Linux distribution to include a package management system. It was mostly me changing Debian into debian; that days in 2010. If I remember correctly, it was initiated by a post of Frans Pop, who proposed that change. And the rationale was in fact, to get a manual, that can easily be turned from a Debian installer manual into a Ubuntu installer manual, for example. Whoever it is that's reworking the manual for the derivative is still going to need to go through the whole text changing the content. The debian; entity seems liable to cost us more effort than it saves them (a single extra search-and-replace operation). And I can't see any particular pattern in when it's Debian installer, when it's debian; installer, and when it's d-i;. With the above been said, it should be as follows: In sentences which apply to Debian and also to its derivates, it should use debian; , while in sentences which only apply to Debian and not to the derivates, it should be Debian. It was also my intention to make it that way indeed, but: 1. I found out that the job was bigger than I first thought when taking it over, leading to mistakes. 2. due to the lack of manpower in the d-i team, especially the loss of Frans, the d-i manual guru (amongst other roles), there was probably not enough reviewing of that changes, and things may got overlooked. Oh, well, for now I'll plan on trying to get debian; into shape as part of my proofreading sweep - it would be easy enough to switch back from sometimes saying debian; to always saying Debian if we decide to give up on it. The debian-gnu; entity is effectively just shorthand for Debian GNU/arch-kernel; - confusing but handy. Wait, does it expand to Debian or debian;? The architecture;, arch-title; and arch-kernel; entities are slightly oddly named Since I keep losing track and having to check again, I'll leave a note for myself here: architecture; = 32-bit PC, 32-bit soft-float ARM, etc. arch-title; = i386, armel, etc. arch-kernel; = Linux, KFreeBSD, etc. but make sense as parametrisations, as do release; and releasename; as long as they're used for things that stay true for every release. (Oh, and I've just noticed there's a releasename-cap;, used instead of plain releasename; for no obvious reason in hardware/supported/arm.xml and nowhere else.) But there are also special entities for enterkey;, escapekey;, tabkey;, f10key;, and even ekey;! Most of these are only used once each - the rest of the time (and always for keys like F2 or space) it just uses keycap.../keycap. That entities like releasename-cap; enterkey; escapekey; tabkey; were created, to give translators a chance to follow the rules for their language there (for example, in German we write Jessie, Stretch or Unstable uppercase, while in English that's mostly lowercase: jessie, stretch, unstable) or to have tab key translated into Tabulator-Taste for German, for example. Sorry, I don't follow. Surely German needs *all* instances of releasename; to be capitalised? How does it help to have some of them replaced in the text with releasename-cap;? And why is it any easier to provide translations for tabkey; than for keycodeTab/keycode? Why would you need ones for f10key; and ekey;, but not keycodeF2/keycode or keycodeSpace/keycode? Hmm, I can imagine cases where the *English* version might benefit from having an entity indefinitearticle; that automatically selects either a or an depending on whether the following substituted-in word starts with a vowel sound! But let's not. Globally said, there may be several occurrences of above things not being perfectly consistent, because there are many editors for the manual these days, but there is no Frans Pop anymore, watching the changings and correcting things where needed. [PS included for convenience:] So I suppose it would be reasonable to put a comment in the document source explaining this, perhaps where these macros are defined, and making further changes as we discover the need and have time, possibly prompted by bug reports from Debian derivatives or forks, or even just doing a diff between our d-i manual and some of the derivatives' Okay. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150728200603.ga13...@xibalba.demon.co.uk
Re: proofreading the installation-guide
On Tue, Jul 28, 2015 at 07:00:27PM +0200, Holger Wansing wrote: Hi, Justin B Rye justin.byam@gmail.com wrote: Hendrik Boom wrote: Justin B Rye wrote: * entity questions - when am I meant to say Debian and when is it debian;? This like many of these entities seems to have no obvious function other than to make the source harder to interpret... * The d-i; entity expands to debian-installer in bold verbatim lowercase. If that is in effect the brandname of the software project then presumably we shouldn't be talking about the d-i; - that ought to be the Debian installer. Presumably both of these parametrisations are for the convenience of Debian derivatives and forks. By making these macros, it's easier for the, and it'll be easier for us to merge downstream patches. An interesting idea, but one that seems unlikely to work, especially given the way it's used in the text. For instance, there's a page welcome/what-is-debian-linux.xml, which is full of sentences like debian; was the first Linux distribution to include a package management system. It was mostly me changing Debian into debian; that days in 2010. If I remember correctly, it was initiated by a post of Frans Pop, who proposed that change. And the rationale was in fact, to get a manual, that can easily be turned from a Debian installer manual into a Ubuntu installer manual, for example. And I can't see any particular pattern in when it's Debian installer, when it's debian; installer, and when it's d-i;. With the above been said, it should be as follows: In sentences which apply to Debian and also to its derivates, it should use debian; , while in sentences which only apply to Debian and not to the derivates, it should be Debian. It was also my intention to make it that way indeed, but: 1. I found out that the job was bigger than I first thought when taking it over, leading to mistakes. 2. due to the lack of manpower in the d-i team, especially the loss of Frans, the d-i manual guru (amongst other roles), there was probably not enough reviewing of that changes, and things may got overlooked. The debian-gnu; entity is effectively just shorthand for Debian GNU/arch-kernel; - confusing but handy. The architecture;, arch-title; and arch-kernel; entities are slightly oddly named but make sense as parametrisations, as do release; and releasename; as long as they're used for things that stay true for every release. (Oh, and I've just noticed there's a releasename-cap;, used instead of plain releasename; for no obvious reason in hardware/supported/arm.xml and nowhere else.) But there are also special entities for enterkey;, escapekey;, tabkey;, f10key;, and even ekey;! Most of these are only used once each - the rest of the time (and always for keys like F2 or space) it just uses keycap.../keycap. That entities like releasename-cap; enterkey; escapekey; tabkey; were created, to give translators a chance to follow the rules for their language there (for example, in German we write Jessie, Stretch or Unstable uppercase, while in English that's mostly lowercase: jessie, stretch, unstable) or to have tab key translated into Tabulator-Taste for German, for example. Globally said, there may be several occurrences of above things not being perfectly consistent, because there are many editors for the manual these days, but there is no Frans Pop anymore, watching the changings and correcting things where needed. So I suppose it would be reasonable to put a comment in the document source explaining this, perhaps where these macros are defined, and making further changes as we discover the need and have time, possibly prompted by bug reports from Debian derivatives or forks, or even just doing a diff between our d-i manual and some of the derivatives' -- hendrik -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150728192418.gb4...@topoi.pooq.com
Re: proofreading the installation-guide
Hi, Justin B Rye justin.byam@gmail.com wrote: Holger Wansing wrote: Justin B Rye justin.byam@gmail.com wrote: The debian-gnu; entity is effectively just shorthand for Debian GNU/arch-kernel; - confusing but handy. Wait, does it expand to Debian or debian;? debian-gnu; - debian; GNU/arch-kernel; - Debian GNU/Linux | Debian GNU/kFreeBSD [...] But there are also special entities for enterkey;, escapekey;, tabkey;, f10key;, and even ekey;! Most of these are only used once each - the rest of the time (and always for keys like F2 or space) it just uses keycap.../keycap. That entities like releasename-cap; enterkey; escapekey; tabkey; were created, to give translators a chance to follow the rules for their language there (for example, in German we write Jessie, Stretch or Unstable uppercase, while in English that's mostly lowercase: jessie, stretch, unstable) or to have tab key translated into Tabulator-Taste for German, for example. Sorry, I don't follow. Surely German needs *all* instances of releasename; to be capitalised? How does it help to have some of them replaced in the text with releasename-cap;? No, not _all_ instances of releasename; have to be capitalised in German, for example in URLs they will have to stay lowercase. But I can use releasename; or releasename-cap; in my translation, where releasename; is used in English. And why is it any easier to provide translations for tabkey; than for keycodeTab/keycode? Why would you need ones for f10key; and ekey;, but not keycodeF2/keycode or keycodeSpace/keycode? This is probably not perfect, maybe it was in the beginning, and then Frans left us? I don't know the exact details, so simply my best guess, maybe. I don't see any benefit on the f10key; or ekey;, too. Holger -- Created with Sylpheed 3.5.0 under D E B I A N L I N U X 8 . 0J E S S I E . Registered Linux User #311290 - https://linuxcounter.net/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150728222342.7870e3bed76d5395701be...@wansing-online.de
proofreading the installation-guide
A month ago in #789604, Justin B Rye wrote: Hmm, well, I've never proofread the installation-guide as a whole. I ought to get round to doing that some time. I'm trying to work out where I'd start with this. I can see things that need fixing, but they fall into several different categories and I don't know if it makes sense to try to deal with all of them at once. * * * First, the deep-rooted termininological issues that I'd prefer to have sane answers for before I start fiddling with details: * why is there so little mention of BD media? It seems to me that we should almost never say CDs and DVDs; we should settle on a cover-term like optical media and always use that. The one time it does mention BD-ROMS it claims that it's going to use CD-ROMs as a cover-term... but then it doesn't. * D-I seems to have standardised on the term MD devices, expanding MD as Multidisk Device (what, so they're Multidisk Device devices?); but officially md stands for Multiple Device. Besides, if what we're talking about is in fact a software RAID array, why don't we just call it that? * is there any hope of getting rid of the crazy backwards jargon of low priority installs? When you ask for Expert mode, you aren't lowering the priority of the install (i.e. declaring it less urgent); you aren't even lowering the priority of the questions it asks. What you're doing is lowering the amount of filtering-by-priority applied to debconf prompts - or to put that another way, you're asking for a low *simplification* install. (Perhaps I should make these three separate bugreports?) * * * Second, questions specific to the installation-guide's docbook, which again it would be nice to have answers for before I start trying to produce patches. (In fact, maybe the answers are or should be in a README somewhere?) * Structure - some of the XML files seem to be unused relics, but it's hard to tell which... * tag questions - e.g.: command is used fairly consistently for executables (like grub), and classinfo for some reason marks Debian packages (like grub-pc), but what do we do with GRUB? * Should all titles be titlecase? Could we switch to sentencecase? * entity questions - when am I meant to say Debian and when is it debian;? This like many of these entities seems to have no obvious function other than to make the source harder to interpret... * The d-i; entity expands to debian-installer in bold verbatim lowercase. If that is in effect the brandname of the software project then presumably we shouldn't be talking about the d-i; - that ought to be the Debian installer. * * * Third, the various categories of routine maintenance: * Decobwebbing - all those examples of tiny IDE hard drives with ext3 file systems. * systemd-proofing - stuff about initscripts, /etc/inittab, eth0. * When do we say APT, when is it apt-get/aptitude/apt? * Non-native-English-speakerisms - the usual objectless allows and Teutonic respectivelies, plus one that's especially common in D-I: yes, CDs are (installation) media, but one CD isn't a medium. * All those references to dhcp and ram and ips. * All those OldWorld PowerMacs (canonically four words). * Standardi[sz]ation issues (mostly behaviour). * General phrasing upgrades (mostly to reduce repetition). * Optional-extra house style tweaks like adding Harvard commas. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150726121518.ga14...@xibalba.demon.co.uk
Re: proofreading the installation-guide
On Sun, Jul 26, 2015 at 01:15:18PM +0100, Justin B Rye wrote: * entity questions - when am I meant to say Debian and when is it debian;? This like many of these entities seems to have no obvious function other than to make the source harder to interpret... * The d-i; entity expands to debian-installer in bold verbatim lowercase. If that is in effect the brandname of the software project then presumably we shouldn't be talking about the d-i; - that ought to be the Debian installer. Presumably both of these parametrisations are for the convenience of Debian derivatives and forks. By making these macros, it's easier for the, and it'll be easier for us to merge downstream patches. -- hendrik -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150726122637.gb10...@topoi.pooq.com
Re: proofreading the installation-guide
Hendrik Boom wrote: Justin B Rye wrote: * entity questions - when am I meant to say Debian and when is it debian;? This like many of these entities seems to have no obvious function other than to make the source harder to interpret... * The d-i; entity expands to debian-installer in bold verbatim lowercase. If that is in effect the brandname of the software project then presumably we shouldn't be talking about the d-i; - that ought to be the Debian installer. Presumably both of these parametrisations are for the convenience of Debian derivatives and forks. By making these macros, it's easier for the, and it'll be easier for us to merge downstream patches. An interesting idea, but one that seems unlikely to work, especially given the way it's used in the text. For instance, there's a page welcome/what-is-debian-linux.xml, which is full of sentences like debian; was the first Linux distribution to include a package management system. And I can't see any particular pattern in when it's Debian installer, when it's debian; installer, and when it's d-i;. The debian-gnu; entity is effectively just shorthand for Debian GNU/arch-kernel; - confusing but handy. The architecture;, arch-title; and arch-kernel; entities are slightly oddly named but make sense as parametrisations, as do release; and releasename; as long as they're used for things that stay true for every release. (Oh, and I've just noticed there's a releasename-cap;, used instead of plain releasename; for no obvious reason in hardware/supported/arm.xml and nowhere else.) But there are also special entities for enterkey;, escapekey;, tabkey;, f10key;, and even ekey;! Most of these are only used once each - the rest of the time (and always for keys like F2 or space) it just uses keycap.../keycap. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150726133745.ga19...@xibalba.demon.co.uk
Re: proofreading the installation-guide
On Sun, Jul 26, 2015 at 02:37:45PM +0100, Justin B Rye wrote: Hendrik Boom wrote: Justin B Rye wrote: * entity questions - when am I meant to say Debian and when is it debian;? This like many of these entities seems to have no obvious function other than to make the source harder to interpret... * The d-i; entity expands to debian-installer in bold verbatim lowercase. If that is in effect the brandname of the software project then presumably we shouldn't be talking about the d-i; - that ought to be the Debian installer. Presumably both of these parametrisations are for the convenience of Debian derivatives and forks. By making these macros, it's easier for the, and it'll be easier for us to merge downstream patches. An interesting idea, but one that seems unlikely to work, especially given the way it's used in the text. For instance, there's a page welcome/what-is-debian-linux.xml, which is full of sentences like debian; was the first Linux distribution to include a package management system. It makes me wonder whether this was originally the intention, but has become lost as generations of editors failed to follow up on it. -- hendrik -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150726153548.ga12...@topoi.pooq.com
