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

Re: Arabeyes Translation Teams

Thank you Nadim for putting light into many issues. Please keep at it,
as much as we >would like things to work, we also wouldn't like to go
along a path that has been proven to be unreliable.


This is not simply a problem in translation - this is a problem with
almost everything we touch.  We have plenty of ideas yet time is
critical for most of us and there simply aren't enough helping or
interested hands.  With that said, I'm not citing an excuse, simply
pointing that this problem exists across all disciplines even beyond
open source efforts.  The reason I'm opting to stop and point out the
obvious will become apparent in a bit but in short the solution is
not entirely specific to the problem.


It's a problem in HR. Translation is one obvious aspect from it.


Here is a old idea that is worth repeating.  Why not have everyone that
is interested in translation (that is willing to work on something other
than their main project) work on ONE project until it is complete ?  In
other words, inform everyone that for the month of August ALL are kindly
asked to only contribute and translate the Gnome project, September
will get assigned to KDE, etc, etc.  There seems to be merit in such an
idea yet I'll leave it to those that do the actual work to decide.  With
the small'ish number of people that are doing the actual work this might
actually get a number of things accomplished sooner rather than later and
it will ultimately be more fun as there is more interaction and like-thought.


That will only be yet another temporary solution. In the long run,
many project may end up being pulled away from under Arabeyes control,
as their "turn" will never come in. Keeping projects under the
maintenance of Arabeye is necessary, it serves to not fragment the
translation effort even more.

On top of that, as with most OSS projects, a user is most likely to
contribute to a project if they actually use it and love using it.
Understandably, It would be a bit wrong to force an avid KDE user to
translate Gnome. First, he won't be that interested. Second, he won't
be using it to see his work. The net result might be a backslash.


> Please take this seriously, we took it upon ourselves to be The
> Ones(tm) when it came to Arabic translation, so we should live up to


Yes and no.  What you see in terms of "complexity" or high barrier
for entry was the result of about 3-4 years of people like you doing
this work and trying to document it as best as they can.  In other words,
people wanted to streamline the process so that they don't continue to
get bombarded with questions, howtos, what-to-do's, etc.


As I said, I don't see what is so wrong about this. What's so bad
about taking a couple of minutes to answer an email containing some
question? If we overcome the irritation and the sudden urge to smite
the asker, it wouldn't be bad after all.

Keep in mind that the mere existence of manuals is not at all a bad
idea, that's not my point, it's requiring potential users to read them
all upfront that is the problem. Humans are impatient, we would be
better off letting them start contributing a bit, to keep them rolling
and direct them as they inevitably ask questions.

Initially the 
idea was for ONE project coordinator to be responsible for a project.
So say person-X comes around and he's interested in KDE.  He's really
really really interested and so he actually spends the time needed to
learn about CVS, etc and applies to be the project's maintainer.  That
person-X would then apply to be KDE's maintainer/coordinator and if
all pans out, he gets the assignment.  With that the role of 'Arabeyes'
proper ends in that person-X is now fully responsible for KDE (that
would include the files, the news, the sub-project page, blurbs, informing
people of tasks and schedules, keeping people motivated, recruiting, etc).
If this person-X after 2 months comes back and says "hey person-Z is
really good and he's helping, please give him an account" the 'core'
team would gladly do that.


That so makes sense and I'm so glad that at least, this is the
somewhat official policy of managing translation teams. Enacting this
policy and making it clear it to maintainers what their tasks are
should be in order.


So why am I saying all of this ?  Well, that is because that is what
we started with.  Arabeyes' initial idea was just that (with relation
to translation).  As the projects grew and as people came-and-went
we started adapting to what is easier to maintain and how best to make
this more of a "process".  So it ultimately became easier to simply
give out CVS accounts to those that knew (or were OK'ed by someone
trusted to know) what they were doing.


As long as it is not required to get a CVS account to contribute then
that's fine.  I'm simply  strongly suggesting not bombarding new users
with requirements/manuals as they want to help.



Project maintainers/coordinators really need to step-forward and take-on
more of the burden to really __lead__ the project they are responsible
for since the more I think about our current state the more I'm inclined
to suggest the initial approach.


Makes perfect sense, excellent point on maintainers needing to be
*Leaders*. As to how to *teach* them, or how to make/encourage them to
do that, I have no idea.




I don't think there is _any_ 'arrogance', I really don't.  But I can
guarantee you no matter what you'll do you won't get the level of
participation you'll expect.  The reason for this is simple (and I
don't mean anything negative by this but it is what veteran translators
have noted themselves) the job is boring and is never-ending.  Simply
put, no matter what you'll do you won't be able to retain a motivated
results-oriented team unless other carrots were introduced (money,
pride in ethnicity, competition versus something/someone else, etc)
and even that is not entirely sustainable.


I firmly believe in the possibility to have a bounties system, or even
a part-time or full-time employees given sources of income, Gov
sponsors and things like Google Summer of Code are not a bad idea.

If you come to think of it, big steps in the recent development of big
distribution were not possible without the help of sponsors.


Linux (and open source) in western markets even is still a niche, so
I don't expect too much from the Arab computer user.


I beg to differ.
First, Linux in the server markets is not a niche player at all. In
many other segments of the market, it's rather a major player. The
higher education sector to start with.

And as you may already know, Linux's biggest roadblock to widespread
adoption is the potential costly switch price. That is not the case in
most Arab countries: The IT market is still mostly fresh, many
organisations are not fully IT operated, and best of all, they have
not yet realised the full cost of proprietary solutions. On top of
that, there is also the political/economical issue of off shoring
money vs keeping it locally circulated with local Arabic Linux
supporting organisations/companies. Linux can make big slides if we
know how to play our cards well.

While that might have seemed as some wishful thinking, if you come to
think of it it is not far from reality at all.


So to overly simply the entire process, a newbie sends an email
(in private if you will) to the project's maintainer to say "I want
to help" and the project maintainer sends him/her files to translate
while tracking progress and ownership.


Fair solution. May be the maintainers should contact people who signs
with suggestions directly?

Snip.... but testing every
method out there is a bit cumbersome to say the least for the limited
people that are currently active.  If a tool becomes available that
everyone would like to seriously use (not just test and play around
with to see how we can modify it to suit our needs) then by all means
we'll try our best to get it up-n-running.


IF you're referring to translation tools, they have been used
extensively and successfully by many projects. Check launchpad.net for
an example, and browser their list to get a grasp of the model they
adopted.


I too, like the others, agree but I think a different tack needs to be
taken.  My remark regarding "solution is not entirely specific to the
problem" steams from the fact I see this problem very related to what
is happening on alots of fronts beyond arabeyes - the mindset simply
needs to start changing and its not a question of mechanisms or tools
(I think its inherit within people - but I might be getting philosophical).
In other words, I don't think you'll get much accomplished/improved if
you were to remove all these "filters" (though as noted they potentially
aren't there given the coordinator shields them away); so prove me wrong :-)
In short, what you are asking for is semi-there.  You want a simplified
means to have newbies contribute and my response to that is "it is
already there" - you are welcome to do or try what you think will work.



I was mainly demonstrating the problem of human resources. It's a
problem, an engineering mind would seek solutions for any problem out
there, by any means necessary. If dropping the barriers of entry won't
work, one has to work harder for another solution.

Still, the overall directions and work approaches need to be advised
by senior members like yourself, as experience is really important.

Djihed