]> git.ipfire.org Git - thirdparty/gettext.git/commitdiff
Stylistic improvements, from Benno Schulenberg.
authorBruno Haible <bruno@clisp.org>
Mon, 10 Mar 2008 22:58:02 +0000 (22:58 +0000)
committerBruno Haible <bruno@clisp.org>
Tue, 23 Jun 2009 10:15:38 +0000 (12:15 +0200)
gettext-tools/doc/ChangeLog
gettext-tools/doc/gettext.texi

index de887ad03608c331c103616da12282378bd2b51a..6ba90516fcfda50c20a4a7c80f3e3e13e4261b2c 100644 (file)
@@ -1,3 +1,7 @@
+2008-02-02  Benno Schulenberg <bensberg@justemail.net>
+
+       * gettext.texi (PO Files): Stylistic improvements.
+
 2008-01-12  Bruno Haible  <bruno@clisp.org>
 
        * msgfilter.texi: Fix last example.
index 0c3a2dd0872a98e99fe399d023fceac1e22f217d..cb66dc2f248e25dad704dc7392df61dd97f1c505 100644 (file)
@@ -1472,16 +1472,16 @@ search only.  @xref{Fuzzy Entries}.
 @kwindex no-c-format@r{ flag}
 These flags should not be added by a human.  Instead only the
 @code{xgettext} program adds them.  In an automated PO file processing
-system as proposed here the user changes would be thrown away again as
+system as proposed here, the user's changes would be thrown away again as
 soon as the @code{xgettext} program generates a new template file.
 
-The @code{c-format} flag tells that the untranslated string and the
+The @code{c-format} flag indicates that the untranslated string and the
 translation are supposed to be C format strings.  The @code{no-c-format}
-flag tells that they are not C format strings, even though the untranslated
+flag indicates that they are not C format strings, even though the untranslated
 string happens to look like a C format string (with @samp{%} directives).
 
-In case the @code{c-format} flag is given for a string the @code{msgfmt}
-does some more tests to check to validity of the translation.
+When the @code{c-format} flag is given for a string the @code{msgfmt}
+program does some more tests to check the validity of the translation.
 @xref{msgfmt Invocation}, @ref{c-format Flag} and @ref{c-format}.
 
 @item objc-format