написане Mon, 09 May 2011 17:13:32 +0300, Kenneth Nielsen [via Scilab /  

<br/>Xcos - Mailing Lists Archives]  

<br/><<a href="/user/SendEmail.jtp?type=node&node=2919195&i=0&by-user=t" target="_top" rel="nofollow" link="external">[hidden email]</a>>:

<br/><div class='shrinkable-quote'><br/>>

<br/>>

<br/>>>> Not a bad guy, but simply one that isn't as good at grammar and yes I

<br/>>>> want to do that and no it isn't easy. To ensure that the translations

<br/>>>> I did had proofread etc. and were thorough with, keeps being that way,

<br/>>>> then I will have to continuously scan all my old translations for bad

<br/>>>> contributions, then correct them back, maybe try and contact the bad

<br/>>>> contributor by email to make sure that he wont keep making the same

<br/>>>> bad suggestions and if he wont respond what? Eventually file a

<br/>>>> questions in LP and ask to have him banned from translation? That's

<br/>>>> easy?

<br/>>> Thus, you, who do not love bureaucracy decided to ban any possible

>> contributor a priori?

<br/>>

<br/>> No. I just require them to do a little more work than can be

<br/>> accomplished in 3 minutes with a hit-and-run translations

<br/>> contribution.

<br/>>

</div><br/>Do you seriously think that this 3 minutes work will be reviewed in a  

<br/>reasonable time and this review can lead to some well-defined conclusions?  

<br/>What if the review will come in a month or two? What if it will never come  

at all?

<br/><div class='shrinkable-quote'><br/>>> As you know if there is no lp-translators team with

<br/>>> "Restricted" permissions it is not even possible to make even  

<br/>>> suggestions.

>> Are you sure that potential contributor love bureaucracy more than you?

<br/>>

<br/>> The process of starting a team under lp translators is done only once

<br/>> and can be used for many projects, so on an overall scale this will

<br/>> amount to less bureaucracy than having a group per project, which is

> what I was comparing to.

<br/>>

</div> Before your input there was no such idea at all.

<br/><br/>And I do not think that it will lead to less bureaucracy. You just replace  

<br/>Launchpad Translations Coordinators by yourself. And it's not the fact  

<br/>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].

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

<br/><br/>[1] <a href="https://answers.launchpad.net/launchpad/+question/153416" target="_top" rel="nofollow" link="external">https://answers.launchpad.net/launchpad/+question/153416</a><br/><br/>>> What if you lose the interest (you have already said that Octave is

<br/>>> completer [1])?

<br/>>

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

<br/>>

<br/><br/>Maybe. I was just an example. In a small teams probability of such cases  

is almost equal to 1.

<br/><br/>>> Who can stand all this bureaucracy if your team of 5

<br/>>> members become stale? Who will prove that you and your reviewer are  

<br/>>> "good

>> guys", not the first people who have registered the group first?

<br/>>

<br/>> No-one, for the last and final time. These measures do not guarantee

<br/>> translations quality, but the fo provide the tools necessary to make

<br/>> it happen

<br/>>

<br/><br/>That is very interesting point. Can you guide me to the page with *tools*  

<br/>of lp-translators. I have always preferred offline TM and strict glossary  

with pology [2] checks and did not know about specific LP tools.

<br/><br/>If no-one can guarantee anything and there is no mailing list where you  

<br/>can claim the change of group leader I think that LP-groups are very  

dangerous regarding to the quality and standards.

<br/><div class='shrinkable-quote'><br/>>> Suppose that our fictitious brave new translator decided to "revive" the

<br/>>> group. Who can guarantee that he or she obtain the answer before giving  

<br/>>> up

<br/>>> and going to translate something else? For example, my question [2] is

>> still unanswered, though I asked Canonical personnel to support it [3].

<br/>>>

<br/>>> [1] <a href="http://logs.ubuntu-eu.org/free/2011/04/26/%23ubuntu-translators.html" target="_top" rel="nofollow" link="external">http://logs.ubuntu-eu.org/free/2011/04/26/%23ubuntu-translators.html</a><br/>>> [2] <a href="https://answers.launchpad.net/launchpad/+question/155900" target="_top" rel="nofollow" link="external">https://answers.launchpad.net/launchpad/+question/155900</a><br/>>> [3] <a href="http://logs.ubuntu-eu.org/free/2011/05/04/%23ubuntu-translators.html" target="_top" rel="nofollow" link="external">http://logs.ubuntu-eu.org/free/2011/05/04/%23ubuntu-translators.html</a><br/>>

