Re: Coordination of translations via debian-l10n-* lists
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2004-01-18 03:25, Nikolai Prokoschenko wrote:
> On Sun, Jan 18, 2004 at 02:38:23AM +0100, Tim Dijkstra wrote:
> > Well here goes: As I said translator and reviewers use special subjects
> > of their posts to the l10n-lists, they have the following form:
> > [state] type://name
> > Where <type> is for example, po-debconf or wml (webpages). <name> is
> > the subject of translation. And <state> can be one of the following:
>
> Let me explain our (russian team) way of handling the load. It it
> slightly diffent, and somehow I think іt's more effective. Let me just
> quote a personal e-mail to Denis Barbier:
>
> ================
> BTW, I find you practise at the moment a little bit unpractical. What we
> do now at our list is to create some kind of "gate". That means, that
> every to-be-translated file (only d-i at the moment) gets renamed and put
> into our own CVS on alioth. Every commit to this CVS goes to the list as
> a kind of RFC. The translation gets peer-reviewed (not extensively at the
> moment, but we have just reached 100%, but it will come) and every person
> with a CVS write access can correct the translation. Every now and then,
> the translation gets synchronised with the main d-i CVS. This way, one
> single person is not "bound" to a certain file (which could be just too
> big in relation to the others) and can also commit only a portion of
> translation or maybe a simple dictionary synchronisation.
> ===============
actually I think that having a 'maintainer' for each translation, having the
file bound to that person is a good thing: usually each individual file
isn't that big so having multiple persons working on the same file is
unnecesary.
> Right now, we are still a rather small team, which only translates
> debian-installer at the moment. But we have big plans :) Currently, we
> are trying to think of a system, which would track the changes in
> .pot-templates and automagically merge them with our files and commit
> them immediately to the interim CVS. This way, a translator can be
> assured, he edits the latest version available.
take a look at http://people.debian.org/~barbier/intl/l10n/LL (where LL is
the language code), po-files with changes merged in are already available.
NOTE: these detail the situation in SID, meaning that using just these
you're always one version behind when there's a string change. Off course
those package-maintainers that care about l10n tend to contact the last
translator asking for an update before the upload to SID
-> again it's a good thing to have somebody bound to the translation
> Also, as you can, we have re-phrased the Linux developing model, "Release
> early, release often" to the "small bits as soon as possible" sense. I
> hope we can reach fairly good quality with this method.
>
> Our current concern is how to proceed further. Our plans are to build up
> this system of "interim CVS gate", but I'd really like to have a
> global Debian i18n solution, from which every translation team would
> benefit.
> Let me say a couple of words to your system: it's good, but I miss the
> dynamics. For example, the debian-installer translations have been last
> updated with a RFR about a month ago. I haven't checked the archives of
> the list, but I guess this means, that these translations are "stuck"
> onto the one person translating them (cobaco).
actually in this particular case it just means that there has been one
_huge_ [DICO] discussion. Comments unrelated to that term have been merged
(and committed to cvs).
also for d-i work http://people.debian.org/~barbier/debian-installer/l10n/LL
is the best place to check progress.
> How can someone else
> continue the translation and stay synced to the others? Do you have any
> centralized location for the latest files? That didn't become clear.
no need to stay synced:
there one person doing the translaton for each po-file, once the po-file is
translated it is send to the list, for review, where again the translator
is responsible for merging comments back (and in case of differences of
opinion it's the translator who has the final say)
if you'd need to continue a translation you'd ITT it (at which point the
person that has last worked on the translation has the chance to object),
and grab the latest version from the overview page (or with apt-get source
directly from SID)
> IMHO, it is easy to get lost in the whole scheme, if you are really new
> to all this. For example, if a file has been marked as ITT let's say a
> week ago, I (as a newbie) wouldn't know, if I could touch it or not. I
> would not know, how far the other translator has got. This problem is
> eliminated with our solution - take any file you want, most changes are
> commited within several hours, so there should not be a conflict with an
> existing work.
1. when in doubt just ask on the list
2. at the moment French is the only language even close to having 100%
translations for all po-debconf templates, there is more then enough left
to do, so if something is ITT'ed there's more enough other things left to
translate
> So far, so good :) This was just a presentation of our method, comments
> are encouraged. It would be great, if we could develop a solution - KDE
> and Gnome teams are far ahead of us :(
>
> > I can imagine that this would also be useful to other language teams.
> > So maybe we should optimize it a bit and in the end give it a place
> > under http://www.debian.org/intl/
>
> This should definitely happen :)
- --
Cheers, cobaco
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFACfm15ihPJ4ZiSrsRArIfAJ9M9OmN6Lbh6JT3uo6jHaz2+qd2CgCglxmk
UfPTk9gazJKvy361YtHSk3I=
=tIik
-----END PGP SIGNATURE-----
Reply to: