From: joy <joy@313b444b-1b9f-4f58-a734-7bb04f332e8d>
Date: Thu, 20 Jun 2002 20:34:58 +0000 (+0000)
Subject: linguistic fixes from David Kimdon; other proofreading by myself, mostly changing... 
X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=developers-reference.git;a=commitdiff_plain;h=dc8127be4b292e0a08170d665857c7da1301a9d7

linguistic fixes from David Kimdon; other proofreading by myself, mostly changing he -> they


git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@1722 313b444b-1b9f-4f58-a734-7bb04f332e8d
---

diff --git a/developers-reference.sgml b/developers-reference.sgml
index 944aebd..58c6e9d 100644
--- a/developers-reference.sgml
+++ b/developers-reference.sgml
@@ -6,7 +6,7 @@
   <!entity % commondata  SYSTEM "common.ent" > %commondata;
 
   <!-- CVS revision of this document -->
-  <!entity cvs-rev "$Revision: 1.115 $">
+  <!entity cvs-rev "$Revision: 1.116 $">
   <!-- if you are translating this document, please notate the CVS
        revision of the developers reference here -->
   <!--
@@ -54,7 +54,7 @@ General Public License for more details.
 	<p>
 A copy of the GNU General Public License is available as &file-GPL; in
 the &debian-formal; distribution or on the World Wide Web at <url
-id="&url-gpl;" name="the GNU website">.  You can also obtain it by
+id="&url-gpl;" name="the GNU web site">.  You can also obtain it by
 writing to the &fsf-addr;.
 
     <toc detail="sect1">
@@ -128,8 +128,8 @@ should get in contact with existing Debian maintainers who are working
 on similar tasks.  That way, you can learn from experienced developers.
 For example, if you are interested in packaging existing software for
 Debian you should try to get a sponsor.  A sponsor will work together
-with you on your package and upload it to the Debian archive once he
-is happy with the packaging work you have done.  You can find a sponsor
+with you on your package and upload it to the Debian archive once they
+are happy with the packaging work you have done.  You can find a sponsor
 by mailing the &email-debian-mentors; mailing list, describing your
 package and yourself and asking for a sponsor (see <ref id="sponsoring">
 for more information on sponsoring).  On the other hand, if you are
@@ -272,7 +272,7 @@ available in <ref id="newmaint">.
 
       <sect id="user-maint">Maintaining your Debian information
 	<p>
-There's a LDAP database containing many informations concerning all
+There's a LDAP database containing information about all
 developers, you can access it at <url id="&url-debian-db;">. You can
 update your password (this password is propagated to most of the machines
 that are accessible to you), your address, your country, the latitude and
@@ -294,7 +294,7 @@ Read the documentation that comes with your software; read the <url
 id="&url-pgp-faq;" name="PGP FAQ">.
 	<p>
 If you add signatures to your public key, or add user identities, you
-can update the debian key ring by sending your key to the key server at
+can update the Debian key ring by sending your key to the key server at
 <tt>&keyserver-host;</tt>.  If you need to add a completely new key,
 or remove an old key, send mail to &email-debian-keyring;.  The same
 key extraction routines discussed in <ref id="registering"> apply.
@@ -465,7 +465,7 @@ The main channel <em>#debian-devel</em> is very active since more
 than 150 persons are always logged in. It's a channel for people who work
 on Debian, it's not a support channel (there's <em>#debian</em> for that).
 It is however open to anyone who wants to lurk (and learn). Its topic is
-always full of interesting informations. Since it's an open channel, you
+always full of interesting information. Since it's an open channel, you
 should not speak there of issues that are discussed in
 &email-debian-private;. There's a key protected channel
 <em>#debian-private</em> for that purpose. The key is available 
@@ -488,7 +488,7 @@ French speaking people interested in Debian's development.
 
       <sect id="doc-rsrcs">Documentation
 	<p>
