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

[Kenneth Nielsen]

2011/5/9 Yuri Chornoivan <yurchor at ukr.net>:
> написане Mon, 09 May 2011 17:13:32 +0300, Kenneth Nielsen [via Scilab /
> Xcos - Mailing Lists Archives]
> <[hidden email]>:
>
>>
>>
>>>> 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?

Yes

> What if the review will come in a month or two? What if it will never come
> at all?

Provided the contributor has made contact with the team, so they know
about the contribution, then it is about the priorities of that team
when the person gets the review. What if it never happens? Well, as I
have already said, more than once, I personally would rather have
fewer translations of better quality.

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

Maybe not in Scilab circles, but it has certainly been around. As I
have also mentioned at least a couple of times already, this is
actually the LP recommended way for independent projects past the
startup phase.

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

If the purpose is to implement a controlled proofreading workflow.
Then yes, it will certainly create less bureaucracy having a shared
group for all the independent projects compared to one group per
project.

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

That is not the result of what I am proposing, please stop putting
words in my mouth.

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

It can happen, yes. But with a probability of 1, hardly.

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

I have used that expression many times before in this discussion. With
"the tools necessary to implement the workflow" I am referring to
having control over the translations and functionality for
proofreading.

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

If the first persons that arrive have bad intentions or are sloppy,
then you will have lost no matter what. We have already had our share
or disasters back when all translations were open be default. But why
I don't understand is why you think that is different from what you do
now, if you have only person per language, no one among you knows
anything about the quality of the translations into the other
languages, so you are also just trusting the first (and in this case
only) person that arrived.

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

- It is possible to filter translations by contributor (all though not
directly in the translation interface). But often enough it is enough
to simply filter by new suggestions.
- You can also dismiss wrong suggestions.
- Suggestions enter the TM the moment that it has been suggested and
does not disappear from there if you dismiss the suggestion. However,
when you are offered the string, you will be offered information about
whether the string has been used somewhere else or is just a
suggestions.

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

What is with the "restricted" I have never said that it is the
recommendation that it should be restricted. I have said that it is
the LP recommendation that it should be "structured" or "restricted"
when the projects is through the start up phase. And I have said that
I personally, if I was a coordinator of a project would prefer
"restricted", but as far as giving me the tools that need for
translating projects, structured is enough.

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

Yeah that would be a nice feature, but until then, we make do with
having it on another internet page and encourage translators to gather
around a email list where where you will know about the glossary.

> Moreother, at least for my language
> Ubuntu-translators recommendations are inconsistent with Microsoft, GNOME
> and KDE guidelines,

This is a special case that is often discussed. In this case there is
no right or wrong. Unifying glossary across all large projects would
be nice but it is not always possible.

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

So you are using the fact that these bad guidelines exits as an
argument not to have any at all? How to fix these problems, well we do
the same thing we always do in free software, we form groups, that
communicate, and discuss the problems.

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

I was speaking about all projects in general, which should be pretty
clear from the context. For very technical programs it is off course
an extra requirement with some technical knowledge. However, I
maintain that it is still very important.

One of the most common corrections during our proofreading is one of
simple stile. It seems that it is very easy for translators to get
stuck with the English sentence structure when you are actually
translating it, and this sentence structure might not be the natural
one to use in the other language. However, it seems that it is far
more easy for the proofreader to ignore the English string and simple
see if the string is good e.g. Danish. In these cases there is no
right or wrong, and therefore the corrections will often just be
suggestions for an alternative formulation. However the results of not
doing it, is to have a lot of Danish strings with English sentence
structure in the translation. So yes, this, along with grammar and
spelling is very important for leaving the user a professional
impression of the program.

Regards Kenneth

>> 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: Re: Settings for the scilab localization in
> LaunchPad Translations
> Sent from the Scilab localization - Mailing Lists Archives mailing list
> archive at Nabble.com.
>