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

[Kenneth Nielsen]

>>>
>>>> So in short my suggestion is to assign the translation of Scilab to
>>>> the ~launchpad-translators group and ask your existing translators to
>>>> join the respective language teams within that group.
>>>
>>> Please do not do this. Some of ~launchpad-translators groups are dead
>>> and
>>> cannot be reached (at least Ukrainian one). It will be very hard for me
>>> to
>>> maintain the translation if you do so.
>>
>> It is true that it can happen that a Lauchpad translators team run out
>> of steam and become inactive. However, the appropriate way to solve
>> that then is to try and take over the team and revive it (which Yuri
>> actually is doing now).
> That is not true. I do not want to revive the team. I just want to adapt
> to the new strict requirements of Scilab translation.

I didn't say that you _wanted_ to do it or were happy with, I simply
said that you were in the process of doing it. The last we spoke in
IRC we discussed the possibility of you assuming leadership of the
team, purely for the purpose of translating scilab through that team
and the passing leadership on whenever someone showed up. And you
seemed willing to do that. If I misunderstood or expressed myself
imprecisely earlier I apologize.

>> Please consider this: The launchpad
>> translators group is meant to be a gathering project for all the
>> independent projects in Launchpad, so if language team cannot be
>> maintained there, then it is unlikely that it can around just at
>> single project.
>
> This gathering is absolutely senseless. There is not much common things
> between Chromium, ADempiere ERP, and Scilab.

The gathering is not one of projects that have things in common, but
of translators who work on small projects. This way translators can
collaborate across project boundaries. So if I do this translations,
then when I'm done, I will ask someone on the team to proofread it and
someone who does not have anything to do with Scilab translations
will, because then later I will proofread something for him.

>> So if you want to assign a group to your translation
>> to provide them with the opportunity to make translations of higher
>> quality, then surely this group is the best bet.
>
> It is not true. The parent groups of these groups (Ubuntu translators) is
> of higher quality and quantity.

Once again. Ubuntu translators is not structurally, or with the regard
to purpose, the parent group for the launchpad translators group.

>>> There is no reason to restrict open project translation by just
>>> Ubuntu
>>> users or Ubuntu teams. I have no reasonable proof that the quality of
>>> these group translations (at least in case of Ukrainian and Russian)
>>> are
>>> in any kind better than the quality of open translations.
>>
>> Well first off, there a few things that need to be cleared up. The
>> Launchpad translators group has nothing to do with Ubuntu nor is it
>> specific to Ubuntu users. Launchpad is a generic code hosting site
>> with support for translation, specification and bug tracking and
>> answers. Ubuntu is just one of the projects being hosted on this site,
>> even though it certainly is the biggest. That is also the reason why
>> it has its own translators-group with its own translation teams, which
>> has nothing to do with launchpad-translators. Just to re-iterate,
>> lauchpad-translators is created for all the "little" independent
>> projects in LP and being a member of that group only requires that you
>> have a LP-account, NOT that you are a Ubunt user.
> That is not true again. Consider Danish translation team.
>
> https://launchpad.net/~lp-l10n-da/+members#active
>
> It consists almost exclusively (I am not sure about 1 member) of Ubuntu
> translation team members.


Yes there is quite a lot a overlap in personnel, which means that we
just happen to have a lot a people that are interested both in the
translation of Ubuntu and in the translations of small projects on
Launchpad. That does not change the fact that they are two different
groups with two completely different purposes. If you are interested
only in translating Ubuntu, then you become a member of that group. If
you are interested only translating independent projects in the
Launchpad but want nothing to do with with Ubuntu because you are a
Fedora user, than you only become a member of the other group. We do
not require people to join both groups and that is an important point.

>> As for quality. You are correct that restricting translations to a
>> group like launchpad translators, does not _guarantee_ that the
>> translations will become of high quality, but it does give the teams,
>> that are willing to make an effort to produce the high quality
>> translations, the tools (and control) to make that possible, tools
>> that don't have if the translations is open.
>
> Let's see the stats. LP-translators is a confederation of 42 teams. These
> teams have to manage 276 projects. Most of the teams consist of 3-4
> members (taking into account even people with zero karma).
>
> What quality control are you talking about? They cannot even review the
> propositions.

