[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
gettext doc patch
From: |
Ben Elliston |
Subject: |
gettext doc patch |
Date: |
Mon, 10 Dec 2001 11:35:55 +1100 (EST) |
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
- gettext doc patch,
Ben Elliston <=