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

Re: If there were translation teams...


If there were translation teams, and I was the coordinator of my team...

Isn't that the case? Do you want to be the maintainer of all modules for catalan now or not? I haven't heard any objections, so it's yours for the taking. :)

 * I would encourage all translators to have a CVS account and commit
their changes, *provided* the file has been *reviewed* and *accepted* by
the rest of the members of the team.

I'd encourage them too. But sometimes you want to commit something you're working on, even though you're not finished. And sometimes you'd like to commit something cos your finished, even though nobody else had time to review yet. If it's no good, you can always roll back. What our system does... you take a module, you work on it, you commit. If it's not finished, you have to release it if you don't want to work on it anymore. If it's finished, you're auto-released. If there's no maintainer, end of story. If there's a maintainer, module set to QA, all commit access blocked for everyone but the maintainer. Maintainer has to approve with either a commit or by clicking [Approve]. Maintainer can chose to wait for feedback from other reviewers.

 * I would encourage all translators to apply as maintainers for those
files that they are familiar with, either because they have translated
them before, or because they use them often, or for whatever reason. I
would still give priority to the last translator to be the maintainer if
he/she would like to.

I'd encourage them too. And I'd give priority to someone who was active translating the file.

 * I would make sure that whenever a file is "taken" or "released" the
team's mailing list, and specially the maintainer of a file, are
informed about it.

Yes, good point, I should add that feature. So far, only the translator is informed if s/he has been released. The maintainer is informed of commits, but informing the maintainer of take and release can indeed be helpful. And nothing speaks against the maintainer being a group, really.

 * I would have more time to translate, and I would have to spend less
time coordinating the team, assigning files and keeping track of who's
doing what and for how long they have been doing it.

That's the aim.


*** Translator: the person translating a file at a given time.

That's the intention.

*** Maintainer: is the person responsible to keep updated a file,
whenever it needs improvements. This person would be responsible for any
translation bugs on that file. He/she doesn't have to be the translator,
though. The translator might change over time, upon team member's

That's the intention.

A Maintainer should be informed about translators taking their files,
and maybe maintainers should be able to commit at any time independently
of who's taken the file... (if possible)

Currently informed of commits, but of takes would be good too, I agree. And the maintainer can commit at any time, that was my main point for adding a maintainer.

Briefly, a maintainer is the person to contact for a certain file, and
it often happens to be its translator too.

That's the intention.

*** Coordinator (team): the person to contact about anything related to
the translation of a certain language (as described in Christian Rose's
description of the GNOME Model¹). It is the maintainer of all those
files that have not yet a maintainer, or for whom s/he is the real
maintainer, of course. It will commit files and act as a maintainer on
behalf of translators that have no CVS account.

That's who I'd assign all modules to by default (as a maintainer). That at least is the intention. When we have team pages up, we can formalize that all a bit more.

The coordinator coaches new translators (could be done by maintainers
Possibly the coordinator should have full CVS access to any file that
belongs to its language.

That is a valid point. So far, the coordinator has only full access to the files that are "unmaintained" (by being their maintainer). But I believe that's a good feature to add. And I believe everyone experienced can coach anyone new.

The election of the coordinator is up to each team, any changes about
coordinator must be submitted to this mailing list.
The coordinator should be informed about changes in Maintainers.

Maybe there could be the role of the "translation project coordinator"
much like what Christian Rose is for the GNOME project, and which I
suppose falls into Sarah Wang right now.

Fedora translation page should have a description of the translation
process, teams, coordinators... you get the idea :)

Well, that's the plan, it'll just take a little longer. Sorry, if we can't put it up all at once.

All that... of course, if there were translation teams...

Well, there are, we know that, don't we? :)

Briefly, combining teams with the new method have a lot of potential
that we should explote.

Again, this is only my view, and there might be flaws, if there are I
hope you can spot them and tell me :)

No, I didn't spot any flaws, a lot of your suggestions have already been put in place with the new system. And that exactly is it what puzzles me. Given you've just suggested a lot of things that we've just put in place with the new status pages, why again is it that it is criticized so much? Why even do people say it nullifies existing translation teams? I don't have to get it, or do I? ;)

Best Regards,

Best regards,


Bernd: these might be the scriptures you were asking for :)

Nah, that's pretty much the path I am going, as said, and a lot has been implemented with the new upgrade. I simply won't restrict anyone cvs access until we're fully organized, that's all. :)

Note: not all members of a team have to be translators, there are also proof readers, philologists, users, etc, and not all of them have to have CVS access.


Fedora-trans-list mailing list
Fedora-trans-list redhat com

Dr. Bernd R. Groh                       Phone : +61 7 3514 8114
Software Engineer (Localization)        Fax   : +61 7 3514 8199
Red Hat Asia-Pacific                    Mobile: +61 403 851 269
Disclaimer: http://apac.redhat.com/disclaimer/

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