Trimming the CC - no need for the bug report in this any longer. On Sat, 28 Apr 2012 20:40:56 -0400 David Prévot <taffit@debian.org> wrote: > >> Updated Portuguese translation for multistrap's PROGRAM messages. > > > > ... using an outdated PO file from who knows where. > > I'm afraid you made a little confusion when you send your call for > translation on April 21 with the following header: Right, in that case there is another glitch in the translation workflow, po-debconf-reportpo needs to understand the status of the po files and update against the source before generating. Both sides of this workflow need more assistance from the relevant scripts. I'm thinking that we need something else instead of po-debconf-reportpo which doesn't expect debconf strings but has support for intltool and another for po4a. > > there needs to be structural > > change in how the l10n teams work to guarantee quality submissions into > > Debian. > > That's a very good advice. Depending on the team, we often have a > process that tries and guarantees the quality of the *content* > translated, but we don't always check if the files work on the technical > point of view. Please, don't hesitate to share your ideas to improve the > technical part. There needs to be a mandatory check that the strings work. Many translators don't even do a msgfmt -c check but we need more than that. The update needs to be checked within the package build. It is incredibly frustrating when there are either regressions or build failures or formatting changes introduced when the patch is applied. No other patch from a Debian bug would be accepted in this way. If this isn't fixed, i18n should stop using the patch tag. Patches need to be tested that the patch applies cleanly, does not break the build and does what is claimed in the bug report. Again, debconf isn't the problem here, it is extending what is basically a debconf-only workflow to upstream messages. At that point, the workflow is just useless. > > The current system just doesn't function effectively. > > Well, it clearly depends of the projects within Debian, I've had many > very good experiences, maybe you have just been unlucky… debconf updates do happen cleanly - probably because the scripts are simpler, there are no upstream changes and the build environment / requirements are therefore consistent and reliable. Problems start with program message translations, get worse with documentation translations and peak in a complete mess when both are combined in the same package. TDebs would have to cope with worst-case scenarios, as does the translation workflow before TDebs can be accepted. i.e. the workflow has to be seen to be working before I could persuade ftpmaster to accept TDeb changes. I've been putting a lot of time into integrating Emdebian into Debian - there is no way TDebs can be considered with the current status of i18n support outside of debconf. > Discussions > between developers and translators usually help a lot to understand each > other's expectation. There is not one single workflow, TIMTOWTDI, but > since we share a common goal (quality and translated packages), I have > no doubt that developers and translators can work things out. I'm thinking ahead of the likely problems that would arise if the TDeb proposal was ever restarted. > > There > > *must* be a barrier between the translators and maintainers, > > This “must” seems misplaced, but I can totally understand if *you* don't > want to deal with translations. All translators are not package > maintainers, and you can't expect all of them to checkout the last > version on your VCS and build the package with their last update before > actually sending it to you. Then the patch tag needs to be dropped, except for debconf. This level of work is expected for all other uses of "patch". This is inherent with doing translations beyond the level of debconf because only debconf can be tested without recourse to the files outside the debian/ directory. i.e. upstream. I don't have the answers here, I've somewhat lost the desire to push this much further. Maintainers, especially upstream maintainers, are not going to put up with these kinds of problems. debconf can use the patch tag, it isn't a problem. Program messages and documentation translations are completely different issues. The problems here all come down to translator workflow being biased towards debconf management where the problems are tightly constrained by the Debian/debconf system itself. Maybe po-debconf needs to drop all non-debconf support and a new interface designed. Particular emphasis must be placed on separating the various levels of translation so that bug reports are not mis-titled, the correct PO file is always attached and that *if* the patch tag is used, the *patch* applies cleanly, with no regressions and no build failures or build changes. Separate templates, checks to prevent new tools being used with debconf and vice-versa, checks to not accept po4a PO files when intltool is required etc. > If you are not ready to deal with possibly non technical contributors, > you may wish to share this part of the work with someone else. .. with even more delays in the string freeze process. Hmm. I think this needs to be automated. We need something closer to piuparts for this. If TDebs were practical, there might be a way of this working, if fully automated: 0: maintainer changes translatable strings 1: build system auto-updates the PO strings - PO and POT are always in sync with sources before upload. Make it a release goal that packages and build tools ensure PO files are updated at every build and that the build fails if changes are detected. 2: maintainer uploads without updating translations but with updated PO strings. 3: separate upload against the version already in Debian, not the version in VCS - this allows fully automated, reliable testing. This will allow valid patches to be created, tested and signed-off. 4: maintainer applies patches. The problem is that the translation workflow has to be improved before TDebs work could restart. Maybe debian-i18n should discourage/prevent translations of strings which are not currently in Debian unstable. > Since I > already take care of the French translations of a few packages you > maintain, I would be happy to handle all translations of those packages > on your behalf, and also of your other packages if you wish (including > multistrap). More delays are not the answer. > > some layer > > which can make some assurance of quality by rejecting updates like the > > ones I've had to handle. > > You may also consider using the Translation Project [0] if you want to > rely on an non-human interface that will do some technical checks before > accepting a new PO file. Been there, tried that. Awful, awful mess. Even further removed from the source code and no decent checks on the final translation. > Please note that having some sort of strong > wall between developers and translators is not fully desirable either, > and can have other bad side effects. An automated accept/reject interface is certainly desirable. More than that, if debian-i18n want ways to upload translations directly to Debian, such a barrier interface will become mandatory. It just needs to be understandable by both sides. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpFHFu85JuuW.pgp
Description: PGP signature