Settings for the scilab localization in LaunchPad Translations

[Yuri Chornoivan]

написане Mon, 09 May 2011 17:13:32 +0300, Kenneth Nielsen [via Scilab /  
Xcos - Mailing Lists Archives]  
<ml-node+2918845-1484456191-394903 at n3.nabble.com>:

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

Do you seriously think that this 3 minutes work will be reviewed in a  
reasonable time and this review can lead to some well-defined conclusions?  
What if the review will come in a month or two? What if it will never come  
at all?

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

Before your input there was no such idea at all.

And I do not think that it will lead to less bureaucracy. You just replace  
Launchpad Translations Coordinators by yourself. And it's not the fact  
that waiting for your or mine approval for a month or two is better than  
waiting for LTC approval for a month or two [1].

It was not very kind to ban more than half of Scilab translators just to  
give lp-translators another dozen of groups in a few months.

[1] https://answers.launchpad.net/launchpad/+question/153416

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

Maybe. I was just an example. In a small teams probability of such cases  
is almost equal to 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?
>
> 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
>

That is very interesting point. Can you guide me to the page with *tools*  
of lp-translators. I have always preferred offline TM and strict glossary  
with pology [2] checks and did not know about specific LP tools.

If no-one can guarantee anything and there is no mailing list where you  
can claim the change of group leader I think that LP-groups are very  
dangerous regarding to the quality and standards.

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

I meant that trying to make interface uncluttered and simplistic,  
developers removed (or did not implement) filtering translations by  
translators, like in Transifex. It leads to the two-level workflow with  
suggestions. Moreover, LP does not remove wrong suggestions from TM and  
make things even worse.

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

KDE and GNOME have the rules to handle these problems (see the cited  
case). If your statement about the number of translators is right why the  
recommended LP-translators way is trying to make the new translator's life  
difficult?

Personally, I am very happy that these "recommendations" are implemented  
just for a few projects only (Chromium, SuperTuxKart). I must thank the  
developers of JMol, Stellarium, Avogadro, OpenShot, Deja Dup and many  
others for not changing to "Restricted". If they have changed the policy  
as it was "recommended" there are no Ukrainian translation for these tools  
at all.

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

LP just do not show them the glossary like it is implemented for offline  
tools (Lokalize, Virtaal). Moreother, at least for my language  
Ubuntu-translators recommendations are inconsistent with Microsoft, GNOME  
and KDE guidelines, as well as current Ukrainian orthography rules.  
Recommendations for Georgian are wrong for replacers (%(something)s),  
recommendations for Russian contain visible typos, etc. And  
Ubuntu-translators team is a core of the most LP-translators teams. Who  
are the judges? Can they be judged? ;)

Bad grammar, spelling mistakes, and failure to implement a common  
vocabulary across applications? In Scilab? Are you sure that a grammar  
knowledge, not a knowledge of mathematics is a best friend here?

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


--
View this message in context: http://mailinglists.scilab.org/Settings-for-the-scilab-localization-in-LaunchPad-Translations-tp2870916p2919195.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/20110509/025d304f/attachment.htm>