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
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
|
<HTML>
<HEAD>
<!-- This HTML file has been created by texi2html 1.52b
from gettext.texi on 28 December 2015 -->
<META HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
<TITLE>GNU gettext utilities - 12 The Translator's View</TITLE>
</HEAD>
<BODY>
Go to the <A HREF="gettext_1.html">first</A>, <A HREF="gettext_11.html">previous</A>, <A HREF="gettext_13.html">next</A>, <A HREF="gettext_25.html">last</A> section, <A HREF="gettext_toc.html">table of contents</A>.
<P><HR><P>
<H1><A NAME="SEC200" HREF="gettext_toc.html#TOC200">12 The Translator's View</A></H1>
<H2><A NAME="SEC201" HREF="gettext_toc.html#TOC201">12.1 Introduction 0</A></H2>
<P>
<STRONG> NOTE: </STRONG> This documentation section is outdated and needs to be
revised.
</P>
<P>
Free software is going international! The Translation Project is a way
to get maintainers, translators and users all together, so free software
will gradually become able to speak many native languages.
</P>
<P>
The GNU <CODE>gettext</CODE> tool set contains <EM>everything</EM> maintainers
need for internationalizing their packages for messages. It also
contains quite useful tools for helping translators at localizing
messages to their native language, once a package has already been
internationalized.
</P>
<P>
To achieve the Translation Project, we need many 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.
If you'd like to volunteer to <EM>work</EM> at translating messages,
please send mail to your translating team.
</P>
<P>
Each team has its own mailing list, courtesy of Linux
International. You may reach your translating team at the address
<TT>‘<VAR>ll</VAR>@li.org’</TT>, replacing <VAR>ll</VAR> by the two-letter ISO 639
code for your language. Language codes are <EM>not</EM> the same as
country codes given in ISO 3166. The following translating teams
exist:
</P>
<BLOCKQUOTE>
<P>
Chinese <CODE>zh</CODE>, Czech <CODE>cs</CODE>, Danish <CODE>da</CODE>, Dutch <CODE>nl</CODE>,
Esperanto <CODE>eo</CODE>, Finnish <CODE>fi</CODE>, French <CODE>fr</CODE>, Irish
<CODE>ga</CODE>, German <CODE>de</CODE>, Greek <CODE>el</CODE>, Italian <CODE>it</CODE>,
Japanese <CODE>ja</CODE>, Indonesian <CODE>in</CODE>, Norwegian <CODE>no</CODE>, Polish
<CODE>pl</CODE>, Portuguese <CODE>pt</CODE>, Russian <CODE>ru</CODE>, Spanish <CODE>es</CODE>,
Swedish <CODE>sv</CODE> and Turkish <CODE>tr</CODE>.
</BLOCKQUOTE>
<P>
For example, you may reach the Chinese translating team by writing to
<TT>‘zh@li.org’</TT>. When you become a member of the translating team
for your own language, you may subscribe to its list. For example,
Swedish people can send a message to <TT>‘sv-request@li.org’</TT>,
having this message body:
</P>
<PRE>
subscribe
</PRE>
<P>
Keep in mind that team members should be interested in <EM>working</EM>
at translations, or at solving translational difficulties, rather than
merely lurking around. If your team does not exist yet and you want to
start one, please write to <TT>‘coordinator@translationproject.org’</TT>;
you will then reach the coordinator for all translator teams.
</P>
<P>
A handful of GNU packages have already been adapted and provided
with message translations for several languages. Translation
teams have begun to organize, using these packages as a starting
point. But there are many more packages and many languages for
which we have no volunteer translators. If you would like to
volunteer to work at translating messages, please send mail to
<TT>‘coordinator@translationproject.org’</TT> indicating what language(s)
you can work on.
</P>
<H2><A NAME="SEC202" HREF="gettext_toc.html#TOC202">12.2 Introduction 1</A></H2>
<P>
<STRONG> NOTE: </STRONG> This documentation section is outdated and needs to be
revised.
</P>
<P>
This is now official, GNU is going international! Here is the
announcement submitted for the January 1995 GNU Bulletin:
</P>
<BLOCKQUOTE>
<P>
A handful of GNU packages have already been adapted and provided
with message translations for several languages. Translation
teams have begun to organize, using these packages as a starting
point. But there are many more packages and many languages
for which we have no volunteer translators. If you'd like to
volunteer to work at translating messages, please send mail to
<SAMP>‘coordinator@translationproject.org’</SAMP> indicating what language(s)
you can work on.
</BLOCKQUOTE>
<P>
This document should answer many questions for those who are curious about
the process or would like to contribute. Please at least skim over it,
hoping to cut down a little of the high volume of e-mail generated by this
collective effort towards internationalization of free software.
</P>
<P>
Most free programming which is widely shared is done in English, and
currently, English is used as the main communicating language between
national communities collaborating to free software. This very document
is written in English. This will not change in the foreseeable future.
</P>
<P>
However, there is a strong appetite from national communities for
having more software able to write using national language and habits,
and there is an on-going effort to modify free software in such a way
that it becomes able to do so. The experiments driven so far raised
an enthusiastic response from pretesters, so we believe that
internationalization of free software is dedicated to succeed.
</P>
<P>
For suggestion clarifications, additions or corrections to this
document, please e-mail to <TT>‘coordinator@translationproject.org’</TT>.
</P>
<H2><A NAME="SEC203" HREF="gettext_toc.html#TOC203">12.3 Discussions</A></H2>
<P>
<STRONG> NOTE: </STRONG> This documentation section is outdated and needs to be
revised.
</P>
<P>
Facing this internationalization effort, a few users expressed their
concerns. Some of these doubts are presented and discussed, here.
</P>
<UL>
<LI>Smaller groups
Some languages are not spoken by a very large number of people, so people
speaking them sometimes consider that there may not be all that much
demand such versions of free software packages. Moreover, many people
being <EM>into computers</EM>, in some countries, generally seem to prefer
English versions of their software.
On the other end, people might enjoy their own language a lot, and be
very motivated at providing to themselves the pleasure of having their
beloved free software speaking their mother tongue. They do themselves
a personal favor, and do not pay that much attention to the number of
people benefiting of their work.
<LI>Misinterpretation
Other users are shy to push forward their own language, seeing in this
some kind of misplaced propaganda. Someone thought there must be some
users of the language over the networks pestering other people with it.
But any spoken language is worth localization, because there are
people behind the language for whom the language is important and
dear to their hearts.
<LI>Odd translations
The biggest problem is to find the right translations so that
everybody can understand the messages. Translations are usually a
little odd. Some people get used to English, to the extent they may
find translations into their own language “rather pushy, obnoxious
and sometimes even hilarious.” As a French speaking man, I have
the experience of those instruction manuals for goods, so poorly
translated in French in Korea or Taiwan...
The fact is that we sometimes have to create a kind of national
computer culture, and this is not easy without the collaboration of
many people liking their mother tongue. This is why translations are
better achieved by people knowing and loving their own language, and
ready to work together at improving the results they obtain.
<LI>Dependencies over the GPL or LGPL
Some people wonder if using GNU <CODE>gettext</CODE> necessarily brings their
package under the protective wing of the GNU General Public License or
the GNU Lesser General Public License, when they do not want to make
their program free, or want other kinds of freedom. The simplest
answer is “normally not”.
The <CODE>gettext-runtime</CODE> part of GNU <CODE>gettext</CODE>, i.e. the
contents of <CODE>libintl</CODE>, is covered by the GNU Lesser General Public
License. The <CODE>gettext-tools</CODE> part of GNU <CODE>gettext</CODE>, i.e. the
rest of the GNU <CODE>gettext</CODE> package, is covered by the GNU General
Public License.
The mere marking of localizable strings in a package, or conditional
inclusion of a few lines for initialization, is not really including
GPL'ed or LGPL'ed code. However, since the localization routines in
<CODE>libintl</CODE> are under the LGPL, the LGPL needs to be considered.
It gives the right to distribute the complete unmodified source of
<CODE>libintl</CODE> even with non-free programs. It also gives the right
to use <CODE>libintl</CODE> as a shared library, even for non-free programs.
But it gives the right to use <CODE>libintl</CODE> as a static library or
to incorporate <CODE>libintl</CODE> into another library only to free
software.
</UL>
<H2><A NAME="SEC204" HREF="gettext_toc.html#TOC204">12.4 Organization</A></H2>
<P>
<STRONG> NOTE: </STRONG> This documentation section is outdated and needs to be
revised.
</P>
<P>
On a larger scale, the true solution would be to organize some kind of
fairly precise set up in which volunteers could participate. I gave
some thought to this idea lately, and realize there will be some
touchy points. I thought of writing to Richard Stallman to launch
such a project, but feel it might be good to shake out the ideas
between ourselves first. Most probably that Linux International has
some experience in the field already, or would like to orchestrate
the volunteer work, maybe. Food for thought, in any case!
</P>
<P>
I guess we have to setup something early, somehow, that will help
many possible contributors of the same language to interlock and avoid
work duplication, and further be put in contact for solving together
problems particular to their tongue (in most languages, there are many
difficulties peculiar to translating technical English). My Swedish
contributor acknowledged these difficulties, and I'm well aware of
them for French.
</P>
<P>
This is surely not a technical issue, but we should manage so the
effort of locale contributors be maximally useful, despite the national
team layer interface between contributors and maintainers.
</P>
<P>
The Translation Project needs some setup for coordinating language
coordinators. Localizing evolving programs will surely
become a permanent and continuous activity in the free software community,
once well started.
The setup should be minimally completed and tested before GNU
<CODE>gettext</CODE> becomes an official reality. The e-mail address
<TT>‘coordinator@translationproject.org’</TT> has been set up for receiving
offers from volunteers and general e-mail on these topics. This address
reaches the Translation Project coordinator.
</P>
<H3><A NAME="SEC205" HREF="gettext_toc.html#TOC205">12.4.1 Central Coordination</A></H3>
<P>
I also think GNU will need sooner than it thinks, that someone set up
a way to organize and coordinate these groups. Some kind of group
of groups. My opinion is that it would be good that GNU delegates
this task to a small group of collaborating volunteers, shortly.
Perhaps in <TT>‘gnu.announce’</TT> a list of this national committee's
can be published.
</P>
<P>
My role as coordinator would simply be to refer to Ulrich any German
speaking volunteer interested to localization of free software packages, and
maybe helping national groups to initially organize, while maintaining
national registries for until national groups are ready to take over.
In fact, the coordinator should ease volunteers to get in contact with
one another for creating national teams, which should then select
one coordinator per language, or country (regionalized language).
If well done, the coordination should be useful without being an
overwhelming task, the time to put delegations in place.
</P>
<H3><A NAME="SEC206" HREF="gettext_toc.html#TOC206">12.4.2 National Teams</A></H3>
<P>
I suggest we look for volunteer coordinators/editors for individual
languages. These people will scan contributions of translation files
for various programs, for their own languages, and will ensure high
and uniform standards of diction.
</P>
<P>
From my current experience with other people in these days, those who
provide localizations are very enthusiastic about the process, and are
more interested in the localization process than in the program they
localize, and want to do many programs, not just one. This seems
to confirm that having a coordinator/editor for each language is a
good idea.
</P>
<P>
We need to choose someone who is good at writing clear and concise
prose in the language in question. That is hard--we can't check
it ourselves. So we need to ask a few people to judge each others'
writing and select the one who is best.
</P>
<P>
I announce my prerelease to a few dozen people, and you would not
believe all the discussions it generated already. I shudder to think
what will happen when this will be launched, for true, officially,
world wide. Who am I to arbitrate between two Czekolsovak users
contradicting each other, for example?
</P>
<P>
I assume that your German is not much better than my French so that
I would not be able to judge about these formulations. What I would
suggest is that for each language there is a group for people who
maintain the PO files and judge about changes. I suspect there will
be cultural differences between how such groups of people will behave.
Some will have relaxed ways, reach consensus easily, and have anyone
of the group relate to the maintainers, while others will fight to
death, organize heavy administrations up to national standards, and
use strict channels.
</P>
<P>
The German team is putting out a good example. Right now, they are
maybe half a dozen people revising translations of each other and
discussing the linguistic issues. I do not even have all the names.
Ulrich Drepper is taking care of coordinating the German team.
He subscribed to all my pretest lists, so I do not even have to warn
him specifically of incoming releases.
</P>
<P>
I'm sure, that is a good idea to get teams for each language working
on translations. That will make the translations better and more
consistent.
</P>
<H4><A NAME="SEC207" HREF="gettext_toc.html#TOC207">12.4.2.1 Sub-Cultures</A></H4>
<P>
Taking French for example, there are a few sub-cultures around computers
which developed diverging vocabularies. Picking volunteers here and
there without addressing this problem in an organized way, soon in the
project, might produce a distasteful mix of internationalized programs,
and possibly trigger endless quarrels among those who really care.
</P>
<P>
Keeping some kind of unity in the way French localization of
internationalized programs is achieved is a difficult (and delicate) job.
Knowing the latin character of French people (:-), if we take this
the wrong way, we could end up nowhere, or spoil a lot of energies.
Maybe we should begin to address this problem seriously <EM>before</EM>
GNU <CODE>gettext</CODE> become officially published. And I suspect that this
means soon!
</P>
<H4><A NAME="SEC208" HREF="gettext_toc.html#TOC208">12.4.2.2 Organizational Ideas</A></H4>
<P>
I expect the next big changes after the official release. Please note
that I use the German translation of the short GPL message. We need
to set a few good examples before the localization goes out for true
in the free software community. Here are a few points to discuss:
</P>
<UL>
<LI>
Each group should have one FTP server (at least one master).
<LI>
The files on the server should reflect the latest version (of
course!) and it should also contain a RCS directory with the
corresponding archives (I don't have this now).
<LI>
There should also be a ChangeLog file (this is more useful than the
RCS archive but can be generated automatically from the later by
Emacs).
<LI>
A <EM>core group</EM> should judge about questionable changes (for now
this group consists solely by me but I ask some others occasionally;
this also seems to work).
</UL>
<H3><A NAME="SEC209" HREF="gettext_toc.html#TOC209">12.4.3 Mailing Lists</A></H3>
<P>
If we get any inquiries about GNU <CODE>gettext</CODE>, send them on to:
</P>
<PRE>
<TT>‘coordinator@translationproject.org’</TT>
</PRE>
<P>
The <TT>‘*-pretest’</TT> lists are quite useful to me, maybe the idea could
be generalized to many GNU, and non-GNU packages. But each maintainer
his/her way!
</P>
<P>
François, we have a mechanism in place here at
<TT>‘gnu.ai.mit.edu’</TT> to track teams, support mailing lists for
them and log members. We have a slight preference that you use it.
If this is OK with you, I can get you clued in.
</P>
<P>
Things are changing! A few years ago, when Daniel Fekete and I
asked for a mailing list for GNU localization, nested at the FSF, we
were politely invited to organize it anywhere else, and so did we.
For communicating with my pretesters, I later made a handful of
mailing lists located at iro.umontreal.ca and administrated by
<CODE>majordomo</CODE>. These lists have been <EM>very</EM> dependable
so far...
</P>
<P>
I suspect that the German team will organize itself a mailing list
located in Germany, and so forth for other countries. But before they
organize for true, it could surely be useful to offer mailing lists
located at the FSF to each national team. So yes, please explain me
how I should proceed to create and handle them.
</P>
<P>
We should create temporary mailing lists, one per country, to help
people organize. Temporary, because once regrouped and structured, it
would be fair the volunteers from country bring back <EM>their</EM> list
in there and manage it as they want. My feeling is that, in the long
run, each team should run its own list, from within their country.
There also should be some central list to which all teams could
subscribe as they see fit, as long as each team is represented in it.
</P>
<H2><A NAME="SEC210" HREF="gettext_toc.html#TOC210">12.5 Information Flow</A></H2>
<P>
<STRONG> NOTE: </STRONG> This documentation section is outdated and needs to be
revised.
</P>
<P>
There will surely be some discussion about this messages after the
packages are finally released. If people now send you some proposals
for better messages, how do you proceed? Jim, please note that
right now, as I put forward nearly a dozen of localizable programs, I
receive both the translations and the coordination concerns about them.
</P>
<P>
If I put one of my things to pretest, Ulrich receives the announcement
and passes it on to the German team, who make last minute revisions.
Then he submits the translation files to me <EM>as the maintainer</EM>.
For free packages I do not maintain, I would not even hear about it.
This scheme could be made to work for the whole Translation Project,
I think. For security reasons, maybe Ulrich (national coordinators,
in fact) should update central registry kept at the Translation Project
(Jim, me, or Len's recruits) once in a while.
</P>
<P>
In December/January, I was aggressively ready to internationalize
all of GNU, giving myself the duty of one small GNU package per week
or so, taking many weeks or months for bigger packages. But it does
not work this way. I first did all the things I'm responsible for.
I've nothing against some missionary work on other maintainers, but
I'm also losing a lot of energy over it--same debates over again.
</P>
<P>
And when the first localized packages are released we'll get a lot of
responses about ugly translations :-). Surely, and we need to have
beforehand a fairly good idea about how to handle the information
flow between the national teams and the package maintainers.
</P>
<P>
Please start saving somewhere a quick history of each PO file. I know
for sure that the file format will change, allowing for comments.
It would be nice that each file has a kind of log, and references for
those who want to submit comments or gripes, or otherwise contribute.
I sent a proposal for a fast and flexible format, but it is not
receiving acceptance yet by the GNU deciders. I'll tell you when I
have more information about this.
</P>
<H2><A NAME="SEC211" HREF="gettext_toc.html#TOC211">12.6 Translating plural forms</A></H2>
<P>
<A NAME="IDX1158"></A>
Suppose you are translating a PO file, and it contains an entry like this:
</P>
<PRE>
#, c-format
msgid "One file removed"
msgid_plural "%d files removed"
msgstr[0] ""
msgstr[1] ""
</PRE>
<P>
What does this mean? How do you fill it in?
</P>
<P>
Such an entry denotes a message with plural forms, that is, a message where
the text depends on a cardinal number. The general form of the message,
in English, is the <CODE>msgid_plural</CODE> line. The <CODE>msgid</CODE> line is the
English singular form, that is, the form for when the number is equal to 1.
More details about plural forms are explained in section <A HREF="gettext_11.html#SEC190">11.2.6 Additional functions for plural forms</A>.
</P>
<P>
The first thing you need to look at is the <CODE>Plural-Forms</CODE> line in the
header entry of the PO file. It contains the number of plural forms and a
formula. If the PO file does not yet have such a line, you have to add it.
It only depends on the language into which you are translating. You can
get this info by using the <CODE>msginit</CODE> command (see section <A HREF="gettext_6.html#SEC37">6 Creating a New PO File</A>) --
it contains a database of known plural formulas -- or by asking other
members of your translation team.
</P>
<P>
Suppose the line looks as follows:
</P>
<PRE>
"Plural-Forms: nplurals=3; plural=n%10==1 && n%100!=11 ? 0 : n%10>=2 && n"
"%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;\n"
</PRE>
<P>
It's logically one line; recall that the PO file formatting is allowed to
break long lines so that each physical line fits in 80 monospaced columns.
</P>
<P>
The value of <CODE>nplurals</CODE> here tells you that there are three plural
forms. The first thing you need to do is to ensure that the entry contains
an <CODE>msgstr</CODE> line for each of the forms:
</P>
<PRE>
#, c-format
msgid "One file removed"
msgid_plural "%d files removed"
msgstr[0] ""
msgstr[1] ""
msgstr[2] ""
</PRE>
<P>
Then translate the <CODE>msgid_plural</CODE> line and fill it in into each
<CODE>msgstr</CODE> line:
</P>
<PRE>
#, c-format
msgid "One file removed"
msgid_plural "%d files removed"
msgstr[0] "%d slika uklonjenih"
msgstr[1] "%d slika uklonjenih"
msgstr[2] "%d slika uklonjenih"
</PRE>
<P>
Now you can refine the translation so that it matches the plural form.
According to the formula above, <CODE>msgstr[0]</CODE> is used when the number
ends in 1 but does not end in 11; <CODE>msgstr[1]</CODE> is used when the number
ends in 2, 3, 4, but not in 12, 13, 14; and <CODE>msgstr[2]</CODE> is used in
all other cases. With this knowledge, you can refine the translations:
</P>
<PRE>
#, c-format
msgid "One file removed"
msgid_plural "%d files removed"
msgstr[0] "%d slika je uklonjena"
msgstr[1] "%d datoteke uklonjenih"
msgstr[2] "%d slika uklonjenih"
</PRE>
<P>
You noticed that in the English singular form (<CODE>msgid</CODE>) the number
placeholder could be omitted and replaced by the numeral word “one”.
Can you do this in your translation as well?
</P>
<PRE>
msgstr[0] "jednom datotekom je uklonjen"
</PRE>
<P>
Well, it depends on whether <CODE>msgstr[0]</CODE> applies only to the number 1,
or to other numbers as well. If, according to the plural formula,
<CODE>msgstr[0]</CODE> applies only to <CODE>n == 1</CODE>, then you can use the
specialized translation without the number placeholder. In our case,
however, <CODE>msgstr[0]</CODE> also applies to the numbers 21, 31, 41, etc.,
and therefore you cannot omit the placeholder.
</P>
<H2><A NAME="SEC212" HREF="gettext_toc.html#TOC212">12.7 Prioritizing messages: How to determine which messages to translate first</A></H2>
<P>
A translator sometimes has only a limited amount of time per week to
spend on a package, and some packages have quite large message catalogs
(over 1000 messages). Therefore she wishes to translate the messages
first that are the most visible to the user, or that occur most frequently.
This section describes how to determine these "most urgent" messages.
It also applies to determine the "next most urgent" messages after the
message catalog has already been partially translated.
</P>
<P>
In a first step, she uses the programs like a user would do. While she
does this, the GNU <CODE>gettext</CODE> library logs into a file the not yet
translated messages for which a translation was requested from the program.
</P>
<P>
In a second step, she uses the PO mode to translate precisely this set
of messages.
</P>
<P>
<A NAME="IDX1159"></A>
Here a more details. The GNU <CODE>libintl</CODE> library (but not the
corresponding functions in GNU <CODE>libc</CODE>) supports an environment variable
<CODE>GETTEXT_LOG_UNTRANSLATED</CODE>. The GNU <CODE>libintl</CODE> library will
log into this file the messages for which <CODE>gettext()</CODE> and related
functions couldn't find the translation. If the file doesn't exist, it
will be created as needed. On systems with GNU <CODE>libc</CODE> a shared library
<SAMP>‘preloadable_libintl.so’</SAMP> is provided that can be used with the ELF
<SAMP>‘LD_PRELOAD’</SAMP> mechanism.
</P>
<P>
So, in the first step, the translator uses these commands on systems with
GNU <CODE>libc</CODE>:
</P>
<PRE>
$ LD_PRELOAD=/usr/local/lib/preloadable_libintl.so
$ export LD_PRELOAD
$ GETTEXT_LOG_UNTRANSLATED=$HOME/gettextlogused
$ export GETTEXT_LOG_UNTRANSLATED
</PRE>
<P>
and these commands on other systems:
</P>
<PRE>
$ GETTEXT_LOG_UNTRANSLATED=$HOME/gettextlogused
$ export GETTEXT_LOG_UNTRANSLATED
</PRE>
<P>
Then she uses and peruses the programs. (It is a good and recommended
practice to use the programs for which you provide translations: it
gives you the needed context.) When done, she removes the environment
variables:
</P>
<PRE>
$ unset LD_PRELOAD
$ unset GETTEXT_LOG_UNTRANSLATED
</PRE>
<P>
The second step starts with removing duplicates:
</P>
<PRE>
$ msguniq $HOME/gettextlogused > missing.po
</PRE>
<P>
The result is a PO file, but needs some preprocessing before a PO file editor
can be used with it. First, it is a multi-domain PO file, containing
messages from many translation domains. Second, it lacks all translator
comments and source references. Here is how to get a list of the affected
translation domains:
</P>
<PRE>
$ sed -n -e 's,^domain "\(.*\)"$,\1,p' < missing.po | sort | uniq
</PRE>
<P>
Then the translator can handle the domains one by one. For simplicity,
let's use environment variables to denote the language, domain and source
package.
</P>
<PRE>
$ lang=nl # your language
$ domain=coreutils # the name of the domain to be handled
$ package=/usr/src/gnu/coreutils-4.5.4 # the package where it comes from
</PRE>
<P>
She takes the latest copy of <TT>‘$lang.po’</TT> from the Translation Project,
or from the package (in most cases, <TT>‘$package/po/$lang.po’</TT>), or
creates a fresh one if she's the first translator (see section <A HREF="gettext_6.html#SEC37">6 Creating a New PO File</A>).
She then uses the following commands to mark the not urgent messages as
"obsolete". (This doesn't mean that these messages - translated and
untranslated ones - will go away. It simply means that the PO file editor
will ignore them in the following editing session.)
</P>
<PRE>
$ msggrep --domain=$domain missing.po | grep -v '^domain' \
> $domain-missing.po
$ msgattrib --set-obsolete --ignore-file $domain-missing.po $domain.$lang.po \
> $domain.$lang-urgent.po
</PRE>
<P>
The she translates <TT>‘$domain.$lang-urgent.po’</TT> by use of a PO file editor
(see section <A HREF="gettext_8.html#SEC55">8 Editing PO Files</A>).
(FIXME: I don't know whether <CODE>KBabel</CODE> and <CODE>gtranslator</CODE> also
preserve obsolete messages, as they should.)
Finally she restores the not urgent messages (with their earlier
translations, for those which were already translated) through this command:
</P>
<PRE>
$ msgmerge --no-fuzzy-matching $domain.$lang-urgent.po $package/po/$domain.pot \
> $domain.$lang.po
</PRE>
<P>
Then she can submit <TT>‘$domain.$lang.po’</TT> and proceed to the next domain.
</P>
<P><HR><P>
Go to the <A HREF="gettext_1.html">first</A>, <A HREF="gettext_11.html">previous</A>, <A HREF="gettext_13.html">next</A>, <A HREF="gettext_25.html">last</A> section, <A HREF="gettext_toc.html">table of contents</A>.
</BODY>
</HTML>
|
