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

Re: Fedora and Translation Teams


First, I am just a stating *my own* openion here and it is not *fedora* openion or redhat.

Certainly. I believe everyone here is aware that people are usually speaking for themselves, without any particular hat on, unless otherwise stated.

Why then did the email from arabeyes talk about fedora policies, though they really only talked about what *I* said? I believe this disclaimer of Sherif was necessary, otherwise, we might have gotten a reply about additional fedora policies, that aren't really any fedora policies, or would you disagree?

I am getting confused and lost in the long emails. Can Mohamed or
Youcef please explain in short email, in points : what are the
problems as I failed to follow all long emails here. I do not
see any changes in the policys, the only thing happened was
to prevent multiple translators committing changes at same time.

I think reading the long detailed mails is a good thing; they explain quite a lot of background, which the heated flamage mails don't.

Anyway, I think everyone agrees that avoiding translation conflicts is a
good thing. It's not really that which is causing the debate. The point
is in *which way* this is achieved. Traditionally, translation projects
are communities where volunteers join seperate language teams to produce
translations, and in this work the teams naturally also arrange these
issues for themselves and arrange who works on what and so on.

Agreed, and this is a good thing.

In Fedora, language teams are right now bypassed completely by the
organization, so that each contributor by default just works for himself
or herself, thus eliminating all benefits of teams. Teams are not
mandated nor encouraged by the process, which many experienced
translators seem to believe is a serious mistake.

Maybe it was a mistake to put the new system online, maybe we should go back to the previous one, in which everyone can commit again at any time? Would you prefer that? This issue is open for discussion. There's still a lot of work to do I believe, I merely thought the new system was a step into the right direction. If it's not, let's fix it, there's no need to suddenly jump up and say that other people shouldn't have a module assigned to them, because they've got nothing to do with the translation group in place. Before, they didn't have a module assigned to them, but simply did a commit. You don't think it's a step into the right direction if you can now see who's doing what? Ok, understood. Maybe we were wrong. Are there other opinions?

I went through Mohamed email and I am not sure where all these
issues came from?

I belive that by people establish teams here, things will be
start to shape and take better form. Let me ask first, when Arabeyes started translation, did they have full list
of things how it should be? Things are still being built and
taking final shape. I belive in the freedom of allowing people to contribute.

Certainly, so do we all. The key issue here is: when would the teams take shape, and what would those teams look like?

Hang on, aren't you part of the community too? Isn't it as much up to you to form such teams as it is up to me? Or do you believe it is RedHat's responsibility to mandate teams? What would these teams look like? I don't know, what do you want your team to look like? Or do you believe it is RedHat's responsibility to define what exactly a team is? There are teams in place, and as said, that's why I've added the option of becoming a maintainer, so that people who have coordinated a certain language since ages, can actually prevent somebody else from commiting. A maintainer can release a module and give it to someone s/he trusts. In effect, the new system allows to give some level of control to existing translation teams, rather than letting everyone commit freely (no, that wasn't a requested feature, I've added this feature myself, so I could ensure that existing coordinators, being assigned as maintainer, can still commit, even though someone else took the module). I'm sorry to hear that you don't think that's a step into the right direction. Well, maybe we didn't think the new additions through enough? If so, I personally apologise for the inconvenience this has caused, though I actually only implemented what was requested. And no, I don't have the URL, since I didn't actually read those requests myself, I merely took on what the maintainers of some of the mailing lists for the individual languages told me was a common request.

With the new Fedora
translation status pages, where anyone can contribute without ever
discussing anything with anyone else, the concept of teams aren't
mandated nor even encouraged.

Wasn't that also the case before the new status pages? Everyone could simply do a commit, without ever talking to anyone. Why are the arguments specifically against the new status pages? And really, if the majority of the community agrees with you, I have absolutely no objections of getting rid of them again.

Allowing anyone to contribute right away without discussing with anyone
may sound like a nice idea in theory, but it is usually in practice
totally orthogonal to the idea of producing coherent, good quality
translations. To have that, one must first cooperate. There's no magic
way around that. And to get that, you must first mandate or at least
encourage volunteering translators to join teams.