<br/>> See above

<br/>>

<br/>>>>>>  > Idea of creation of so called

<br/>>>>>>  > 'translation groups'  maybe could be useful for some projects,

<br/>>>>>>  > however, is totally senseless in the Scilab case. Actually it adds

<br/>>>>>>  > nothing to the quality of translation of Scilab or even decrease  

<br/>>>>>> it

<br/>>>>>>  > because it kills effort of causal translators which help us by

>>>>>  > correction of one or two strings only.

<br/>>>>>>

>>>>>  You can't do proper QA by a casual effort.

<br/>>>>>

<br/>>>>> Why? I believe that not all of us are professionals in translation.  

<br/>>>>> Why

<br/>>>>> casual reviewer (we are all casual reviewers) cannot fix casual

<br/>>>>> translator

<br/>>>>> (do not tell me that you will leave forever and translate Scilab to  

<br/>>>>> the

<br/>>>>> end

<br/>>>>> of times)?

<br/>>>>

<br/>>>> I did not mean casual as supposed to professional. I was referring to

<br/>>>> the case described _just_ above, about someone casually dropping by

>>> and fixing a couple of errors in the translations.

<br/>>>>

<br/>>> It is the bug in Launchpad/Rosetta itself. If developers cannot  

<br/>>> implement

<br/>>> this (the bug is well-known) why you are sure that we should use

<br/>>> workarounds?

<br/>>

<br/>> I'm not 100% sure I understand what you mean. The way we implement QA

<br/>> in launchpad is the recommended way to do it, if you want to, it is

> not a workaround.

<br/>>

</div><br/>I meant that trying to make interface uncluttered and simplistic,  

<br/>developers removed (or did not implement) filtering translations by  

<br/>translators, like in Transifex. It leads to the two-level workflow with  

<br/>suggestions. Moreover, LP does not remove wrong suggestions from TM and  

make things even worse.

<br/><div class='shrinkable-quote'><br/>>>>>>  > These people need to have easy

<br/>>>>>>  > and simple access to the translation interface, otherwise they

<br/>>>>>> simply

>>>>>  > will not participate in the translation process.

<br/>>>>>>

<br/>>>>>>  Making translations something that you can contribute to with this

<br/>>>>>>  kind of hit-and-run contributions is a huge mistake. I don't know  

<br/>>>>>> who

<br/>>>>>>  ever came up with that idea but it is horrible. Translations, just

<br/>>>>>>  like programming or documentations writing, requires a little more

<br/>>>>>>  effort that that to do it right. That was the way the Launchpad

<br/>>>>>>  started out and they have now realized that effect that has on  

<br/>>>>>> quality

<br/>>>>>>  and therefore now, still allow it, but recommends restrictions after

<br/>>>>>>  the upstart phase

<br/>>>>>>

<br/>>>>> Well, who can judge who are right 3 Ubuntu translators or 3 KDE

<br/>>>>> translators?

<br/>>>>>

<br/>>>>> There are no conflicts between Scilab translators. We were working

<br/>>>>> together

<br/>>>>> to make the translations better. But then someone find that we should

<br/>>>>> not

<br/>>>>> give the opportunity to the new translators and reviewers and it  

<br/>>>>> appears

<br/>>>>> that there are groups of translators (lp-translators) that know things

<br/>>>>> better but did not translate Scilab because of the wrong rules

<br/>>>>

<br/>>>>

<br/>>>> All I can tell you is that a decision has been made to restrict access

<br/>>>> to translations to pretty much all major free software projects (a lot

<br/>>>> more that 3 translators). And yes, giving people the options to

<br/>>>> implement QA properly in the translations did play a role in those

<br/>>>> decisions.

<br/>>> I try and remove such restrictions from any project I am taking part  

<br/>>> (KDE,

<br/>>> GNOME, TP, Fedora). People should not suffer from the bad management of

>> their teams or bottlenecks in translator-editor-commiter chain.

<br/>>>

<br/>>> After all, as I can see all such restrictions leads to one end. See  

<br/>>> Slovak

>> translation case in GNOME [4]. QA arguments do not help.

<br/>>

<br/>> So what if people run into problems. Making good stuff is difficult,

<br/>> nothing to do about that. Free software projects are always

<br/>> understaffed. In my view, what you are doing is to adopt an inferior

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

<br/>>

</div><br/>KDE and GNOME have the rules to handle these problems (see the cited  

<br/>case). If your statement about the number of translators is right why the  

<br/>recommended LP-translators way is trying to make the new translator's life  

difficult?

