manual: fix spelling typos
I've bracketed the changes to make it easier to pick out. enlengthen -> extend enlengthened -> extended excep[e]tions -> exceptions exten[da]ble -> exten[si]ble implement[o]r -> implement[e]r licen[c]e -> licen[s]e optimzed -> optim[i]zed overriden -> overrid[d]en param[a]ter -> param[e]ter Signed-off-by: Mike Frysinger <vapier@gentoo.org> 2012-10-27 Mike Frysinger <vapier@gentoo.org> * manual/arith.texi: Fix spelling typos. * manual/contrib.texi: Likewise. * manual/crypt.texi: Likewise. * manual/filesys.texi: Likewise. * manual/llio.texi: Likewise. * manual/locale.texi: Likewise. * manual/message.texi: Likewise. * manual/nss.texi: Likewise. * manual/socket.texi: Likewise. * manual/stdio.texi: Likewise. * manual/string.texi: Likewise. * manual/sysinfo.texi: Likewise.
This commit is contained in:
Mike Frysinger
parent
4706240f52
commit
ef48b19677
10
ChangeLog
10
ChangeLog
|
|
@ -1,3 +1,13 @@
|
|||
2016-06-16 Mike Frysinger <vapier@gentoo.org>
|
||||
|
||||
* manual/contrib.texi: Fix spelling typos.
|
||||
* manual/crypt.texi: Likewise.
|
||||
* manual/filesys.texi: Likewise.
|
||||
* manual/locale.texi: Likewise.
|
||||
* manual/message.texi: Likewise.
|
||||
* manual/nss.texi: Likewise.
|
||||
* manual/string.texi: Likewise.
|
||||
|
||||
2016-06-16 Rical Jasan <ricaljasan@pacific.net>
|
||||
|
||||
* manual/locale.texi: Fix typos & grammar errors.
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ Thomas Bushnell for his contributions to Hurd.
|
|||
Wilco Dijkstra for various fixes.
|
||||
|
||||
@item
|
||||
Liubov Dmitrieva for optimzed string and math functions on x86-64 and
|
||||
Liubov Dmitrieva for optimized string and math functions on x86-64 and
|
||||
x86.
|
||||
|
||||
@item
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ to provide a definitive survey of the laws affecting cryptography.
|
|||
Instead, this section warns you of some of the known trouble spots; this
|
||||
may help you when you try to find out what the laws of your country are.
|
||||
|
||||
Some countries require that you have a licence to use, possess, or import
|
||||
Some countries require that you have a license to use, possess, or import
|
||||
cryptography. These countries are believed to include Byelorussia,
|
||||
Burma, India, Indonesia, Israel, Kazakhstan, Pakistan, Russia, and Saudi
|
||||
Arabia.
|
||||
|
|
|
|||
|
|
@ -885,7 +885,7 @@ of the following categories. This could be special files, sockets etc.
|
|||
The item is a directory.
|
||||
@item FTW_NS
|
||||
The @code{stat} call failed and so the information pointed to by the
|
||||
second paramater is invalid.
|
||||
second parameter is invalid.
|
||||
@item FTW_DNR
|
||||
The item is a directory which cannot be read.
|
||||
@item FTW_SL
|
||||
|
|
|
|||
|
|
@ -613,7 +613,7 @@ as far as the system follows the Unix standards.
|
|||
|
||||
Together with the @code{setlocale} function the @w{ISO C} people
|
||||
invented the @code{localeconv} function. It is a masterpiece of poor
|
||||
design. It is expensive to use, not extendable, and not generally
|
||||
design. It is expensive to use, not extensible, and not generally
|
||||
usable as it provides access to only @code{LC_MONETARY} and
|
||||
@code{LC_NUMERIC} related information. Nevertheless, if it is
|
||||
applicable to a given situation it should be used since it is very
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ industry decisions and therefore not necessarily based on reasonable
|
|||
decisions.
|
||||
|
||||
As mentioned above the message catalog handling provides easy
|
||||
extendibility by using external data files which contain the message
|
||||
extendability by using external data files which contain the message
|
||||
translations. I.e., these files contain for each of the messages used
|
||||
in the program a translation for the appropriate language. So the tasks
|
||||
of the message handling functions are
|
||||
|
|
@ -1639,12 +1639,12 @@ family. But in two places the string passed into the function would be
|
|||
@code{Open}. The translations might not be the same and therefore we
|
||||
are in the dilemma described above.
|
||||
|
||||
One solution to this problem is to artificially enlengthen the strings
|
||||
One solution to this problem is to artificially extend the strings
|
||||
to make them unambiguous. But what would the program do if no
|
||||
translation is available? The enlengthened string is not what should be
|
||||
translation is available? The extended string is not what should be
|
||||
printed. So we should use a little bit modified version of the functions.
|
||||
|
||||
To enlengthen the strings a uniform method should be used. E.g., in the
|
||||
To extend the strings a uniform method should be used. E.g., in the
|
||||
example above the strings could be chosen as
|
||||
|
||||
@smallexample
|
||||
|
|
@ -1681,7 +1681,7 @@ for the Menu entries and therefore contains a @code{|} character. We
|
|||
simply search for the last occurrence of this character and return a
|
||||
pointer to the character following it. That's it!
|
||||
|
||||
If one now consistently uses the enlengthened string form and replaces
|
||||
If one now consistently uses the extended string form and replaces
|
||||
the @code{gettext} calls with calls to @code{sgettext} (this is normally
|
||||
limited to very few places in the GUI implementation) then it is
|
||||
possible to produce a program which can be internationalized.
|
||||
|
|
@ -1716,7 +1716,7 @@ with the second part which is:
|
|||
@item
|
||||
There is no way the C library can contain a version which can work
|
||||
everywhere. The problem is the selection of the character to separate
|
||||
the prefix from the actual string in the enlenghtened string. The
|
||||
the prefix from the actual string in the extended string. The
|
||||
examples above used @code{|} which is a quite good choice because it
|
||||
resembles a notation frequently used in this context and it also is a
|
||||
character not often used in message strings.
|
||||
|
|
@ -1728,7 +1728,7 @@ why the @file{iso646.h} file exists in @w{ISO C} programming environments).
|
|||
@end itemize
|
||||
|
||||
There is only one more comment to make left. The wrapper function above
|
||||
require that the translations strings are not enlengthened themselves.
|
||||
require that the translations strings are not extended themselves.
|
||||
This is only logical. There is no need to disambiguate the strings
|
||||
(since they are never used as keys for a search) and one also saves
|
||||
quite some memory and disk space by doing this.
|
||||
|
|
|
|||
|
|
@ -566,7 +566,7 @@ here only important to remember that adding another database is
|
|||
independent from adding another service because a service need not
|
||||
support all databases or lookup functions.
|
||||
|
||||
A designer/implementor of a new service is therefore free to choose the
|
||||
A designer/implementer of a new service is therefore free to choose the
|
||||
databases s/he is interested in and leave the rest for later (or
|
||||
completely aside).
|
||||
|
||||
|
|
|
|||
|
|
@ -2300,7 +2300,7 @@ The GNU version of the @code{basename} function returns the last
|
|||
component of the path in @var{filename}. This function is the preferred
|
||||
usage, since it does not modify the argument, @var{filename}, and
|
||||
respects trailing slashes. The prototype for @code{basename} can be
|
||||
found in @file{string.h}. Note, this function is overriden by the XPG
|
||||
found in @file{string.h}. Note, this function is overridden by the XPG
|
||||
version, if @file{libgen.h} is included.
|
||||
|
||||
Example of using GNU @code{basename}:
|
||||
|
|
|
|||
Loading…
Reference in New Issue