[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [i18n]Source packages and translation templates q.

On Mon, 6 Sep 2010 06:49:12 +0200
Christian PERRIER <bubulle@debian.org> wrote:

> Quoting Neil Williams (codehelp@debian.org):
> (of course, I mostly disagree with the initial comment as most, if not
> nearly all, Debian developers are now very i18n-friendly and most of
> the time do what's needed to make translators' work easier)
> > Translators don't want their work discarded, upstream don't want to
> > waste time putting in PO files which are already out of date.
> > Therefore, putting a POT file in the source package can be precisely
> > the WRONG thing to do.
> > 
> > What needs to be done is a call for translations *before* the
> > release, 

The "release" referred to here is not the Debian (downstream)
stable release but the upstream package-specific release which doesn't
then coincide with other releases, mostly. Sorry that this wasn't clear.

> > giving time for all updated translations to be received
> > and then the package released and uploaded with as many
> > translations updated as possible. When the POT file changes,
> > another string freeze, another call and the package gets uploaded
> > with updated strings already in place.
> Well, here I feel the need to comment.
> This is quite theoretical assumption. If this reasoning is pushed,
> then nearly no localization works happens during the release cycle and
> everybody waits for the freeze. The, when the freeze comes,
> translators are squashed with gazillion of call for l10n updates.

Hence the need to do this by the package release schedule, not the
distribution release schedule.
> So, by far, regular updates (and therefore regular calls for l10n
> updates) are really needed.

Yes - each time an upstream package (because that is where the
non-debconf translations necessarily live) is released, there should
be a preceding update of the translations in that specific package.
Alternatively, if the package strings are stable and translator work
wouldn't be wasted, then the POT should be packaged and translations
done after release. The problem with that is many packages which have
stable translatable strings are also stable source code and don't
release often - having the up to date POT file in the source package
doesn't help anyone if the package itself does not get released for
months after the i18n bug is filed. Very few upstreams bother with
interim i18n releases in the absence of other bug fixes.

I mostly want to avoid throwing away translated strings here but I
also want to try and avoid having usable translations hanging around in
our BTS or the upstream bug tracker for months on end because the rest
of the package doesn't need a release. I have two such bugs now - the
library concerned just doesn't warrant a new upload. It won't work it's
way up my TODO list for quite some time yet. The two bugs concerned
were filed after the original deadline for the previous string freeze
and are hence waiting for the next one.

It comes down to a problem with the gettext design - it's too tightly
integrated into the upstream build process to be able to easily handle
separating the po/ directory into a separate upstream tarball which
could be updated separately from the rest of the source code.
Documentation PO support can be done that way, (but mostly isn't),
runtime program output translations are harder.

> For instance, look at dpkg or apt
> translation work: only those who kept the pace can now follow the huge
> numnber of needed updates (I'm still fighting with dpkg manpages
> French translations just because I gave up on updates for a few
> months).

I believe there is an argument here for not expecting i18n updates for
1.2.x updates, only in 1.x.0 updates. Native packages do need to be
handled differently but, again, churn doesn't help anyone because it is
demotivating. (As you, of all people, know all too well.)

Why translate strings for 1.2.5 if the functionality is modified or
even removed in 1.3.0?

This is a particular problem with documentation because sometimes point
releases introduce complex new ideas which need docs. There's no
one-size-fits-all approach possible here, teams need to coordinate
their i18n work.

> So, anything helping this to happen is welcomed....which includes
> providing up-to-date POT files (and keep them in the various VCS which
> is something I always fought for.

Churn is the problem here, IMHO. Many packages just change too fast at
specific times to allow generated files like the POT into the VCS. i.e.
the source code is changing and whether or not the translatable strings
actually change, committing the POT every time (because it timestamps
itself every time it is checked) is a PITA. Yes, wrappers can be
written etc but those are VCS or package specific. Keeping an up to
date POT file in VCS is generally the wrong approach because it is a
generated file and because intltool insists on timestamping the damn
file every time the build so much as looks at it. Then, if PO files
exist, every single one is updated every single time a new line is
added to any files in the source code which also contain translatable
strings, making even a single-line commit into a behemoth of thousands
of pointless tweaks to the POT and PO files. That makes upstream work
impossible because the important diff is lost in i18n fluff. So, *no*,
please do not recommend putting generated files into VCS and especially
not the POT file. Churn in the PO files is bad enough and if the build
is modified to not constantly update the POT and PO then the POT and PO
will be constantly out of date, leading to wasted translator effort.
These things need to be coordinated, not left to the build process to
sort out.

I had this specific problem with drivel - it hadn't changed for months
and then I had to do a complete refactoring of the code for GTK+3
support. I modified every source code file in the package over a 4
month period (completely rewrote most of the UI) but did not touch the
PO update process until the very, very end because so many strings were
changing. Translation updates were lost in that process but keeping the
POT updated during that time would have been equally pointless and an
unnecessary burden on the upstream process.

I've also tried fly-by translation sites where the POT is constantly
available and it and the PO files are constantly updated. The
translations are always incomplete and frequently error-prone. Errors
in PO files can break the main package build process, so it is not
surprising that upstreams do NOT want to give translators access to the
upstream VCS to keep the PO files constantly updated or even commit
updates to PO files until the code itself has stabilised ahead of a
release - hence keeping the POT file in such a VCS is just pointless

 > > Therefore, I think you should think this through more carefully.
> > Blindly enforcing that all source packages which support l10n also
> > include the POT file is counter-productive. Encouraging *some* to
> > include POT files once the package is in a state that the strings
> > don't change that much any more is good. Encouraging maintainers to
> > allow time for a genuine string freeze and make a call for
> > translations, including the updated translations in the actual
> > release, is a FAR BETTER idea.
> That works well with developers that have a strict developing agenda
> with planned released, development plan, etc. You're one of these,
> Neil, and that's much appreciated. However, other development styles
> may better fit with constant providing of localization material.

True - which only reinforces the point that Policy cannot mandate one
single approach here, it needs to be granular and package-specific /
team-specific. Any general approach will either cause translators to do
work unnecessarily or will impose a demotivating burden on upstream

Encouraging better coordination between l10n teams, DD's and upstreams
is the only real answer here, to find a package-specific and/or
team-specific approach which neither leaves i18n out in the cold nor
causes unnecessary work for either l10n or upstream.

Nothing in the above is meant to be done on a Debian release schedule,
this is all concerned with package release cycles.


Neil Williams

Attachment: pgpnq282cJyIl.pgp
Description: PGP signature

Reply to: