gettext doc patch

[Ben Elliston]

I believe the current gettext maintainer is Bruno Haible, but I have
been unable to contact him by email (does anyone know a working
address?)  I would like to submit the following patch to the gettext
documentation.


2001-12-07  Ben Elliston  <address@hidden>

        * gettext.texi (Overview): Grammar fixes.
        (PO Files): Likewise.

diff -r -u gettext-0.10.40/doc/gettext.texi 
gettext-0.10.40-patched/doc/gettext.texi
--- gettext-0.10.40/doc/gettext.texi    Sun Sep  9 23:38:35 2001
+++ gettext-0.10.40-patched/doc/gettext.texi    Mon Dec 10 11:22:16 2001
@@ -573,12 +573,12 @@
 @node Overview,  , Files, Introduction
 @section Overview of GNU @code{gettext}
 
-The following diagram summarizes the relation between the files
-handled by GNU @code{gettext} and the tools acting on these files.
-It is followed by a somewhat detailed explanations, which you should
-read while keeping an eye on the diagram.  Having a clear understanding
-of these interrelations would surely help programmers, translators
-and maintainers.
+The following diagram summarizes the relation between the files handled
+by GNU @code{gettext} and the tools acting on these files.  It is
+followed by somewhat detailed explanations, which you should read while
+keeping an eye on the diagram.  Having a clear understanding of these
+interrelations will surely help programmers, translators and
+maintainers.
 
 @example
 @group
@@ -707,13 +707,13 @@
 
 Programs, or packages of programs, are dynamic in nature: users write
 bug reports and suggestion for improvements, maintainers react by
-modifying programs in various ways.  The fact that a package has
-already been internationalized should not make maintainers shy
-of adding new strings, or modifying strings already translated.
-They just do their job the best they can.  For the Translation
-Project to work smoothly, it is important that maintainers do not
-carry translation concerns on their already loaded shoulders, and that
-translators be kept as free as possible of programmatic concerns.
+modifying programs in various ways.  The fact that a package has already
+been internationalized should not make maintainers shy of adding new
+strings, or modifying strings already translated.  They just do their
+job the best they can.  For the Translation Project to work smoothly, it
+is important that maintainers do not carry translation concerns on their
+already loaded shoulders, and that translators be kept as free as
+possible of programming concerns.
 
 The only concern maintainers should have is carefully marking new
 strings as translatable, when they should be, and do not otherwise
@@ -756,21 +756,20 @@
 Translation Project, or will give a hard time to other participants!  In
 particular, maintainers should relax and include all available official
 PO files in their distributions, even if these have not recently been
-updated, without banging or otherwise trying to exert pressure on the
-translator teams to get the job done.  The pressure should rather come
-from the community of users speaking a particular language, and
-maintainers should consider themselves fairly relieved of any concern
-about the adequacy of translation files.  On the other hand, translators
-should reasonably try updating the PO files they are responsible for,
-while the package is undergoing pretest, prior to an official
-distribution.
+updated, without exerting pressure on the translator teams to get the
+job done.  The pressure should rather come from the community of users
+speaking a particular language, and maintainers should consider
+themselves fairly relieved of any concern about the adequacy of
+translation files.  On the other hand, translators should reasonably try
+updating the PO files they are responsible for, while the package is
+undergoing pretest, prior to an official distribution.
 
 Once the PO file is complete and dependable, the @code{msgfmt} program
 is used for turning the PO file into a machine-oriented format, which
 may yield efficient retrieval of translations by the programs of the
 package, whenever needed at runtime (@pxref{MO Files}).  @xref{msgfmt
-Invocation}, for more information about all modalities of execution
-for the @code{msgfmt} program.
+Invocation}, for more information about all modes of execution for the
address@hidden program.
 
 Finally, the modified and marked C sources are compiled and linked
 with the GNU @code{gettext} library, usually through the operation of
@@ -919,7 +918,7 @@
 @item c-format
 @itemx no-c-format
 These flags should not be added by a human.  Instead only the
address@hidden program adds them.  In an automatized PO file processing
address@hidden program adds them.  In an automated PO file processing
 system as proposed here the user changes would be thrown away again as
 soon as the @code{xgettext} program generates a new template file.
 
@@ -958,11 +957,11 @@
 
 Each of @var{untranslated-string} and @var{translated-string} respects
 the C syntax for a character string, including the surrounding quotes
-and imbedded backslashed escape sequences.  When the time comes
-to write multi-line strings, one should not use escaped newlines.
-Instead, a closing quote should follow the last character on the
-line to be continued, and an opening quote should resume the string
-at the beginning of the following PO file line.  For example:
+and embedded backslashed escape sequences.  When the time comes to write
+multi-line strings, one should not use escaped newlines.  Instead, a
+closing quote should follow the last character on the line to be
+continued, and an opening quote should resume the string at the
+beginning of the following PO file line.  For example:
 
 @example
 msgid ""
@@ -1064,14 +1063,15 @@
 can undo the edition work quite parsimoniously.
 
 The commands @kbd{Q} (@code{po-quit}) and @kbd{q}
-(@code{po-confirm-and-quit}) are used when the translator is done with the
-PO file.  The former is a bit less verbose than the latter.  If the file
-has been modified, it is saved to disk first.  In both cases, and prior to
-all this, the commands check if some untranslated message remains in the
-PO file and, if yes, the translator is asked if she really wants to leave
-off working with this PO file.  This is the preferred way of getting rid
-of an Emacs PO file buffer.  Merely killing it through the usual command
address@hidden@kbd{C-x k}} (@code{kill-buffer}) is not the tidiest way to 
proceed.
+(@code{po-confirm-and-quit}) are used when the translator is done with
+the PO file.  The former is a bit less verbose than the latter.  If the
+file has been modified, it is saved to disk first.  In both cases, and
+prior to all this, the commands check if any untranslated messages
+remain in the PO file and, if so, the translator is asked if she really
+wants to leave off working with this PO file.  This is the preferred way
+of getting rid of an Emacs PO file buffer.  Merely killing it through
+the usual command @address@hidden k}} (@code{kill-buffer}) is not the
+tidiest way to proceed.
 
 The command @kbd{O} (@code{po-other-window}) is another, softer way,
 to leave PO mode, temporarily.  It just moves the cursor to some other
@@ -2390,16 +2390,16 @@
 @node Modifying Translations, Modifying Comments, Obsolete Entries, Updating
 @section Modifying Translations
 
-PO mode prevents direct edition of the PO file, by the usual
-means Emacs give for altering a buffer's contents.  By doing so,
-it pretends helping the translator to avoid little clerical errors
-about the overall file format, or the proper quoting of strings,
-as those errors would be easily made.  Other kinds of errors are
-still possible, but some may be caught and diagnosed by the batch
-validation process, which the translator may always trigger by the
address@hidden command.  For all other errors, the translator has to rely on
-her own judgment, and also on the linguistic reports submitted to her
-by the users of the translated package, having the same mother tongue.
+PO mode prevents direct modification of the PO file, by the usual means
+Emacs gives for altering a buffer's contents.  By doing so, it pretends
+helping the translator to avoid little clerical errors about the overall
+file format, or the proper quoting of strings, as those errors would be
+easily made.  Other kinds of errors are still possible, but some may be
+caught and diagnosed by the batch validation process, which the
+translator may always trigger by the @kbd{V} command.  For all other
+errors, the translator has to rely on her own judgment, and also on the
+linguistic reports submitted to her by the users of the translated
+package, having the same mother tongue.
 
 When the time comes to create a translation, correct an error diagnosed
 mechanically or reported by a user, the translators have to resort to