On Sun, 29 Apr 2012 08:38:36 +0200 Christian PERRIER <bubulle@debian.org> wrote: > (skipping David's answer, wchi I mostly agree with. Thanks, David, for > taking care to de-escalate the issue with Neil, who is a longstanding > i18n-friendly person and who I don't like to see ranting because he's > also a friendly person in general..:-)) Sometimes a rant is needed ... I've trimmed the CC too. > On my side, when I act as the barrier suggested by Neil (a kind of > "translation coordinator" between the maintainer and translators), I > use a few scriptsbefore committing files. > > The main one is the one call "po_test" (attached along with > "check_var.pl"that it uses). I agree it should > be more widely exposed but it is in shorta quite crude hack and would > therefore need to be cleaned before being packaged. > > Still, it may help those people in the i18n crowd who would like to > offer doing what David offers to do with Neil : act as this "barrier" > between maintainers and translators. It would be interesting to have > this for internationalized Debian native packages (those packages > that, by definition, rely only on Debian for their localization). We > already have this for a few of these (dpkg, apt, aptitude, "Neilstrap" > packages...:-)). The scripts are a start but there need to be changes at the maintainer side too - podebconf-reportpo needs to be constrained to debconf and new tools with new templates written expressly for intltool translations and po4a translations. I think we also need to separate the three modes in all stages of i18n processing. Current mechanisms can work fine for debconf but need to be constrained to only debconf. There is constant confusion about terms when dealing with non-debconf translations - agreeing on terminology is the first step. Instead of program, runtime or other words, let's use the tool being used - intltool. That allows the tools to be constrained to only intltool support which means that the tools can do intltool type stuff and justifiably fail with sensible errors. Then, for manpage / documentation translation, we could just stipulate po4a. Flexibility is the wrong solution here. We need predictable, constrained tools which do a small job, fail predictably and refuse to work outside their sphere. One tool per role, no equivalence, no confusion, no overlaps. That way, we prevent confusion in the final submissions. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpV7QNdk_nd5.pgp
Description: PGP signature