-This document contains many informations very useful to Debian developers,
+This document contains a lot of information very useful to Debian developers,
 but it can not contain everything. Most of the other interesting documents
 are linked from <url id="&url-devel-docs;" name="The Developers' Corner">.
 Take the time to browse all the links, you will learn many more things.
@@ -503,7 +503,7 @@ If you have a problem with the operation of a Debian server, and you
 think that the system operators need to be notified of this problem,
 please find the contact address for the particular machine at <url
 id="&url-devel-machines;">.  If you have a non-operating problems
-(such as packages to be remove, suggestions for the web site, etc.),
+(such as packages to be removed, suggestions for the web site, etc.),
 generally you'll report a bug against a ``pseudo-package''.  See <ref
 id="submit-bug"> for information on how to submit bugs.
 
@@ -544,7 +544,7 @@ The main web server, <tt>&www-host;</tt>, is also known as
 machine.
 	<p>
 If you have some Debian-specific information which you want to serve
-up on the web, you can do this by putting material in the
+on the web, you can do this by putting material in the
 <file>public_html</file> directory under your home directory.  You should
 do this on <tt>klecker.debian.org</tt>. Any material you put in those areas
 are accessible via the URL
@@ -980,10 +980,10 @@ be moved in <file>4-day</file>). This feature is particularly useful
 for people who are doing non-maintainer uploads. Instead of
 waiting before uploading a NMU, it is uploaded as soon as it is
 ready but in one of those <file>DELAYED/<var>x</var>-day</file> directories.
-That leaves the corresponding number of days to the maintainer
-in order to react and upload himself another fix if he is not
-completely satisfied with the NMU. Alternatively he can remove
-the NMU by himself.
+That leaves the corresponding number of days for the maintainer
+to react and upload another fix themselves if they are not
+completely satisfied with the NMU. Alternatively they can remove
+the NMU.
 	<p>
 The use of that delayed feature can be simplified with a bit
 of integration with your upload tool.  For instance, if you use 
@@ -1042,7 +1042,7 @@ the <prgn>grep-excuses</prgn> program part of the
 to keep someone informed of the progression of his packages in testing.
 	<p>
 The <file>update_excuses</file> file does not always give the precise reason
-why the package is refused, one may have to find it by himself by looking
+why the package is refused, one may have to find it on their own by looking
 what would break with the inclusion of the package. The <url
 id="&url-testing-faq;" name="testing FAQ"> gives some more information
 about the usual problems which may be causing such troubles.
@@ -1057,8 +1057,8 @@ contacted, and he will force the inclusion of the packages.
 
       <sect1 id="pkg-info-web">On the web
 	<p>
-Each package has several dedicated web pages that contains many
-informations. <tt>http://&packages-host;/<var>package-name</var></tt>
+Each package has several dedicated web pages that contain a lot of
+information. <tt>http://&packages-host;/<var>package-name</var></tt>
 will display each version of the package
 available in the various distributions.  The per-version detailed
 information includes the package description,
@@ -1831,8 +1831,8 @@ Make sure your patch is as small and as non-disruptive as it can be.
 	    <item>
 Upload your package to incoming in <file>DELAYED/7-day</file> (cf.
 <ref id="delayed-incoming">), send the final patch to the maintainer via
-the BTS, and explain him that he has 7 days to react if he wants to cancel
-the NMU.
+the BTS, and explain to them that they have 7 days to react if they want
+to cancel the NMU.
 	    <item>
 Follow what happens, you're responsible for any bug that you introduced
 with your NMU. You should probably use <ref id="pkg-tracking-system"> (PTS)
@@ -1972,10 +1972,10 @@ BTS or by adding the required <tt>closes: #nnnn</tt> in the changelog
 entry of your next upload.
 	<p>
 In any case, you should not be upset by the NMU. An NMU is not a
