jpayne@68: jpayne@68: jpayne@68: jpayne@68: jpayne@68:
jpayne@68:[ << ] | jpayne@68:[ >> ] | jpayne@68:jpayne@68: | jpayne@68: | jpayne@68: | jpayne@68: | jpayne@68: | [Top] | jpayne@68:[Contents] | jpayne@68:[Index] | jpayne@68:[ ? ] | jpayne@68:
NOTE: This documentation section is outdated and needs to be jpayne@68: revised. jpayne@68:
jpayne@68:Free software is going international! The Translation Project is a way jpayne@68: to get maintainers, translators and users all together, so free software jpayne@68: will gradually become able to speak many native languages. jpayne@68:
jpayne@68:The GNU gettext
tool set contains everything maintainers
jpayne@68: need for internationalizing their packages for messages. It also
jpayne@68: contains quite useful tools for helping translators at localizing
jpayne@68: messages to their native language, once a package has already been
jpayne@68: internationalized.
jpayne@68:
To achieve the Translation Project, we need many interested jpayne@68: people who like their own language and write it well, and who are also jpayne@68: able to synergize with other translators speaking the same language. jpayne@68: If you'd like to volunteer to work at translating messages, jpayne@68: please send mail to your translating team. jpayne@68:
jpayne@68:Each team has its own mailing list, courtesy of Linux jpayne@68: International. You may reach your translating team at the address jpayne@68: ‘ll@li.org’, replacing ll by the two-letter ISO 639 jpayne@68: code for your language. Language codes are not the same as jpayne@68: country codes given in ISO 3166. The following translating teams jpayne@68: exist: jpayne@68:
jpayne@68:jpayne@68: jpayne@68:Chinese
zh
, Czechcs
, Danishda
, Dutchnl
, jpayne@68: Esperantoeo
, Finnishfi
, Frenchfr
, Irish jpayne@68:ga
, Germande
, Greekel
, Italianit
, jpayne@68: Japaneseja
, Indonesianin
, Norwegianno
, Polish jpayne@68:pl
, Portuguesept
, Russianru
, Spanishes
, jpayne@68: Swedishsv
and Turkishtr
. jpayne@68:
For example, you may reach the Chinese translating team by writing to jpayne@68: ‘zh@li.org’. When you become a member of the translating team jpayne@68: for your own language, you may subscribe to its list. For example, jpayne@68: Swedish people can send a message to ‘sv-request@li.org’, jpayne@68: having this message body: jpayne@68:
jpayne@68:subscribe jpayne@68: |
Keep in mind that team members should be interested in working jpayne@68: at translations, or at solving translational difficulties, rather than jpayne@68: merely lurking around. If your team does not exist yet and you want to jpayne@68: start one, please write to ‘coordinator@translationproject.org’; jpayne@68: you will then reach the coordinator for all translator teams. jpayne@68:
jpayne@68:A handful of GNU packages have already been adapted and provided jpayne@68: with message translations for several languages. Translation jpayne@68: teams have begun to organize, using these packages as a starting jpayne@68: point. But there are many more packages and many languages for jpayne@68: which we have no volunteer translators. If you would like to jpayne@68: volunteer to work at translating messages, please send mail to jpayne@68: ‘coordinator@translationproject.org’ indicating what language(s) jpayne@68: you can work on. jpayne@68:
jpayne@68: jpayne@68: jpayne@68: jpayne@68:NOTE: This documentation section is outdated and needs to be jpayne@68: revised. jpayne@68:
jpayne@68:This is now official, GNU is going international! Here is the jpayne@68: announcement submitted for the January 1995 GNU Bulletin: jpayne@68:
jpayne@68:jpayne@68: jpayne@68:A handful of GNU packages have already been adapted and provided jpayne@68: with message translations for several languages. Translation jpayne@68: teams have begun to organize, using these packages as a starting jpayne@68: point. But there are many more packages and many languages jpayne@68: for which we have no volunteer translators. If you'd like to jpayne@68: volunteer to work at translating messages, please send mail to jpayne@68: ‘coordinator@translationproject.org’ indicating what language(s) jpayne@68: you can work on. jpayne@68:
This document should answer many questions for those who are curious about jpayne@68: the process or would like to contribute. Please at least skim over it, jpayne@68: hoping to cut down a little of the high volume of e-mail generated by this jpayne@68: collective effort towards internationalization of free software. jpayne@68:
jpayne@68:Most free programming which is widely shared is done in English, and jpayne@68: currently, English is used as the main communicating language between jpayne@68: national communities collaborating to free software. This very document jpayne@68: is written in English. This will not change in the foreseeable future. jpayne@68:
jpayne@68:However, there is a strong appetite from national communities for jpayne@68: having more software able to write using national language and habits, jpayne@68: and there is an on-going effort to modify free software in such a way jpayne@68: that it becomes able to do so. The experiments driven so far raised jpayne@68: an enthusiastic response from pretesters, so we believe that jpayne@68: internationalization of free software is dedicated to succeed. jpayne@68:
jpayne@68:For suggestion clarifications, additions or corrections to this jpayne@68: document, please e-mail to ‘coordinator@translationproject.org’. jpayne@68:
jpayne@68: jpayne@68: jpayne@68: jpayne@68:NOTE: This documentation section is outdated and needs to be jpayne@68: revised. jpayne@68:
jpayne@68:Facing this internationalization effort, a few users expressed their jpayne@68: concerns. Some of these doubts are presented and discussed, here. jpayne@68:
jpayne@68:Some languages are not spoken by a very large number of people, so people jpayne@68: speaking them sometimes consider that there may not be all that much jpayne@68: demand such versions of free software packages. Moreover, many people jpayne@68: being into computers, in some countries, generally seem to prefer jpayne@68: English versions of their software. jpayne@68:
jpayne@68:On the other end, people might enjoy their own language a lot, and be jpayne@68: very motivated at providing to themselves the pleasure of having their jpayne@68: beloved free software speaking their mother tongue. They do themselves jpayne@68: a personal favor, and do not pay that much attention to the number of jpayne@68: people benefiting of their work. jpayne@68:
jpayne@68:Other users are shy to push forward their own language, seeing in this jpayne@68: some kind of misplaced propaganda. Someone thought there must be some jpayne@68: users of the language over the networks pestering other people with it. jpayne@68:
jpayne@68:But any spoken language is worth localization, because there are jpayne@68: people behind the language for whom the language is important and jpayne@68: dear to their hearts. jpayne@68:
jpayne@68:The biggest problem is to find the right translations so that jpayne@68: everybody can understand the messages. Translations are usually a jpayne@68: little odd. Some people get used to English, to the extent they may jpayne@68: find translations into their own language “rather pushy, obnoxious jpayne@68: and sometimes even hilarious.” As a French speaking man, I have jpayne@68: the experience of those instruction manuals for goods, so poorly jpayne@68: translated in French in Korea or Taiwan… jpayne@68:
jpayne@68:The fact is that we sometimes have to create a kind of national jpayne@68: computer culture, and this is not easy without the collaboration of jpayne@68: many people liking their mother tongue. This is why translations are jpayne@68: better achieved by people knowing and loving their own language, and jpayne@68: ready to work together at improving the results they obtain. jpayne@68:
jpayne@68:Some people wonder if using GNU gettext
necessarily brings their
jpayne@68: package under the protective wing of the GNU General Public License or
jpayne@68: the GNU Lesser General Public License, when they do not want to make
jpayne@68: their program free, or want other kinds of freedom. The simplest
jpayne@68: answer is “normally not”.
jpayne@68:
The gettext-runtime
part of GNU gettext
, i.e. the
jpayne@68: contents of libintl
, is covered by the GNU Lesser General Public
jpayne@68: License. The gettext-tools
part of GNU gettext
, i.e. the
jpayne@68: rest of the GNU gettext
package, is covered by the GNU General
jpayne@68: Public License.
jpayne@68:
The mere marking of localizable strings in a package, or conditional
jpayne@68: inclusion of a few lines for initialization, is not really including
jpayne@68: GPL'ed or LGPL'ed code. However, since the localization routines in
jpayne@68: libintl
are under the LGPL, the LGPL needs to be considered.
jpayne@68: It gives the right to distribute the complete unmodified source of
jpayne@68: libintl
even with non-free programs. It also gives the right
jpayne@68: to use libintl
as a shared library, even for non-free programs.
jpayne@68: But it gives the right to use libintl
as a static library or
jpayne@68: to incorporate libintl
into another library only to free
jpayne@68: software.
jpayne@68:
NOTE: This documentation section is outdated and needs to be jpayne@68: revised. jpayne@68:
jpayne@68:On a larger scale, the true solution would be to organize some kind of jpayne@68: fairly precise set up in which volunteers could participate. I gave jpayne@68: some thought to this idea lately, and realize there will be some jpayne@68: touchy points. I thought of writing to Richard Stallman to launch jpayne@68: such a project, but feel it might be good to shake out the ideas jpayne@68: between ourselves first. Most probably that Linux International has jpayne@68: some experience in the field already, or would like to orchestrate jpayne@68: the volunteer work, maybe. Food for thought, in any case! jpayne@68:
jpayne@68:I guess we have to setup something early, somehow, that will help jpayne@68: many possible contributors of the same language to interlock and avoid jpayne@68: work duplication, and further be put in contact for solving together jpayne@68: problems particular to their tongue (in most languages, there are many jpayne@68: difficulties peculiar to translating technical English). My Swedish jpayne@68: contributor acknowledged these difficulties, and I'm well aware of jpayne@68: them for French. jpayne@68:
jpayne@68:This is surely not a technical issue, but we should manage so the jpayne@68: effort of locale contributors be maximally useful, despite the national jpayne@68: team layer interface between contributors and maintainers. jpayne@68:
jpayne@68:The Translation Project needs some setup for coordinating language
jpayne@68: coordinators. Localizing evolving programs will surely
jpayne@68: become a permanent and continuous activity in the free software community,
jpayne@68: once well started.
jpayne@68: The setup should be minimally completed and tested before GNU
jpayne@68: gettext
becomes an official reality. The e-mail address
jpayne@68: ‘coordinator@translationproject.org’ has been set up for receiving
jpayne@68: offers from volunteers and general e-mail on these topics. This address
jpayne@68: reaches the Translation Project coordinator.
jpayne@68:
I also think GNU will need sooner than it thinks, that someone set up jpayne@68: a way to organize and coordinate these groups. Some kind of group jpayne@68: of groups. My opinion is that it would be good that GNU delegates jpayne@68: this task to a small group of collaborating volunteers, shortly. jpayne@68: Perhaps in ‘gnu.announce’ a list of this national committee's jpayne@68: can be published. jpayne@68:
jpayne@68:My role as coordinator would simply be to refer to Ulrich any German jpayne@68: speaking volunteer interested to localization of free software packages, and jpayne@68: maybe helping national groups to initially organize, while maintaining jpayne@68: national registries for until national groups are ready to take over. jpayne@68: In fact, the coordinator should ease volunteers to get in contact with jpayne@68: one another for creating national teams, which should then select jpayne@68: one coordinator per language, or country (regionalized language). jpayne@68: If well done, the coordination should be useful without being an jpayne@68: overwhelming task, the time to put delegations in place. jpayne@68:
jpayne@68: jpayne@68: jpayne@68: jpayne@68:I suggest we look for volunteer coordinators/editors for individual jpayne@68: languages. These people will scan contributions of translation files jpayne@68: for various programs, for their own languages, and will ensure high jpayne@68: and uniform standards of diction. jpayne@68:
jpayne@68:From my current experience with other people in these days, those who jpayne@68: provide localizations are very enthusiastic about the process, and are jpayne@68: more interested in the localization process than in the program they jpayne@68: localize, and want to do many programs, not just one. This seems jpayne@68: to confirm that having a coordinator/editor for each language is a jpayne@68: good idea. jpayne@68:
jpayne@68:We need to choose someone who is good at writing clear and concise jpayne@68: prose in the language in question. That is hard—we can't check jpayne@68: it ourselves. So we need to ask a few people to judge each others' jpayne@68: writing and select the one who is best. jpayne@68:
jpayne@68:I announce my prerelease to a few dozen people, and you would not jpayne@68: believe all the discussions it generated already. I shudder to think jpayne@68: what will happen when this will be launched, for true, officially, jpayne@68: world wide. Who am I to arbitrate between two Czekolsovak users jpayne@68: contradicting each other, for example? jpayne@68:
jpayne@68:I assume that your German is not much better than my French so that jpayne@68: I would not be able to judge about these formulations. What I would jpayne@68: suggest is that for each language there is a group for people who jpayne@68: maintain the PO files and judge about changes. I suspect there will jpayne@68: be cultural differences between how such groups of people will behave. jpayne@68: Some will have relaxed ways, reach consensus easily, and have anyone jpayne@68: of the group relate to the maintainers, while others will fight to jpayne@68: death, organize heavy administrations up to national standards, and jpayne@68: use strict channels. jpayne@68:
jpayne@68:The German team is putting out a good example. Right now, they are jpayne@68: maybe half a dozen people revising translations of each other and jpayne@68: discussing the linguistic issues. I do not even have all the names. jpayne@68: Ulrich Drepper is taking care of coordinating the German team. jpayne@68: He subscribed to all my pretest lists, so I do not even have to warn jpayne@68: him specifically of incoming releases. jpayne@68:
jpayne@68:I'm sure, that is a good idea to get teams for each language working jpayne@68: on translations. That will make the translations better and more jpayne@68: consistent. jpayne@68:
jpayne@68: jpayne@68: jpayne@68: jpayne@68: jpayne@68:Taking French for example, there are a few sub-cultures around computers jpayne@68: which developed diverging vocabularies. Picking volunteers here and jpayne@68: there without addressing this problem in an organized way, soon in the jpayne@68: project, might produce a distasteful mix of internationalized programs, jpayne@68: and possibly trigger endless quarrels among those who really care. jpayne@68:
jpayne@68:Keeping some kind of unity in the way French localization of
jpayne@68: internationalized programs is achieved is a difficult (and delicate) job.
jpayne@68: Knowing the latin character of French people (:-), if we take this
jpayne@68: the wrong way, we could end up nowhere, or spoil a lot of energies.
jpayne@68: Maybe we should begin to address this problem seriously before
jpayne@68: GNU gettext
become officially published. And I suspect that this
jpayne@68: means soon!
jpayne@68:
I expect the next big changes after the official release. Please note jpayne@68: that I use the German translation of the short GPL message. We need jpayne@68: to set a few good examples before the localization goes out for true jpayne@68: in the free software community. Here are a few points to discuss: jpayne@68:
jpayne@68:If we get any inquiries about GNU gettext
, send them on to:
jpayne@68:
‘coordinator@translationproject.org’ jpayne@68: |
The ‘*-pretest’ lists are quite useful to me, maybe the idea could jpayne@68: be generalized to many GNU, and non-GNU packages. But each maintainer jpayne@68: his/her way! jpayne@68:
jpayne@68:François, we have a mechanism in place here at jpayne@68: ‘gnu.ai.mit.edu’ to track teams, support mailing lists for jpayne@68: them and log members. We have a slight preference that you use it. jpayne@68: If this is OK with you, I can get you clued in. jpayne@68:
jpayne@68:Things are changing! A few years ago, when Daniel Fekete and I
jpayne@68: asked for a mailing list for GNU localization, nested at the FSF, we
jpayne@68: were politely invited to organize it anywhere else, and so did we.
jpayne@68: For communicating with my pretesters, I later made a handful of
jpayne@68: mailing lists located at iro.umontreal.ca and administrated by
jpayne@68: majordomo
. These lists have been very dependable
jpayne@68: so far…
jpayne@68:
I suspect that the German team will organize itself a mailing list jpayne@68: located in Germany, and so forth for other countries. But before they jpayne@68: organize for true, it could surely be useful to offer mailing lists jpayne@68: located at the FSF to each national team. So yes, please explain me jpayne@68: how I should proceed to create and handle them. jpayne@68:
jpayne@68:We should create temporary mailing lists, one per country, to help jpayne@68: people organize. Temporary, because once regrouped and structured, it jpayne@68: would be fair the volunteers from country bring back their list jpayne@68: in there and manage it as they want. My feeling is that, in the long jpayne@68: run, each team should run its own list, from within their country. jpayne@68: There also should be some central list to which all teams could jpayne@68: subscribe as they see fit, as long as each team is represented in it. jpayne@68:
jpayne@68: jpayne@68: jpayne@68: jpayne@68:NOTE: This documentation section is outdated and needs to be jpayne@68: revised. jpayne@68:
jpayne@68:There will surely be some discussion about this messages after the jpayne@68: packages are finally released. If people now send you some proposals jpayne@68: for better messages, how do you proceed? Jim, please note that jpayne@68: right now, as I put forward nearly a dozen of localizable programs, I jpayne@68: receive both the translations and the coordination concerns about them. jpayne@68:
jpayne@68:If I put one of my things to pretest, Ulrich receives the announcement jpayne@68: and passes it on to the German team, who make last minute revisions. jpayne@68: Then he submits the translation files to me as the maintainer. jpayne@68: For free packages I do not maintain, I would not even hear about it. jpayne@68: This scheme could be made to work for the whole Translation Project, jpayne@68: I think. For security reasons, maybe Ulrich (national coordinators, jpayne@68: in fact) should update central registry kept at the Translation Project jpayne@68: (Jim, me, or Len's recruits) once in a while. jpayne@68:
jpayne@68:In December/January, I was aggressively ready to internationalize jpayne@68: all of GNU, giving myself the duty of one small GNU package per week jpayne@68: or so, taking many weeks or months for bigger packages. But it does jpayne@68: not work this way. I first did all the things I'm responsible for. jpayne@68: I've nothing against some missionary work on other maintainers, but jpayne@68: I'm also losing a lot of energy over it—same debates over again. jpayne@68:
jpayne@68:And when the first localized packages are released we'll get a lot of jpayne@68: responses about ugly translations :-). Surely, and we need to have jpayne@68: beforehand a fairly good idea about how to handle the information jpayne@68: flow between the national teams and the package maintainers. jpayne@68:
jpayne@68:Please start saving somewhere a quick history of each PO file. I know jpayne@68: for sure that the file format will change, allowing for comments. jpayne@68: It would be nice that each file has a kind of log, and references for jpayne@68: those who want to submit comments or gripes, or otherwise contribute. jpayne@68: I sent a proposal for a fast and flexible format, but it is not jpayne@68: receiving acceptance yet by the GNU deciders. I'll tell you when I jpayne@68: have more information about this. jpayne@68:
jpayne@68: jpayne@68: jpayne@68: jpayne@68:Suppose you are translating a PO file, and it contains an entry like this: jpayne@68:
jpayne@68:#, c-format jpayne@68: msgid "One file removed" jpayne@68: msgid_plural "%d files removed" jpayne@68: msgstr[0] "" jpayne@68: msgstr[1] "" jpayne@68: |
What does this mean? How do you fill it in? jpayne@68:
jpayne@68:Such an entry denotes a message with plural forms, that is, a message where
jpayne@68: the text depends on a cardinal number. The general form of the message,
jpayne@68: in English, is the msgid_plural
line. The msgid
line is the
jpayne@68: English singular form, that is, the form for when the number is equal to 1.
jpayne@68: More details about plural forms are explained in Additional functions for plural forms.
jpayne@68:
The first thing you need to look at is the Plural-Forms
line in the
jpayne@68: header entry of the PO file. It contains the number of plural forms and a
jpayne@68: formula. If the PO file does not yet have such a line, you have to add it.
jpayne@68: It only depends on the language into which you are translating. You can
jpayne@68: get this info by using the msginit
command (see Creating a New PO File) –
jpayne@68: it contains a database of known plural formulas – or by asking other
jpayne@68: members of your translation team.
jpayne@68:
Suppose the line looks as follows: jpayne@68:
jpayne@68:"Plural-Forms: nplurals=3; plural=n%10==1 && n%100!=11 ? 0 : n%10>=2 && n" jpayne@68: "%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;\n" jpayne@68: |
It's logically one line; recall that the PO file formatting is allowed to jpayne@68: break long lines so that each physical line fits in 80 monospaced columns. jpayne@68:
jpayne@68:The value of nplurals
here tells you that there are three plural
jpayne@68: forms. The first thing you need to do is to ensure that the entry contains
jpayne@68: an msgstr
line for each of the forms:
jpayne@68:
#, c-format jpayne@68: msgid "One file removed" jpayne@68: msgid_plural "%d files removed" jpayne@68: msgstr[0] "" jpayne@68: msgstr[1] "" jpayne@68: msgstr[2] "" jpayne@68: |
Then translate the msgid_plural
line and fill it in into each
jpayne@68: msgstr
line:
jpayne@68:
#, c-format jpayne@68: msgid "One file removed" jpayne@68: msgid_plural "%d files removed" jpayne@68: msgstr[0] "%d slika uklonjenih" jpayne@68: msgstr[1] "%d slika uklonjenih" jpayne@68: msgstr[2] "%d slika uklonjenih" jpayne@68: |
Now you can refine the translation so that it matches the plural form.
jpayne@68: According to the formula above, msgstr[0]
is used when the number
jpayne@68: ends in 1 but does not end in 11; msgstr[1]
is used when the number
jpayne@68: ends in 2, 3, 4, but not in 12, 13, 14; and msgstr[2]
is used in
jpayne@68: all other cases. With this knowledge, you can refine the translations:
jpayne@68:
#, c-format jpayne@68: msgid "One file removed" jpayne@68: msgid_plural "%d files removed" jpayne@68: msgstr[0] "%d slika je uklonjena" jpayne@68: msgstr[1] "%d datoteke uklonjenih" jpayne@68: msgstr[2] "%d slika uklonjenih" jpayne@68: |
You noticed that in the English singular form (msgid
) the number
jpayne@68: placeholder could be omitted and replaced by the numeral word “one”.
jpayne@68: Can you do this in your translation as well?
jpayne@68:
msgstr[0] "jednom datotekom je uklonjen" jpayne@68: |
Well, it depends on whether msgstr[0]
applies only to the number 1,
jpayne@68: or to other numbers as well. If, according to the plural formula,
jpayne@68: msgstr[0]
applies only to n == 1
, then you can use the
jpayne@68: specialized translation without the number placeholder. In our case,
jpayne@68: however, msgstr[0]
also applies to the numbers 21, 31, 41, etc.,
jpayne@68: and therefore you cannot omit the placeholder.
jpayne@68:
A translator sometimes has only a limited amount of time per week to jpayne@68: spend on a package, and some packages have quite large message catalogs jpayne@68: (over 1000 messages). Therefore she wishes to translate the messages jpayne@68: first that are the most visible to the user, or that occur most frequently. jpayne@68: This section describes how to determine these "most urgent" messages. jpayne@68: It also applies to determine the "next most urgent" messages after the jpayne@68: message catalog has already been partially translated. jpayne@68:
jpayne@68:In a first step, she uses the programs like a user would do. While she
jpayne@68: does this, the GNU gettext
library logs into a file the not yet
jpayne@68: translated messages for which a translation was requested from the program.
jpayne@68:
In a second step, she uses the PO mode to translate precisely this set jpayne@68: of messages. jpayne@68:
jpayne@68: jpayne@68:Here are more details. The GNU libintl
library (but not the
jpayne@68: corresponding functions in GNU libc
) supports an environment variable
jpayne@68: GETTEXT_LOG_UNTRANSLATED
. The GNU libintl
library will
jpayne@68: log into this file the messages for which gettext()
and related
jpayne@68: functions couldn't find the translation. If the file doesn't exist, it
jpayne@68: will be created as needed. On systems with GNU libc
a shared library
jpayne@68: ‘preloadable_libintl.so’ is provided that can be used with the ELF
jpayne@68: ‘LD_PRELOAD’ mechanism.
jpayne@68:
So, in the first step, the translator uses these commands on systems with
jpayne@68: GNU libc
:
jpayne@68:
$ LD_PRELOAD=/usr/local/lib/preloadable_libintl.so jpayne@68: $ export LD_PRELOAD jpayne@68: $ GETTEXT_LOG_UNTRANSLATED=$HOME/gettextlogused jpayne@68: $ export GETTEXT_LOG_UNTRANSLATED jpayne@68: |
and these commands on other systems: jpayne@68:
jpayne@68:$ GETTEXT_LOG_UNTRANSLATED=$HOME/gettextlogused jpayne@68: $ export GETTEXT_LOG_UNTRANSLATED jpayne@68: |
Then she uses and peruses the programs. (It is a good and recommended jpayne@68: practice to use the programs for which you provide translations: it jpayne@68: gives you the needed context.) When done, she removes the environment jpayne@68: variables: jpayne@68:
jpayne@68:$ unset LD_PRELOAD jpayne@68: $ unset GETTEXT_LOG_UNTRANSLATED jpayne@68: |
The second step starts with removing duplicates: jpayne@68:
jpayne@68:$ msguniq $HOME/gettextlogused > missing.po jpayne@68: |
The result is a PO file, but needs some preprocessing before a PO file editor jpayne@68: can be used with it. First, it is a multi-domain PO file, containing jpayne@68: messages from many translation domains. Second, it lacks all translator jpayne@68: comments and source references. Here is how to get a list of the affected jpayne@68: translation domains: jpayne@68:
jpayne@68:$ sed -n -e 's,^domain "\(.*\)"$,\1,p' < missing.po | sort | uniq jpayne@68: |
Then the translator can handle the domains one by one. For simplicity, jpayne@68: let's use environment variables to denote the language, domain and source jpayne@68: package. jpayne@68:
jpayne@68:$ lang=nl # your language jpayne@68: $ domain=coreutils # the name of the domain to be handled jpayne@68: $ package=/usr/src/gnu/coreutils-4.5.4 # the package where it comes from jpayne@68: |
She takes the latest copy of ‘$lang.po’ from the Translation Project, jpayne@68: or from the package (in most cases, ‘$package/po/$lang.po’), or jpayne@68: creates a fresh one if she's the first translator (see Creating a New PO File). jpayne@68: She then uses the following commands to mark the not urgent messages as jpayne@68: "obsolete". (This doesn't mean that these messages - translated and jpayne@68: untranslated ones - will go away. It simply means that the PO file editor jpayne@68: will ignore them in the following editing session.) jpayne@68:
jpayne@68:$ msggrep --domain=$domain missing.po | grep -v '^domain' \ jpayne@68: > $domain-missing.po jpayne@68: $ msgattrib --set-obsolete --ignore-file $domain-missing.po $domain.$lang.po \ jpayne@68: > $domain.$lang-urgent.po jpayne@68: |
The she translates ‘$domain.$lang-urgent.po’ by use of a PO file editor
jpayne@68: (see section Editing PO Files).
jpayne@68: (FIXME: I don't know whether KBabel
and gtranslator
also
jpayne@68: preserve obsolete messages, as they should.)
jpayne@68: Finally she restores the not urgent messages (with their earlier
jpayne@68: translations, for those which were already translated) through this command:
jpayne@68:
$ msgmerge --no-fuzzy-matching $domain.$lang-urgent.po $package/po/$domain.pot \ jpayne@68: > $domain.$lang.po jpayne@68: |
Then she can submit ‘$domain.$lang.po’ and proceed to the next domain. jpayne@68:
jpayne@68: jpayne@68:[ << ] | jpayne@68:[ >> ] | jpayne@68:jpayne@68: | jpayne@68: | jpayne@68: | jpayne@68: | jpayne@68: | [Top] | jpayne@68:[Contents] | jpayne@68:[Index] | jpayne@68:[ ? ] | jpayne@68:
jpayne@68:
jpayne@68: This document was generated by Bruno Haible on February, 21 2024 using texi2html 1.78a.
jpayne@68:
jpayne@68:
jpayne@68:
jpayne@68: