> I joined recently the translation project. How many
> hungarians are involved? Can anybody tell me?
The Hungarian translation team is "led" by Tamas Szanto
[tszanto@MOL.hu]...well he's the uy who did most of the translating.
Can't exactly tell how many we are but any help is welcome :D
With kind regards
Thank you very much for your hard work and good job! :D
I've just tried the updated status system, it really works well.
======= 2004-07-01 09:13:50 Quote from your mail =======
>since there has been some confusion about the new status pages, I feel
>like I need to summarize what actually happened, and let me assure you,
>it wasn't a step away from teams. Established language teams are well
>considered by the new status pages, much more than previously. Yes, we
>are still missing team pages, and we do apologise for not having had the
>ressources to put them up yet, but it is our intention to do so. Things
>are moving towards teams, and we'd like to encourage them, however, we
>are reluctant to mandate things and tell you how things are going to be,
>since that's not entirely up to us, but also up to you.
>So, what is new?
>First new thing is that a module can be assigned to a Translator and
>there is a [Take]/[Release] mechanism in place. What exactly is a
>Translator in this respect? A Translator is a person translating a file
>at a given time (thanks, Josep ). What's it for? Two things. First, so
>other people know who's currently doing what, and second, to minimise
>conflicts because two translators are working on the same file at the
>same time. You say that wouldn't happen if you'd have a group and one
>coordinator to coordinate all translations of the group? For a small
>group that might be feasible, but if you have one coordinator and 70+
>translators, things can get quite difficult to manage this way. Also, we
>would require the coordinator to be available at all time, we'd require
>the coordinator to make a decision, or we'd require 70 people to
>discuss about who's going to translate the file. Sometimes it is much
>easier if, given the translator can do a good translation of the file,
>whoever sees first that there is a file to be translated, that this
>translator just does the job. Sometimes, there can be too much talking
>about things, and it is, in fact, better to just do it. And there's
>nothing that says that that's not how the group wants to do things. Not
>all groups work in the same way. That might have an effect on
>consistency? If the group has already agreed on a certain terminology,
>and a person of that group simply does the job, without requiring too
>much talking about it, how? As said, different groups work differently,
>and I do not like the idea to build a system that is set to a certain
>way, I rather build a system that can accommodate a large range of
>behaviours of groups, or even of individuals. And yes, I am aware of the
>disadvantages of this system, but IMO, groups should form because groups
>want to form, and not because they have to form in order for the entire
>system to work, groups should form in the way they want to form, and not
>in one certain way, because that's the only way the system accommodates
>How was the [Take]/[Release] mechanism intended to be used? A file
>should be [Take]n before starting the translation, before doing a last
>cvs up. Then the file should be worked on, and it should be commited
>whenever you stop translating it. If you intend to keep working on it
>soon, you keep the file, otherwise, you [Release] it. If you do commit a
>finished file, it'll be released automatically.
>This allows people to work independently, without requiring a group?
>Yes, it does. It doesn't encourage groups? No, it doesn't. It is not the
>job of a system to encourage groups, it is the job of people. People
>encourage other people. I'd encourage anyone to join a group, everyone
>should encourage everyone to join a group. If it is really the case that
>most people ask for groups, and want to work in groups, why should it
>even be necessary to mandate them? Shouldn't it then be the case that
>most people actually do work in groups? It is up to every individual to
>form a group, and to work in groups, it is, IMO, not up to one
>individual to make groups happen.
>What else is new?
>The system allows for a module to have a maintainer. What exactly is a
>Maintainer in this respect? A Maintainer is the person accountable for
>the translation of a file. A Maintainer is the person commited to
>providing a high-quality translation of that module to the
>user-community. Yes, the maintainer is also the one who takes the blame
>for a bad translation. As such, to compensate for the additional
>responsibilities, the maintainer also has additional privileges. The
>maintainer can manage who's translating the file. A maintainer is now
>informed if someone takes the file (thanks, Josep ), and can chose to
>release the module and take it herself/himself or to get someone else to
>take it. A Maintainer is also informed of all commits to the file. If a
>module has been finished, the module will automatically be set to QA and
>the maintainer is now the only person with commit access to this file,
>unless s/he [Approve]s it, or commits it, which we recognize as approval.
>How do we support established translation teams? By making them
>maintainers of modules, by letting them take over the responsibility
>they've been carrying in the past, and by now providing them with a
>mechanism to better manage the translation of a particular module, also
>with informing them if somebody else is working on the file. Do we
>support coordinators? Coordinators of small teams are invited to apply
>for maintainership of all modules of a certain language. In general, and
>if there are no objections from other members within the same language
>group, this will be granted. For large teams, it may be better to split
>maintainership to several individuals by coordinating/maintaining a
>group of modules, however, we'd still, given there are no objections,
>grant such request. If at any time, there are objections with regards to
>a certain maintainer, everyone objecting is invited to make their case.
>Every opinion will be heard, and we're happy to take concerns to a
>That's about all. Again, apologies if the introduction of the new status
>pages has been confusing, it wasn't our intention, and we will discuss
>any further change on this list now. We'd also like to encourage people
>to speak up, and not just if things aren't the way they want them to be.
>After all, it is everyone's community.
>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
>Fedora-trans-list mailing list