Re: [Translation-i18n] The reason for make dist updating po files
- From: Bruno Haible <bruno clisp org>
- To: Christian Rose <menthos gnome org>,translation-i18n lists sourceforge net, gnome-i18n gnome org
- Cc: Kjartan Maraas <kmaraas gnome org>
- Subject: Re: [Translation-i18n] The reason for make dist updating po files
- Date: Tue, 27 May 2003 13:33:45 +0200 (CEST)
Christian Rose asked:
> So, a discussion has come to place whether we should alter this behavior
> of make dist in GNOME, so that it does not touch the po files. But the
> question remains why this behavior was chosen to begin with.
The main reason of existence of msgmerge is that after the developers have
added new messages to the code, the translators are made aware of these
new messages, so they can translate them in order to get 100% translation
coverage.
Martin v. Löwis said the purpose is to avoid bogus, obsolete messages that
cause work to the translator. This is a secondary goal, yes.
Taken together, the goal is that a translator starts from a PO file that
reflects the current state of the code.
Now comes the question: How is the PO file transferred from the developers
to the translators? In other words, where do the translators pick up the PO
file?
In the traditional distribution model for many packages, the ftp servers
containing the released .tar.gz files are the primary means of pick up.
This mode is also a good way for the translators because
- this way, they have source references, and can throw a glimpse on the
source code in order to get some context.
- this way, they can build the package and test their translation.
That's why "make dist" updates the PO files.
In GNOME, apparently, a second transfer channel has been added: translators
pick up the PO files from the CVS. It is reasonable that for this case
the translators use intltool-update (which invokes msgmerge) before they
start their translation work.
> Currently in the GNOME translation process, make dist updating the po
> files causes some problems as maintainers often commit back those
> regenerated po files into cvs, often introducing cvs conflicts for
> translators who happen to be working on those files in cvs at the same
> time.
So it appears that just "cvs commit" - as recommended as step 9 in Christian
Rose's tutorial - is an incomplete recommendation, and you should instead
recommend to them to run intltool-commit. intltool-commit should be a shell
script which hides the complexities of "cvs update", the conflict check,
"msgfmt -c", "msgmerge", "cvs commit" to the translator.
But the msgmerge invocations during "make dist" are still justified, because
some translators will prefer to work from the released .tar.gz.
The "cvs commit" in the PO directory after "make dist" is not really needed
- because translators working off the CVS use intltool-update anyway. Its
only purpose is to avoid a CVS conflict for the person doing the "make dist".
And, assuming a proper intltool-commit tool, these "cvs commit"s won't hurt
either.
Bruno
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]