1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
|
Notes on the GNU Translation Project
************************************
GNU is going international! The GNU Translation Project is a way to
get maintainers, translators, and users all together, so that GNU will
gradually become able to speak many languages. A few packages already
provide translations for their messages.
If you found this `ABOUT-NLS' file inside a GNU distribution, you
may assume that the distributed package does use GNU `gettext'
internally, itself available at your nearest GNU archive site. But you
do *not* need to install GNU `gettext' prior to configuring, installing
or using this package with messages translated.
Installers will find here some useful hints. These notes also
explain how users should proceed for getting the programs to use the
available translations. They tell how people wanting to contribute and
work at translations should contact the appropriate team.
When reporting bugs in the `intl/' directory or bugs which may be
related to internationalization, you should tell about the version of
`gettext' which is used. The information can be found in the
`intl/VERSION' file, in internationalized packages.
One advise in advance
=====================
If you want to exploit the full power of internationalization, you
should configure it using
./configure --with-gnu-gettext
to force usage of internationalizing routines provided within this
package, despite the existence of internationalizing capabilities in
the operating system where this package is being installed. So far, no
prior implementation provides as many useful features (such as locale
alias or message inheritance). It is also not possible to offer this
additional functionality on top of a `catgets' implementation. Future
versions of GNU `gettext' will very likely convey even more
functionality. So it might be a good idea to change to GNU `gettext'
as soon as possible.
INSTALL Matters
===============
Some GNU packages are "localizable" when properly installed; the
programs they contain can be made to speak your own native language.
Most such packages use GNU `gettext'. Other packages have their own
ways to internationalization, predating GNU `gettext'.
By default, this package will be installed to allow translation of
messages. It will automatically detect whether the system provides
usable `catgets' (if using this is selected by the installer) or
`gettext' functions. If neither is available, the GNU `gettext' own
library will be used. This library is wholly contained within this
package, usually in the `intl/' subdirectory, so prior installation of
the GNU `gettext' package is *not* required. Installers may use
special options at configuration time for changing the default
behaviour. The commands:
./configure --with-gnu-gettext
./configure --with-catgets
./configure --disable-nls
will respectively bypass any pre-existing `catgets' or `gettext' to use
the internationalizing routines provided within this package, enable
the use of the `catgets' functions (if found on the locale system), or
else, *totally* disable translation of messages.
When you already have GNU `gettext' installed on your system and run
configure without an option for your new package, `configure' will
probably detect the previously built and installed `libintl.a' file and
will decide to use this. This might be not what is desirable. You
should use the more recent version of the GNU `gettext' library. I.e.
if the file `intl/VERSION' shows that the library which comes with this
package is more recent, you should use
./configure --with-gnu-gettext
to prevent auto-detection.
By default the configuration process will not test for the `catgets'
function and therefore they will not be used. The reasons are already
given above: the emulation on top of `catgets' cannot provide all the
extensions provided by the GNU `gettext' library. If you nevertheless
want to use the `catgets' functions use
./configure --with-catgets
to enable the test for `catgets' (this causes no harm if `catgets' is
not available on your system). If you really select this option we
would like to hear about the reasons because we cannot think of any
good one ourself.
Internationalized packages have usually many `po/LL.po' files, where
LL gives an ISO 639 two-letter code identifying the language. Unless
translations have been forbidden at `configure' time by using the
`--disable-nls' switch, all available translations are installed
together with the package. However, the environment variable `LINGUAS'
may be set, prior to configuration, to limit the installed set.
`LINGUAS' should then contain a space separated list of two-letter
codes, stating which languages are allowed.
Using This Package
==================
As a user, if your language has been installed for this package, you
only have to set the `LANG' environment variable to the appropriate
ISO 639 `LL' two-letter code prior to using the programs in the
package. For example, let's suppose that you speak German. At the
shell prompt, merely execute `setenv LANG de' (in `csh'),
`export LANG; LANG=de' (in `sh') or `export LANG=de' (in `bash'). This
can be done from your `.login' or `.profile' file, once and for all.
An operating system might already offer message localization for
many of its programs, while other programs (whether GNU or not) have
been installed locally with the full capabilities of GNU `gettext'.
Just using `gettext' extended syntax for `LANG' would break proper
localization of already available operating system programs. In this
case, users should set both `LANGUAGE' and `LANG' variables in their
environment, as programs using GNU `gettext' give preference to
`LANGUAGE'. For example, some Swedish users would rather read
translations in German than English for when Swedish is not available.
This is easily accomplished by setting `LANGUAGE' to `sv:de' while
leaving `LANG' to `sv'.
Translating Teams
=================
For the GNU Translation Project to be a success, we need interested
people who like their own language and write it well, and who are also
able to synergize with other translators speaking the same language.
Each translation team has its own mailing list, courtesy of Linux
International. You may reach your translation team at the address
`LL@li.org', replacing LL by the two-letter ISO 639 code for your
language. Language codes are *not* the same as the country codes given
in ISO 3166. The following translation teams exist, as of May 1996:
Arabic `ar', Chinese `zh', Czech `cs', Danish `da', Dutch `nl',
English `en', Esperanto `eo', Finnish `fi', French `fr', German
`de', Greek `el', Hebrew `he', Hungarian `hu', Irish `ga', Italian
`it', Indonesian `id', Japanese `ja', Korean `ko', Latin `la',
Norwegian `no', Persian `fa', Polish `pl', Portuguese `pt',
Russian `ru', Slovenian `sl', Spanish `es', Swedish `sv', Telugu
`te', Turkish `tr' and Ukrainian `uk'.
For example, you may reach the Chinese translation team by writing to
`zh@li.org'.
If you'd like to volunteer to *work* at translating messages, you
should become a member of the translating team for your own language.
The subscribing address is *not* the same as the list itself, it has
`-request' appended. For example, speakers of Swedish can send a
message to `sv-request@li.org', having this message body:
subscribe
Keep in mind that team members are expected to participate
*actively* in translations, or at solving translational difficulties,
rather than merely lurking around. If your team does not exist yet and
you want to start one, or if you are unsure about what to do or how to
get started, please write to `gnu-translation@gnu.ai.mit.edu' to reach
the GNU coordinator for all translator teams.
The English team is special. It works at improving and uniformizing
the terminology used in GNU. Proven linguistic skill are praised more
than programming skill, here. For the time being, please avoid
subscribing to the English team unless explicitly invited to do so.
Available Packages
==================
Languages are not equally supported in all GNU packages. The
following matrix shows the current state of GNU internationalization,
as of May 1996. The matrix shows, in regard of each package, for which
languages PO files have been submitted to translation coordination.
cs de en es fi fr ja ko no pt sl sv
.-------------------------------------.
bash | [] | 1
bison | | 0
clisp | [] [] [] | 3
cpio | [] | 1
diffutils | [] [] | 2
enscript | [] [] [] [] | 4
fileutils | [] [] [] | 3
findutils | [] [] | 2
flex | [] | 1
gettext | [] [] [] [] [] | 6
glibc | [] [] [] | 3
grep | [] [] [] [] | 4
hello | [] [] [] [] | 4
m4 | [] [] [] [] | 4
make | | 0
mkid | [] [] | 2
music | [] | 1
ptx | [] [] [] | 3
recode | [] [] [] [] [] | 5
sh-utils | [] [] | 2
sharutils | [] [] [] | 3
tar | [] [] [] [] [] [] [] | 7
textutils | [] [] [] | 3
wdiff | [] [] [] [] | 4
`-------------------------------------'
cs de en es fi fr ja ko no pt sl sv
1 16 1 3 1 21 1 6 3 1 5 9
For a PO file in the matrix above to be effective, the package to
which it applies should also have been internationalized and distributed
as such by its maintainer. There is often a lag between the mere
existence a PO file and its wide availability in a GNU distribution.
If May 1996 seems to be old, you may fetch a more recent copy of
this `ABOUT-NLS' file on most GNU archive sites.
|