<br/><br/>Personally, I am very happy that these "recommendations" are implemented  

<br/>just for a few projects only (Chromium, SuperTuxKart). I must thank the  

<br/>developers of JMol, Stellarium, Avogadro, OpenShot, Deja Dup and many  

<br/>others for not changing to "Restricted". If they have changed the policy  

<br/>as it was "recommended" there are no Ukrainian translation for these tools  

at all.

<br/><div class='shrinkable-quote'><br/>>> [4] <a href="http://mail.gnome.org/archives/gnome-i18n/2010-May/msg00023.html" target="_top" rel="nofollow" link="external">http://mail.gnome.org/archives/gnome-i18n/2010-May/msg00023.html</a><br/>>>

<br/>>>>

<br/>>>>>>  > I know examples of the projects with completely restrict-less  

<br/>>>>>> access

<br/>>>>>>  > to the translation interface which are extremely successful. See  

<br/>>>>>> for

<br/>>>>>>  > example SMath Studio (freeware Mathcad clone) translation  

<br/>>>>>> interface

<br/>>>>>> at

<br/>>>>>>  >

<br/>>>>>>  > <a href="http://smath.info/translator/" target="_top" rel="nofollow" link="external">http://smath.info/translator/</a><br/>>>>>>

<br/>>>>>>  Success in terms of what? Quantity I'll believe, quality, not  

<br/>>>>>> likely.

<br/>>>>>

>>>> Can you give an example of the faulty translation?

<br/>>>>

<br/>>>> I see bad suggestions all the time. Luckily the are in translations

<br/>>>> the are restricted so they did not just get implemented directly. You

<br/>>>> want me to find you a couple of suggestions and explain to you why

>>> they are bad Danish translations?

<br/>>>>

<br/>>>> Regards Kenneth

<br/>>> It was said

<br/>>>

<br/>>> “Do not judge, or you too will be judged. For in the same way you judge

<br/>>> others, you will be judged, and with the measure you use, it will be

>> measured to you.

<br/>>>

>> I only want to second this.

<br/>>

<br/>> Judge? About bad grammar, spelling mistakes and failure to implement a

<br/>> common vocabulary across applications? Guilty as charged! And I

<br/>> certainly hope that someone will "judge" me too. In fact they do, and

<br/>> I rely on them to do so, because I also make mistakes when I

<br/>> translate. Don't be mistaken about that. When I talk about just how

<br/>> many bad translations and errors we catch with proofreading, I know

<br/>> that both from doing the proofreading and from having my own stuff

<br/>> proofread. The difference is that I actually care enough about people

<br/>> learning something along the way, to not just correct their stuff

<br/>> without including them in the process. Something that is not always

> possible with open permissions.

</div><br/>LP just do not show them the glossary like it is implemented for offline  

<br/>tools (Lokalize, Virtaal). Moreother, at least for my language  

<br/>Ubuntu-translators recommendations are inconsistent with Microsoft, GNOME  

<br/>and KDE guidelines, as well as current Ukrainian orthography rules.  

<br/>Recommendations for Georgian are wrong for replacers (%(something)s),  

<br/>recommendations for Russian contain visible typos, etc. And  

<br/>Ubuntu-translators team is a core of the most LP-translators teams. Who  

<br/>are the judges? Can they be judged? ;)

<br/><br/>Bad grammar, spelling mistakes, and failure to implement a common  

<br/>vocabulary across applications? In Scilab? Are you sure that a grammar  

knowledge, not a knowledge of mathematics is a best friend here?

<br/><div class='shrinkable-quote'><br/>>

<br/>> In any case, I don't think you and I are going to see eye to eye on

<br/>> this thing. So why don't you guys, the existing community around

<br/>> Scilab translations, decide what, if any, change you want to make, and

<br/>> then I'll check in later* to see if I can contribute to the project or

<br/>> not.

<br/>>

<br/>> \Kenneth

<br/>>

<br/>> * I'll be insanely busy until the end of August anyway, so I probably

<br/>> wont make much progress on the translation in the mean time. I just

> wanted get the discussion going.

<br/></div>

<br/><hr align="left" width="300" />

View this message in context: <a href="http://mailinglists.scilab.org/Settings-for-the-scilab-localization-in-LaunchPad-Translations-tp2870916p2919195.html">Re: Settings for the scilab localization in LaunchPad Translations</a><br/>

Sent from the <a href="http://mailinglists.scilab.org/Scilab-localization-Mailing-Lists-Archives-f2602259.html">Scilab localization - Mailing Lists Archives mailing list archive</a> at Nabble.com.<br/>