If there were translation teams...
bgroh at redhat.com
Sat Jun 26 06:16:07 UTC 2004
>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? ;)
>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 at 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
More information about the trans