Josep Puigdemont schrieb:
On Wed, 2004-06-23 at 02:19, Bernd Groh wrote:
>Josep Puigdemont schrieb:
>
>
>>On Tue, 2004-06-22 at 11:38, Bernd Groh wrote:
>>
>>
>>>If you have only 2 translators, then it may not be a problem, it gets
>>>more difficult with 10. And if you have 20+ translators to a language,
>>>peer-to-peer communication has proven not to be ideal. In this way,
>>>
>>>
>>>
>>I think we should have been consulted about this change before it was
>>applied, no? Maybe you did and I missed it, sorry! After all, the
>>translation project is a true community effort, and we might have
>>something to say about what's best for us too...
>>
>>
>>
>I did this on request from a lot of people within the community, and I
>believed their reasoning to be very valid.
>
>
>
I completely missed that, and wasn't aware of the fact that this was a
community request, and being this the functionality the community
wanted, it seems very logical that it was implemented.
Anyway, I still disagree in not having translation teams instead, and I
would be a bad member of the community if I didn't at least mention it
(even if it is only for myself who I'm speaking for).
Nobody keeps anyone from having translations teams, I think it is a good
idea, but not one we'll be enforcing. This is something that has to
evolve out of the community itself.
I appreciate the advantages of this new method:
* it's a community request
* translation work accessible to everybody
* avoids duplicated work
* Anyone can see who's doing what in a very organized way
* I think I miss a few more here...
It would also be interesting to see which points you (plural) think are
not so good, or could be improved.
Agree. I'd be happy to receive any feedback, as long as it appears
constructive, and I believe your comments are.
For me, the problem I see is that it doesn't encourage team
work. In
any translation project it is very important that all translators get in
contact, that way we make sure we all use the same terminology, the same
style, etc, and thus we guarantee a certain level of quality and
consistency. Quality gets better with time.
I agree to some extent, in some cases, it is hard to manage though. Not
talking about everyone agreeing on the same terminology. For some
languages, that can indeed be extremely difficult, if it is possible at all.
In my particular case I can enjoy the experience of a group that
has
been working with the translation of open source software for more than
7 years. This work includes a great compendium of words and neologisms,
a style guide, and a translation memory with more than 62,000 entries.
Anyone with sufficient knowledge can do a translation, but although
those 7 years of work are accessible to anyone, nobody forces a new
translator to use them.
On the other hand, if a new translator had to join a team, s/he would
have to use the same style and terminology as the rest of the team,
which I find _very_ important. For example, the word "File" can be
translated into my language as "Fitxer" or "Arxiu". In order to keep
consistency we had to decide which one to use and stay with it always,
and _that's_ what a translation team can guarantee, and _that_ improves
quality and consistency among translations. That's just one example, but
there are many, specially those related to "new" terms like "buffer"
or
"cache", for which many people use the English term when there already
is a translation.
Believe me, this point is very well taken, but at the same time, you can
watch who is translating what, and if you recognize a new translator,
invite her/him to your team. Why does it always have to be the new
translator who gets in contact with the group? I personally believe in
making it as easy for people to get started as possible. Wouldn't it be
easier for the group to send an invite?
>>What if it never gets finished? Or never released, or someone
else can
>>translate it faster, or if it contains errors? Or if it does't use the
>>same terminology/style as other translations?
>>
>>
>>
>If it doesn't get finished in time, we'll release it. If somone else can
>translate it faster, so what? And I don't think all the other problems
>are to be associated with the new system, you have the same problems
>without it.
>
>
>
True, you're right, but, as explained above, the "other problems" are
not present if translation teams are used.
But these aren't associated with the new system, since it is even more
restrictive than the previous one.
I still think that it would be good to force translators to work and
join translation teams.
I believe it would be good to encourage them, I disagree with forcing them.
>Why? Why does the new system keep you from communicating with
other
>translators in your language?
>
>
>
It doesn't, but the fact that it doesn't, doesn't mean that it makes me
communicate with other translators, which, for the reasons explained
above, I believe should be enforced.
I don't think it should. I believe it makes it harder for new
translators to get started. Nobody keeps you from encouraging new
translators to join your team.
>>On the other hand it restricts the assignment of modules to
people using
>>CVS. Just as an example, in our team we have some very good translators
>>that use Windows, and have no idea about CVS or SSH keys, but are very
>>valuable to us.
>>
>>
>>
>Who is commiting their files?
>
>
I was, and I suppose you'll say that I can take the file for them and
continue committing their files. True, it is just that I don't want to
figure as a translator of something someone else is translating, I would
feel like steeling their credit.
Why won't you be the maintainer then? ;) And being a current translator
is not about credit, it's so that people know who is currently
translating the file, or who intends a commit, so that other people know
what to and what not to translate.
>>IMHO, I think a better approach is that of the gnome
translation
>>project, having a coordinator for a language and making him/her commit
>>the changes, but I believe Christian Rose has more to say if this is the
>>case than I do.
>>
>>
>>
>The new system has the option of a maintainer. I can simply set the
>coordinator the maintainer of all modules of a certain language, and
>this maintainer then has full access to the cvs for that language. In
>how is that different to what gnome is doing? Nobody keeps only one
>
>
That's what I could find:
http://developer.gnome.org/projects/gtp/join.html
GNOME makes you be part of a team, you don't get CVS access unless
someone vouches for you (iirc) or you have done previous work that
proves you should have access (or deserve to).
Yes, that's why I never got any cvs access. The first maintainer I send
an email to wasn't the maintainer anymore since ages, and the second one
never replied. That's a really good system! I understand that
maintainers of modules are busy with other things, this is voluntary
after all, but that's exactly why I prefer a system in which you can
just get started (ignoring the problems we had with account activation
now and then :)), and if a maintainer has time, s/he can look at who was
doing what and then either invite a person to become part of a group, or
what ever s/he may chose. I prefer to assume that everyone deserves to
participate, and then restrict or disable someones access if the
opposite becomes apparent.
>person from commiting. We simply disallow two non-maintainers from
>commiting at the same time.
>
>
I believe it can be done with teams too.
And I don't disagree.
That's just my opinion and I can be wrong too. So far no one has
backed
me up, and the community has already spoken, but I had to tell to have
the satisfaction of having done [at least for once] my duty :)
And so you should! And I'm not doing anything else than stating my
opinion either. :)
Best Regards,
Bernd
Keep up the good work!
Best regards,
Josep
--
Fedora-trans-list mailing list
Fedora-trans-list(a)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/