Re: [Translation-i18n] The reason for make dist updating po files

[Christian Rose <menthos gnome org>]

tis 2003-05-27 klockan 13.33 skrev Bruno Haible:
> 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.

Exactly. In fact, we also have a third transfer channel, which is the
GNOME translation status pages
(http://developer.gnome.org/projects/gtp/status/), put together by
Carlos. On these pages, all pot and po files are instantly accessible
and together with the stats refreshed and regenerated (through
intltool-update on the current cvs sources) several times a day. So
translators always have an alternative, simple access to reasonably
up-to-date pot and po files without having to use cvs or intltool
themselves if they cannot use those or do not want to.


> > 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.

I have my doubts about that and how suitable such an approach would be.
First of all, I'm not sure how feasible it would be to teach such a
command how to distinguish an update that actually has a po file bugfix,
committed by another translator or developer, from a routinely checked
in "make dist"ed po file, committed by a developer.
Also, I'm not sure about how positive the intltool developers are about
adopting intltool to these specific behaviors and weirdnesses of cvs
development. But I'm cc:ing them.


> But the msgmerge invocations during "make dist" are still justified, because
> some translators will prefer to work from the released .tar.gz.

I doubt such contributions account for anything but a very small
percentage of our total GNOME translation contributions. In fact, I'm
not familiar with anyone that regularily works or prefer working on
translations from released tarballs instead of from the status pages or
cvs.

In addition, such contributions from tarballs would be more or less
obsolete from the start to begin with, since the packages rarely exactly
match the state in cvs, and are increasingly less likely to do so over
time. I'm sure the tarballs are often used as references though, much
like they are in the Translation Project, when a translator has
downloaded a pot/po file from the status pages and needs to look in the
code for some context reference. But I doubt tarballs are used very much
for direct translation, so I don't think we should try to adopt the
situation very much for that scenario.


> 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.

As I said above, I'm not sure if I believe in that as a solution to the
problem.


Christian