Agreed, with the exception of the mandate. But why should it be entirely up to "us"? Isn't it the responsibility of each individual within the community to encourage people to join teams? Why should "we" *make* people join certain teams? And while I agree with what you're saying, I still believe that an understandable translation is better than none, and you can start throwing stones at me now, if you wish. Ok, now, again, what exactly about the new status pages is it that causes all these problems? As said, I have no objections towards rolling them back and allowing everyone to commit again, at any given time.

Also, there's no way for someone else not fluent in the language to
decide whether particular translations are good or bad. Thus, you
usually have to ask the translators for that language as a group to have
that question answered. That means teams. So no matter how you design
your translation organization, you usually can't get around the concept
of teams, at least not if you care squat about quality assurance.

Completely agree. I believe teamwork is very essential, and I'd encourage anyone to join an existing team, if exists.

Thus the heated debate: The concept of community translations of Red Hat
Linux or Fedora Core is not new, so there are long-time contributors
that have already formed successful language translation teams for many
years, producing 100% complete translations for [insert divinity] knows
how many releases. Some of those teams are large, some teams are
smaller, but they are usually all quite experienced.
Enter today where these existing teams are suddenly completely nullified
by the Fedora translation status pages, which ignore them completely.

I'm sorry, but I don't see it? Why do the status pages nullify existing teams? If you chose to be a maintainer (and I've offered it to you), you're actually able to release someone from a module and get someone else to take it, or you can just take it yourself. Before, you had no way of doing that, and everyone could just freely commit, whether you wanted it or not. Please Christian, please explain to me why the new status pages nullify existing teams? I'd really like to know.

Then perhaps you can understand why people are annoyed, when they have
the successful teams they've built up and contributed with in the past
now being completely ignored.

Christian, I've offered you to be the maintainer for all swedish modules -- no reply. I'm happy to make Josep the maintainer for all modules for Catalan. I know he's asked, but then he said he'd want to wait till I tell him what he's messing with, so I told him. And I haven't heard anything since. Yes, it should be stated somewhere on the page, yes, we really should have team pages up, yes, this and that should be in place too, sorry if things aren't up as fast as you'd like them, we're really trying. Maybe starting with the status pages send the wrong message, if so, I apologise. And if you were hinting towards Youcef, I'm happy to discuss it with you off list, or on Youcef's request on list. But, if there are no objections from the other arabic translators, I have no objections either. One question though, why exactly did you get annoyed? Why exactly do you think it is all the fault of the new status pages? What is it about the new status pages that makes this system so infinitly worse than the one that was in place before? I'd really like to hear your take on it. Why is it, that it nullifies existing teams?

Granted, these existing Red Hat/Fedora community language translation
teams weren't really tracked before. They weren't really official; Red
Hat just tracked individual contributors and hoped that these should
organize themselves some way. Which is also what happened. Unofficial
language teams were formed out of registered community translators, and
were successful in producing Red Hat translations and later Fedora
So, would we be again at that point in time at the birth of the project,
I would agree with you that we would just need to wait and see
translation teams form.

But we're not.

But we aren't. For many languages, there is already organized and
successful teams that have already been dealing with this for many
years. Bypassing and ignoring the existance of them, be it accidentally
or intentionally, is like throwing the baby out with the bathwater.

I'm sure I sound like a broken record by now, but again, why do you think that the new status pages bypass and ignore the existance of already organized language teams? And for the case I haven't made myself clear enough in previous emails, the system is open for discussion. And as said before also, if the majority of the community supports your view, I don't even have any objections of rolling it back, and allowing unrestricted commit access again. I can't promise anything though, after all, it's not up to me alone to decide, but I'd definitely speak for whatever the majority of the community wants.

The main goal I see here is to provide traslation. Is the translation provided by certain people will be final and
for good? I doubt! To establish a translation first is the
first step. I belive yet to come a lot of tuning and enhancement.

Certainly. It's just that to have help and feedback from other translators they must know about your work and be able to review it, preferrably in good time. With the current system, some random person could commit a babelfish-quality translation without other translators fluent in the language (the "team") knowing about it or catching it in time.

Hmm, now you've lost me completely. :(
How is that different from how it was before? Everyone could do a commit. Now, on the other hand, if you are a maintainer, and somebody else does a commit, you'll even be notified by email. And you keep telling me it's all the new status pages? Sorry, but I just don't get it?! :(

I can't speak for Arabeyes, but there's nothing magic about most teams.
They're not a secret, closed band of elitist people. Usually they're
quite informal. All it takes to become a "member" of a language team is
often a discussion like this on a language team mailing list:

       A: Hi, I want to translate the X module into LL!
       B: Sure, go ahead. We will note in this LL team that you're
       doing the X translation. Please ask if you have any questions
       and also consider subscribing to our mailing list if you haven't
       already. Also, once you're finished, please send your
       translation to the mailing list so others can try to review it
       and give helpful comments.
       A: Gee, thanks, will do.

If the situation was that all teams were closed gangs of self-selected
arrogant people that perhaps rejected new volunteers or demanded them to
work on stuff they didn't like to, then I would understand your point
that there should perhaps be a way for volunteers to decide not to be
part of a team to participate.

This almost always isn't the situation though. The teams are usually as
informal as could possibly be. They're there so that volunteer
translators for that language know each other and who's working on what
in the project, and can help eachother and review each other's work, and
as a consequence in the end as a team produce coherent translations for
that language.

And you won't see me disagree with you, not in the least. It is true though, that sometimes, it's really hard to find a maintainer. ;) That however, I wouldn't in the least hold against teams. I believe having teams is a good thing.

