BZ#14336: Manual spelling fixes.

3 files changed, 14 insertions, 5 deletions

diff --git a/ChangeLog b/ChangeLog
index 5291b24fe8..c7070c57c1 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2012-07-09  Roland McGrath  <roland@hack.frob.com>
+
+	[BZ #14336]
+	* manual/charset.texi (Extended Char Intro): Word use fix, "operating
+	system".
+	* manual/message.texi (The Uniforum approach): Likewise.
+	* manual/charset.texi (Extended Char Intro): Spelling fix, "affected".
+	(glibc iconv Implementation): Likewise.
+
 2012-07-09  Joseph Myers  <joseph@codesourcery.com>
 
 	[BZ #14337]
diff --git a/manual/charset.texi b/manual/charset.texi
index 97fb2bed2d..e21502e5c8 100644
--- a/manual/charset.texi
+++ b/manual/charset.texi
@@ -204,7 +204,7 @@ defined in @file{wchar.h}.
 
 These internal representations present problems when it comes to storing
 and transmittal.  Because each single wide character consists of more
-than one byte, they are effected by byte-ordering.  Thus, machines with
+than one byte, they are affected by byte-ordering.  Thus, machines with
 different endianesses would see different values when accessing the same
 data.  This byte ordering concern also applies for communication protocols
 that are all byte-based and therefore require that the sender has to
@@ -225,7 +225,7 @@ fulfill one requirement: they are "filesystem safe."  This means that
 the character @code{'/'} is used in the encoding @emph{only} to
 represent itself.  Things are a bit different for character sets like
 EBCDIC (Extended Binary Coded Decimal Interchange Code, a character set
-family used by IBM), but if the operation system does not understand
+family used by IBM), but if the operating system does not understand
 EBCDIC directly the parameters-to-system calls have to be converted
 first anyhow.
 
@@ -257,7 +257,7 @@ state changes that cover more than the next character.  This has the
 big advantage that whenever one can identify the beginning of the byte
 sequence of a character one can interpret a text correctly.  Examples of
 character sets using this policy are the various EUC character sets
-(used by Sun's operations systems, EUC-JP, EUC-KR, EUC-TW, and EUC-CN)
+(used by Sun's operating systems, EUC-JP, EUC-KR, EUC-TW, and EUC-CN)
 or Shift_JIS (SJIS, a Japanese encoding).
 
 But there are also character sets using a state that is valid for more
@@ -2225,7 +2225,7 @@ become clear that this is the name for the representation used in the
 intermediate step of the triangulation.  We have said that this is UCS-4
 but actually that is not quite right.  The UCS-4 specification also
 includes the specification of the byte ordering used.  Since a UCS-4 value
-consists of four bytes, a stored value is effected by byte ordering.  The
+consists of four bytes, a stored value is affected by byte ordering.  The
 internal representation is @emph{not} the same as UCS-4 in case the byte
 ordering of the processor (or at least the running process) is not the
 same as the one required for UCS-4.  This is done for performance reasons
diff --git a/manual/message.texi b/manual/message.texi
index 3fc6d249f0..f65123c9f8 100644
--- a/manual/message.texi
+++ b/manual/message.texi
@@ -727,7 +727,7 @@ for @code{catopen} presented in the description above.
 
 Sun Microsystems tried to standardize a different approach to message
 translation in the Uniforum group.  There never was a real standard
-defined but still the interface was used in Sun's operation systems.
+defined but still the interface was used in Sun's operating systems.
 Since this approach fits better in the development process of free
 software it is also used throughout the GNU project and the GNU
 @file{gettext} package provides support for this outside @theglibc{}.