BZ #14833: message.texi typo fixes

diff --git a/ChangeLog b/ChangeLog
index 80c873c43670df8f57dbcbf6d7e00a2f2f60953a..fb3c24cb9ede2253a020fd8f90a410cc8d56a39f 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2012-12-08  Benno Schulenberg <bensberg@justemail.net>
+
+       [BZ #14833]
+       * menual/message.texi (Message Translation): Fix typos.
+       (Helper programs for gettext): Likewise.
+
 2012-12-07  Andreas Schwab  <schwab@linux-m68k.org>
 
        [BZ #14898]

diff --git a/NEWS b/NEWS
index 756019a9a73012d6078f97350dd5a4f656c98678..5c5224eccde60b2aea9717976d458082441f8d34 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -21,8 +21,9 @@ Version 2.17
   14587, 14595, 14602, 14610, 14621, 14638, 14645, 14648, 14652, 14660,
   14661, 14669, 14672, 14683, 14694, 14716, 14719, 14743, 14767, 14783,
   14784, 14785, 14793, 14796, 14797, 14801, 14803, 14805, 14807, 14811,
-  14815, 14821, 14822, 14824, 14828, 14831, 14835, 14838, 14856, 14863,
-  14865, 14866, 14868, 14869, 14871, 14879, 14889, 14893, 14898, 14914.
+  14815, 14821, 14822, 14824, 14828, 14831, 14833, 14835, 14838, 14856,
+  14863, 14865, 14866, 14868, 14869, 14871, 14879, 14889, 14893, 14898,
+  14914.
 
 * CVE-2011-4609 svc_run() produces high cpu usage when accept fails with
   EMFILE has been fixed (Bugzilla #14889).

diff --git a/manual/message.texi b/manual/message.texi
index 6f51918673d170ec1941d9bab536317d5f147213..2b186ee11926c5520c85731c372dcc51003701e0 100644 (file)
--- a/manual/message.texi
+++ b/manual/message.texi
@@ -8,12 +8,12 @@ whatever language the user prefers.
 
 Printing messages in different languages can be implemented in different
 ways.  One could add all the different languages in the source code and
-add among the variants every time a message has to be printed.  This is
-certainly no good solution since extending the set of languages is
-difficult (the code must be changed) and the code itself can become
+choose among the variants every time a message has to be printed.  This is
+certainly not a good solution since extending the set of languages is
+cumbersome (the code must be changed) and the code itself can become
 really big with dozens of message sets.
 
-A better solution is to keep the message sets for each language are kept
+A better solution is to keep the message sets for each language
 in separate files which are loaded at runtime depending on the language
 selection of the user.
 
@@ -32,7 +32,7 @@ of the message handling functions are
 
 @itemize @bullet
 @item
-locate the external data file with the appropriate translations.
+locate the external data file with the appropriate translations
 @item
 load the data and make it possible to address the messages
 @item
@@ -1799,16 +1799,16 @@ available.
 
 The @code{xgettext} program can be used to automatically extract the
 translatable messages from a source file.  I.e., the programmer need not
-take care for the translations and the list of messages which have to be
+take care of the translations and the list of messages which have to be
 translated.  S/He will simply wrap the translatable string in calls to
 @code{gettext} et.al and the rest will be done by @code{xgettext}.  This
-program has a lot of option which help to customize the output or do
+program has a lot of options which help to customize the output or
 help to understand the input better.
 
-Other programs help to manage development cycle when new messages appear
-in the source files or when a new translation of the messages appear.
+Other programs help to manage the development cycle when new messages appear
+in the source files or when a new translation of the messages appears.
 Here it should only be noted that using all the tools in GNU gettext it
 is possible to @emph{completely} automate the handling of message
-catalog.  Beside marking the translatable string in the source code and
+catalogs.  Beside marking the translatable strings in the source code and
 generating the translations the developers do not have anything to do
 themselves.