Settings for the scilab localization in LaunchPad Translations

Yuri Chornoivan yurchor at ukr.net
Fri May 6 16:12:54 CEST 2011


написане Fri, 06 May 2011 14:42:37 +0300, Kenneth Nielsen [via Scilab /  
Xcos - Mailing Lists Archives]  
<ml-node+2907766-912096632-394903 at n3.nabble.com>:

>
>
> 2011/5/6 Yuri Chornoivan <yurchor at ukr.net>:
>>> 2011/5/5 Ihor Rokach <[hidden email]>:
>>>  > Yuri,
>>>  >
>>>  > I agree with you totally. Most of the Open Source translation  
>>> projects
>>>  > were, are and will be the one-man ones.
>>>
>>>  Joining a team in a gathering group like Launchpad translators, will
>>>  (if you get the team of the ground) allow you to get help with the
>>>  proofreading, turning it into an at least 2 man job. I have
>>>  contributed to jmol, rednotebook, Ubuntu Pay and others in this way me
>>>  translating and someone else proofreading or the other way around and
>>>  it works just fine.
>> I am KDE and Fedora coordinator and Opera Software official volunteer
>> translator. For sure, I cannot understand what prevents you from doing  
>> this
>> now. Just call your reviewers and they correct the mistakes.
>>
>> Do you want to ban some "bad" guys that ruined your translations? That  
>> is
>> easy, file a question on LP. ;)
>
> Not a bad guy, but simply one that isn't as good at grammar and yes I
> want to do that and no it isn't easy. To ensure that the translations
> I did had proofread etc. and were thorough with, keeps being that way,
> then I will have to continuously scan all my old translations for bad
> contributions, then correct them back, maybe try and contact the bad
> contributor by email to make sure that he wont keep making the same
> bad suggestions and if he wont respond what? Eventually file a
> questions in LP and ask to have him banned from translation? That's
> easy?

Thus, you, who do not love bureaucracy decided to ban any possible  
contributor a priori? As you know if there is no lp-translators team with  
"Restricted" permissions it is not even possible to make even suggestions.  
Are you sure that potential contributor love bureaucracy more than you?

What if you lose the interest (you have already said that Octave is  
completer [1])? Who can stand all this bureaucracy if your team of 5  
members become stale? Who will prove that you and your reviewer are "good  
guys", not the first people who have registered the group first?

Suppose that our fictitious brave new translator decided to "revive" the  
group. Who can guarantee that he or she obtain the answer before giving up  
and going to translate something else? For example, my question [2] is  
still unanswered, though I asked Canonical personnel to support it [3].

[1] http://logs.ubuntu-eu.org/free/2011/04/26/%23ubuntu-translators.html
[2] https://answers.launchpad.net/launchpad/+question/155900
[3] http://logs.ubuntu-eu.org/free/2011/05/04/%23ubuntu-translators.html

>
>>>  > Idea of creation of so called
>>>  > 'translation groups'  maybe could be useful for some projects,
>>>  > however, is totally senseless in the Scilab case. Actually it adds
>>>  > nothing to the quality of translation of Scilab or even decrease it
>>>  > because it kills effort of causal translators which help us by
>>>  > correction of one or two strings only.
>>>
>>>  You can't do proper QA by a casual effort.
>>
>> Why? I believe that not all of us are professionals in translation. Why
>> casual reviewer (we are all casual reviewers) cannot fix casual  
>> translator
>> (do not tell me that you will leave forever and translate Scilab to the  
>> end
>> of times)?
>
> I did not mean casual as supposed to professional. I was referring to
> the case described _just_ above, about someone casually dropping by
> and fixing a couple of errors in the translations.
>

It is the bug in Launchpad/Rosetta itself. If developers cannot implement  
this (the bug is well-known) why you are sure that we should use  
workarounds?

>>>  > These people need to have easy
>>>  > and simple access to the translation interface, otherwise they  
>>> simply
>>>  > will not participate in the translation process.
>>>
>>>  Making translations something that you can contribute to with this
>>>  kind of hit-and-run contributions is a huge mistake. I don't know who
>>>  ever came up with that idea but it is horrible. Translations, just
>>>  like programming or documentations writing, requires a little more
>>>  effort that that to do it right. That was the way the Launchpad
>>>  started out and they have now realized that effect that has on quality
>>>  and therefore now, still allow it, but recommends restrictions after
>>>  the upstart phase
>>>
>> Well, who can judge who are right 3 Ubuntu translators or 3 KDE  
>> translators?
>>
>> There are no conflicts between Scilab translators. We were working  
>> together
>> to make the translations better. But then someone find that we should  
>> not
>> give the opportunity to the new translators and reviewers and it appears
>> that there are groups of translators (lp-translators) that know things
>> better but did not translate Scilab because of the wrong rules
>
>
> All I can tell you is that a decision has been made to restrict access
> to translations to pretty much all major free software projects (a lot
> more that 3 translators). And yes, giving people the options to
> implement QA properly in the translations did play a role in those
> decisions.

I try and remove such restrictions from any project I am taking part (KDE,  
GNOME, TP, Fedora). People should not suffer from the bad management of  
their teams or bottlenecks in translator-editor-commiter chain.

After all, as I can see all such restrictions leads to one end. See Slovak  
translation case in GNOME [4]. QA arguments do not help.

[4] http://mail.gnome.org/archives/gnome-i18n/2010-May/msg00023.html

>
>>>  > I know examples of the projects with completely restrict-less access
>>>  > to the translation interface which are extremely successful. See for
>>>  > example SMath Studio (freeware Mathcad clone) translation interface  
>>> at
>>>  >
>>>  > http://smath.info/translator/
>>>
>>>  Success in terms of what? Quantity I'll believe, quality, not likely.
>>
>> Can you give an example of the faulty translation?
>
> I see bad suggestions all the time. Luckily the are in translations
> the are restricted so they did not just get implemented directly. You
> want me to find you a couple of suggestions and explain to you why
> they are bad Danish translations?
>
> Regards Kenneth

It was said

“Do not judge, or you too will be judged. For in the same way you judge  
others, you will be judged, and with the measure you use, it will be  
measured to you.

I only want to second this.

Best regards,
Yuri


--
View this message in context: http://mailinglists.scilab.org/Settings-for-the-scilab-localization-in-LaunchPad-Translations-tp2870916p2908319.html
Sent from the Scilab localization - Mailing Lists Archives mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/localization/attachments/20110506/874afd55/attachment.htm>


More information about the localization mailing list