You need only 2 people to implement a proper proofreading workflow. As
for how many projects they can cover? The groups of Danish translators
that maintain the GNOME desktop translation (about 80 modules), is
about a 3 people, doing so with a complete
translate-proofread-correct-integrate workflow and with a few people
extra we also take case of quite a few of the modules in the
gnome-extras. But you are correct, teams of 3-4 people might not be
able to review all of the suggestions by drive-by-translators, but in
the process of proofreading and hopefully getting into some dialogue
with the people that suggested the translations they might get more
proofreaders and so on.

In any case, when you say: "They cannot even review the propositions."
then you make an assumption that I don't agree with and that is that
they indeed need to get around to all the modules. I will much rather
have a program be in English than poorly translated to Danish, so when
we (and the other teams) have the resources to make the quality
translations then we will, otherwise the remain in English and that is
as it should be.

> This can be clearly seen by the mailing list:
>
> https://lists.launchpad.net/launchpad-translators/
>
> There are no messages for months. LiVES developer asked them to give LiVES
> new translations:
>
> https://lists.launchpad.net/launchpad-translators/msg00136.html
>
> and... The only 100% translation was given by the guy who did not even
> know about LP-translators.
>
> https://translations.launchpad.net/lives/trunk/+pots/lives

If now one replied then it is probably because no one in interested in
translating LiVES. It is a video editor, not something that Linux is
known for doing well, so it can't be a surprise that it is difficult
to find translators. But that does not mean that they would be better
off accepting the translations of anyone that just happens to drop by,
totally independent of language and grammar skills.

> -------------------------------------------------------------------------------------------
>
> Let's analyze the current state of affairs.
>
> Scilab top contributors
>
> Rui Hirokawa 1450 points  - not a member of lp-translators
> Fido 900 points - member of lp-translators
> Yuri Chornoivan 707 points - not a member of lp-translators
> Ondrej Staš 701 points - not a member of lp-translators
> Carml 700 points - member of lp-translators
>
> Well, I propose that Kenneth (1 point of Scilab karma) send a message to
> all the current Scilab translators with the larger Scilab karma and
> propose them to join lp-translators.

That is what I just did and you can think about that exactly what you
want I don't care much. I did that one string just to see if it was
actually true that indeed anyone could write strings there directly,
but you see, I wont contribute as much as a single string to any
project, let alone ask my team to help proofread it, if it is not
under some level of control, if I cannot be assured that our hard and
thorough work cannot just be overwritten by someone that just happens
to pass by. That is the way that I choose to work. If Scilab decides
to do it differently, then I wont loose any sleep over that. I'll just
find another project that does care about quality. There are plenty of
projects that are hungry for translator contributions.

> To be serious, if you do not want to loose half (at least) of Scilab
> translators, please change the policy to "Structured"

Structured wont make a difference in the case where
launchpad-translators have inactive language teams. As I already
explained, the difference between structures and restricted is what
happens if there is no team for a language.

> or "Open".  LP-translators cannot give nor quantity, neither quality of translations,
> but the current translators can.

I disagree but the is off course the choice if the Scilab teamm

> If you are still not sure, please create "Scilab translators" and approve
> its members by yourself

That is the next best solution. This will allow me the control I need
in order for med to contribute. Personally it is not a solutions I
like, but that is because I contribute to many projects and the
bureaucracy if maintaining a group for each one of them is not
something absolutely horrible.

> or give open permissions.

see above

> Restrictions like
> "lp-translators" do not work. It can be easily seen on the Chromium
> example. These restrictions just narrow down the number of translators
> with no quality advantage.

Yes, they will narrow down the number of contributors, but as for
quality I don't think you are right. I have about half a decade worth
of experience with translating free software so I know the kind of and
amount of errors you will find in a proofreading. But as I said
earlier, assigning the translation to a group and making it restricted
or structured off course does not guarantee higher quality, that
depends on the members, but it does give those of us that care about
quality the tools we need.

Regards Kenneth