Thus, I don't understand at all what the benefit would be of deciding
not to join a team, or why the system should encourage that or even have
that as an option. If there's a particular team that isn't as open or
helpful as could be to new volunteers, then it's a problem with that
particular language team, not the concept of language teams per se.

In general, of course I agree with you, that doesn't mean there couldn't be exceptions though. And I believe we can leave it at that. I'm happy to discuss it though.

If you ask for my opinion, something like the model used in almost all
other translation projects is the way to go. See my "The GNOME model"
mail which explains how such translation projects often work.

Perhaps not every little detail should be copied, since even those
systems have their problems in details, but an organization
fundamentally built on teams is a must, and also that the system
encourages or mandates that volunteers join the teams first before
committing translations. If you don't have that, you scrap all the
benefits of having the teams in the first place.

Also, each team having a coordinator is often a must. Perhaps you can
live without a team coordinator if the team is only two people, but if
the teams grow larger you often need it. Then you can have someone that
has the final say, should there be an issue in the team where there
needs to be someone that has the final say.
Usually this is not the case, but should there be such a situation the
team will often be able to resolve the issues themselves if there has
been a coordinator assigned in the team. Otherwise the translation
project maintainer may need to step in and decide on an issue he or she
couldn't possibly make a qualified decision on, because it involves
knowledge of the particular language.
And if the team is unhappy with the team coordinator, the coordinator
can always be replaced.
Also, occasionally you will want to get in contact with a team, and if
you have assigned a coordinator, you have an excellent contact person

I hope this mail was helpful, even if it was long. Translation itself isn't rocket science, but it often scales into a very large project with many volunteers quite rapidly. And dealing with how to best organize those large amounts of volunteers so that they can cooperate in the best way possible and produce coherent translations is a nontrivial task, from which lessons have been learned in the past in other free software translation projects. We should learn from those lessons.

Christian, all these point are very well taken, believe me. I see a lot of problems with our current system, especially since we don't have everything in place that we'd like to have in place. We'd like to see language-specific mailing lists and team pages for all teams too, we just haven't gotten around to it yet. It would be nice to have it all centralized in one place, and that's the main aim, but for now, individual groups just have to have their own pages. Geez, in the beginning we even pointed to a non-fedora site for status information. So we've started with putting up a status page. Since the problem of concurrent commits and therefore conflicts in large and active groups was a main issue, we've decided on adding a mechanism to prevent people from comitting at the same time, which was implemented next, as part of the status pages, so it would also function as an overview for others on who exactly is doing what. That's what we did. And suddenly, by simply implementing this next step, we're getting all this critique about the new status pages nullifying existing translations teams? I truly thought it was a step into the right direction, and that's what everyone else here thought too. Maybe it wasn't? However, I let the community decide -- in its entirety.

Best Regards,


Fedora-trans-list mailing list
Fedora-trans-list at redhat dot 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/