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

Re: Help needed with DDTP strcture



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Quinson wrote:
:: On Fri, Jun 17, 2005 at 10:30:07AM +0300, Eddy Petrisor
:: wrote:

:::: On 6/17/05, Martin Quinson <martin.quinson@loria.fr>
:::: wrote:

::::::::    martin> Juste a stupid idea: I know Christian
::::::::    martin> is dreaming of setting up a pootle
::::::::    martin> server on debian machines to ease
::::::::    martin> translation works. What about using
::::::::    martin> pootle for the interface?

:::: Why more division in the translation effort? Why
:::: can't it be _only_ _ONE_ central place where
:::: people can do their work/get info?

:: Because it still has to be implemented. :)

	I was talking with Otavio Salvador in the IRC
another day and I was wondering if we could work on
DDTP and build the framework based on it.


:::::: IMHO, the tricky part will be to interface it with
:::::: all the code pieces we have here and there (dl10n,
:::::: amongst others), and the new ones we will >develop
:::::: to fully leverage the beast.

:::: Do you want to extend pootle with the l10n pieces
:::: and tools in Debian? Contribute back to Pootle?

:: Some feature has to be implemented within pootle,
:: such as a reviewing mecanism (a way to not
:: distribute a translation before it was seen and
:: approved by at least N translators -- used to
:: work in DDTP -- and maybe a bug tracking mecanism
:: for translations) and mail interface (for the ones
:: doing most of their translation in the Paris
:: transportation system and thus off line and such).

	Here it goes, the initial idea is setup a
kind of "robot" to grab parts from the packages that
could be translated and sent it to translators when
they request.

	One of the gratest features of our BTS is
that it is controled by mail; DDTP used to be a very
easy to use tool, because of its simples mail system
(ok, not that simple, but with the correct explanations
it is far easier than CVS/SVN).


:: But on a larger plan, pootle would become one piece
:: of the picture. Maybe something like having katie
:: (or a friend) run dl10n on all uploaded packages
:: to extract the stuff which need to be translated
:: and push it into pootle.

	Same concept, but instead of pootle, DDTP
(which obvioulsy need a new name).


:: The extraction could be eased by po4a for everything
:: beside regular program message catalogs.

	Yep. And then sent it over e-mail and using
the DDTS review system, could be helpful. Of course,
we have to review the code, sign it to be sure that
there is no compromise and then solve its bugs and
improve it. :)

	I would like to help on this, I'm not sure,
but sounds like a good way to integrate with dl10n,
html statistics generation and other useful related
info.


:: Then translations are feeded by translators into
:: pootle, something could trigger an automatic upload
:: to the archive so that the users benefit of them.
:: These translations would use the override mecanism
:: to get also added in ant further [manual] upload.

	The advantage of e-mail is that we can
work off-line, get a lot of work, do it offline and
when we are back on-line send it to the server.


:: Issues here are: 1) not to mess with maintainer
:: work, ie don't erase translations provided by
:: the maintainer with translations provided through
:: pootle. Doing so only for packages containing a
:: debian/dl10n file (and thus specifying that the
:: maintainer wants so) could solve it.

	Hmmm, could we write some policy to clear
specify it?


:: 2) technically doing an upload when translation
:: is provided. You have to actually build a new
:: package with the same content beside the
:: translation, a new changelog entry and a
:: version number, etc. Cryptographic issues may
:: also arise. It's not impossible, but is still
:: tedious. This tool could also help in l10n-only
:: NMU rounds.

	But... just an idea, the maintainer could
send a signed message to the server allowing a
new build with the translations that already had
passed QA process? Or we can have and i18n task
force to keep it updated and considered as special
uploads, like QA and Security.

	Since it is Debian work, it shouldn't
affect .orig.tar.gz, should it? Of course, we
need a way to give it back to upstream. Or we
should enforce a new upload? Or some way to get
it just "approved" (tm)? No idea of which one is
the best and most non-harmful option. ;)


:::::: We may eventually actually implement the
:::::: dreams of a system automatically extraction
:::::: all the translatable material from uploaded
:::::: packages, and doing

:::: The itch is soooo bad that is impossible to
:::: think that nobody will not scratch it.

:: I'm scratching it since years, and I'm not the
:: only one. Even if the big picture becomes
:: clearer and clearer, with different software pieces
:: maturating, I can't imagine that it will become
:: reality before etch+1, actually.

	Automatic translatable material being extracted
from packages maybe not, but perhaps we could make the
whole proccess easier, adding then more man/woman power
to the l10n framework, with this, we can get the
translators more involved with CVS/SVN and other
programming related skills, doing a neffort with
maintainers to get their packages translated. Is sounds
too crazy/insane?

	AFAICT, Christian Perrier is doing some
work on that way with 'dpkg'. I don't know if we
could think to walk in the same way, but, looks
like a good try. :)

	Kind regards,

- --
//////////
// Felipe Augusto van de Wiel (faw) <felipe@cathedrallabs.org>
// GUD-PR / DUG-PR || http://www.debian-pr.org
// GUD-BR / DUG-BR || http://www.debian-br.org
// Debian Project  || http://www.debian.org/
//////////
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQFCv4suCjAO0JDlykYRAnnFAKDOpXFEUQcqECDssfczqiaEMQzJoACfRwxk
ZmAw7jBEBPjEJ/WMwRJr9hM=
=r6Wg
-----END PGP SIGNATURE-----



Reply to: