[Scilab-loc] Re: Settings for the scilab localization in LaunchPad Translations

[Kenneth Nielsen]

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

No. I just require them to do a little more work than can be
accomplished in 3 minutes with a hit-and-run translations
contribution.

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

The process of starting a team under lp translators is done only once
and can be used for many projects, so on an overall scale this will
amount to less bureaucracy than having a group per project, which is
what I was comparing to.

> What if you lose the interest (you have already said that Octave is
> completer [1])?

That is perhaps a somewhat selective interpretation of what I said.

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

No-one, for the last and final time. These measures do not guarantee
translations quality, but the fo provide the tools necessary to make
it happen

> 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

See above

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

I'm not 100% sure I understand what you mean. The way we implement QA
in launchpad is the recommended way to do it, if you want to, it is
not a workaround.

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

So what if people run into problems. Making good stuff is difficult,
nothing to do about that. Free software projects are always
understaffed. In my view, what you are doing is to adopt an inferior
work flow, merely because you have concluded that we don't have the
resources to implement a proper one. That is not something I would do.

> [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.

Judge? About bad grammar, spelling mistakes and failure to implement a
common vocabulary across applications? Guilty as charged! And I
certainly hope that someone will "judge" me too. In fact they do, and
I rely on them to do so, because I also make mistakes when I
translate. Don't be mistaken about that. When I talk about just how
many bad translations and errors we catch with proofreading, I know
that both from doing the proofreading and from having my own stuff
proofread. The difference is that I actually care enough about people
learning something along the way, to not just correct their stuff
without including them in the process. Something that is not always
possible with open permissions.

In any case, I don't think you and I are going to see eye to eye on
this thing. So why don't you guys, the existing community around
Scilab translations, decide what, if any, change you want to make, and
then I'll check in later* to see if I can contribute to the project or
not.

\Kenneth

* I'll be insanely busy until the end of August anyway, so I probably
wont make much progress on the translation in the mean time. I just
wanted get the discussion going.