-personal attack against the maintainer. It is just the proof that
-someone cares enough about the package and was willing to help
-you in your work. You should be thankful to him and you may want to
-ask him if he would be interested to help you on a more frequent
+personal attack against the maintainer. It is a proof that
+someone cares enough about the package and that they were willing to help
+you in your work, so you should be thankful. You may also want to
+ask them if they would be interested to help you on a more frequent
 basis as co-maintainer or backup maintainer
 (see <ref id="collaborative-maint">).
 
@@ -2400,8 +2400,8 @@ automatically once you upload a new version with an updated
 <tt>Maintainer:</tt> field, although it can take a few hours after the
 upload is done. If you do not expect to upload a new version for a while,
 you can use <ref id="pkg-tracking-system"> to get the bug reports. However,
-make sure that the old maintainer is not embarrassed by the fact that
-he will continue to receive the bugs during that time.
+make sure that the old maintainer has no problem with the fact that
+they will continue to receive the bugs during that time.
 
 
     <sect id="bug-handling">Handling package bugs
@@ -2481,7 +2481,7 @@ give an informative error message. This is an issue that may need
 to be brought to the upstream author.
     <p>
 If the bug submitter disagree with your decision to close the bug,
-he may reopen it until you find an agreement on how to handle it.
+they may reopen it until you find an agreement on how to handle it.
 If you don't find any, you may want to tag the bug <tt>wontfix</tt>
 to let people know that the bug exists but that it won't be corrected.
 If this situation is unacceptable, you (or the submitter) may want to
@@ -2691,8 +2691,8 @@ automatically done by <prgn>dh_installdebconf</prgn> (package
 do the same with <prgn>debconf-mergetemplate</prgn>
 (package <package>debconf-utils</package>). 
 	<p>
-When the package maintainer needs to update the templates file, he only
-changes <file>debian/templates</file>.  When English strings in this file
+When the package maintainer needs to update the templates file, they only
+change <file>debian/templates</file>.  When English strings in this file
 and in <file>debian/templates.xx</file> differ, translators do know that
 their translation is outdated.
 	<p>
@@ -2786,7 +2786,7 @@ It is something that you must read if you decide to use debconf.
 	    <p>
 The description of the package (as defined by the corresponding field
 in the <file>control</file> file) is usually the first information
-available to the user before he installs it. As such, it should
+available to the user before they install it. As such, it should
 provide all the required information to let him decide whether
 to install the package.
 	    <p>
@@ -2890,8 +2890,8 @@ If you do not get a reply after a few weeks you should collect all
 useful information about this maintainer. Start by logging into 
 the <url id="&url-debian-db;" name="Debian Developer's Database">
 and doing a full search to check whether the maintainer is on vacation
-and when he was last seen. Collect any important package names
-he maintains and any Release Critical bugs filled against them.
+and when they were last seen. Collect any important package names
+they maintain and any Release Critical bugs filed against them.
       <p>
 Send all this information to &email-debian-qa;, in order to let the 
 QA people do whatever is needed.
@@ -2911,7 +2911,7 @@ email the maintainer, whatever their individual email address (or
 addresses) may be.  Replace <tt>&lt;package&gt;</tt> with the name of
 a source or a binary package.
       <p>
-You may also be interested by contacting the persons who are
+You may also be interested in contacting the persons who are
 subscribed to a given source package via <ref id="pkg-tracking-system">.
 You can do so by using the <tt>&lt;package-name&gt;@&pts-host;</tt>
 email address.
@@ -2962,9 +2962,9 @@ You can not simply upload a binary <file>.deb</file> from the sponsoree. In
 theory, you should only ask only for the diff file, and the location of the
 original source tarball, and then you should download the source and apply
 the diff yourself. In practice, you may want to use the source package
-built by your sponsoree. In that case you have to check that he hasn't
-altered the upstream files in the <file>.orig.tar.gz</file> file that he's
-providing.
+built by your sponsoree. In that case, you have to check that they haven't
+altered the upstream files in the <file>.orig.tar.gz</file> file that
+they're providing.
 	<p>
 Do not be afraid to write the sponsoree back and point out changes
 that need to be made.  It often takes several rounds of back-and-forth