>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
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
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
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
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
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
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
I can't speak for Arabeyes, but there's nothing magic about
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
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
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
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.
Fedora-trans-list mailing 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