On Tue, Sep 30, 2003 at 08:07:13PM +0200, Bartosz Fenski aka fEnIo wrote:
> On Fri, Sep 26, 2003 at 08:52:40AM +0200, Martin Quinson wrote:
> > > Polish Debian Documentation Project would like to start translations of
> > > po-debconf templates. Since there will be more packages using po-debconf
> > > because of obsoleting old template solution, there should be some
> > > central repository of po-debconf templates and translations.
> > >
> > > The ideal way would be to use CVS.
> > I also think so. My plan was to put the material found by the
> > w.d.o/intl/l10n generating scripts into a CVS with a nice merge mecanism
> > adapted to po files.
> Great!
>
> > Then, a mail robot in the spirit of the one used on
> > http://www2.iro.umontreal.ca/~gnutra/po/HTML/
> > would be used to handle incoming signed mails from translators, check the
> > correctness of their work and merge it in the CVS.
> Hmm, but this robot will be working in parallel to the normal CVS access?
> The problem is that I hate attachments and working via mail. I mean mail
> is for discussing, and not for talking with the machines ;)
The nice things with emails is that you can deal with authentification very
easily. In my mind, all mails would have to be signed with PGP, so that we
can trust the "commit" without dealing with tons of account on the server.
I know that speaking per email can be rather cumbersome, but we can do a
client on the translator side to generate proper emails. I think about what
Nicolas Bertolissimo made for the ddtp. Adding some rules to your mail
filtering mechanism (either procmail or other, it works also for kmail), the
data from the server is processed properly. Then you edit your stuff like
usual (kbabel, po-mode, vi). Then a script can be used to send back your
work to the server in the proper form.
Of course, that's a lot of work to design and do that script family, but
once it's in place, you have a better guarentee that translators cannot mess
with the files, you allow them to work offline and you solve the
authentification process in a more scalable way than managing an account on
the server for each translator.
> > Finally, a nice tool in the dh_ spirit would allow the maintainer to
> > retrieve the existing translation against their package and include it.
> Nice idea.
>
> > - Put the material in a CVS
> > - Find a CVS host accepting to deal with the load it will induce.
> > - Setup the tools around CVS to have proper merge with msgmerge instead
> > of a brutal replacement of file
> > - Modify the wannabe-DTC scripts to put the material into that CVS
> >
> > - Let the translator put their work into that CVS
> > - First, using the classical CVS solutions
> > - Setup a mail daemon checking the validity of signed mails and their po
> > file attachement which can be used to provide the write access without
> > the possibility to break anything in the CVS (with no need of rollback).
> > - Widespread the use of that robot
> If it'll be one of the solution then I agree. But I'll be thankful if
> putting translation by CVS will be always possible.
In my mind, CVS direct access will still be available to some people, like
the administrators of the stuff and the language teams coordinators. I just
want to reduce the amount of accounts on the server without putting the
commit responsability on the shoulders of human beings.
> > - Let the maintainer get the translations from that CVS
> > - First, using a classical read-only CVS access
> > - make a nicer interface, using a script or something
> > - Allow maintainer to put the translation manually, for example a week
> > before the real release so that translators are given the time to do
> > their work without needing to reupload translation only packages such
> > as JoeyH makes all the time (thanks to him)
> >
> > - Improve the i18n of documentation to fit into that picture
> > - work on po4a to make it more reliable (mainly documentation bugs are
> > known for now, but I guess that this poor documentation prevented real
> > users to use it and break it in more critical ways)
> > - Add support for the missing formats (mainly docbook-xml and texinfo)
> Seems good. How non-developer can help you?
Dunno exactly. I wait to become DD (before chrismas, I hope) to get the
ability to start the server on alioth. Right now, almost everything is
blocked.
You could try po4a to see if it's ready for release, provide patches to the
bugs known on http://savannah.nongnu.org/bugs/?group=po4a At least one of
them are documentation bugs, where the man page does not reflect the reality
of the scripts. This reality is reflected by <command> --help, so fixing
this should be easy [*].
Use it personnaly for your own translations, in order to 1) ease your life
of translator 2) search for bugs 3) incitate developpers to use it.
Translate the documentation of po4a to your language. That's a good way to
test the tool since it naturaly use itself for translation of documentation.
If you want to see the support of po4a for yet another format, patches are
welcome (and that's not really hard to do, provided that you have some
notions of Perl programming).
If you cannot do it yourself, fill a bug about that on savannah as
reminder for the ones who can.
You could also look at the pages w.d.o/intl/l10n and use them in your
coordination work. I guess it will lead you to ideas about improvements I'd
be glad to hear.
[*]: I'm currently writing my PhD, which explains why I do not do that
trivial fix myself.
--
The unavoidable price of reliability is simplicity.
--Hoare
Attachment:
pgpoOH6TlNWOS.pgp
Description: PGP signature