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 churn. > > 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 development. 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 ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgpnq282cJyIl.pgp
Description: PGP signature