From 6c55cda37a1ad5e39fc7dc2eac8c3bc07fb1be8f Mon Sep 17 00:00:00 2001 From: Roland McGrath Date: Mon, 9 Jul 2012 04:41:13 -0700 Subject: [PATCH] BZ#14336: Manual spelling fixes. --- ChangeLog | 9 +++++++++ manual/charset.texi | 8 ++++---- manual/message.texi | 2 +- 3 files changed, 14 insertions(+), 5 deletions(-) diff --git a/ChangeLog b/ChangeLog index 5291b24..c7070c5 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,12 @@ +2012-07-09 Roland McGrath + + [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 [BZ #14337] diff --git a/manual/charset.texi b/manual/charset.texi index 97fb2be..e21502e 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 3fc6d24..f65123c 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{}. -- 2.7.4