Fedora and Translation Teams

[Bernd Groh]

Christian,

>>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
>translations.
>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
>aswell.
>
>
>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,
Bernd

>Christian
>
>
>--
>Fedora-trans-list mailing list
>Fedora-trans-list at redhat.com
>http://www.redhat.com/mailman/listinfo/fedora-trans-list
>  
>


-- 
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/