Settings for the scilab localization in LaunchPad Translations

[Yuri Chornoivan]

Hi again,

написане Thu, 05 May 2011 14:09:33 +0300, Kenneth Nielsen [via Scilab /  
Xcos - Mailing Lists Archives]  
<ml-node+2902955-1764742167-394903 at n3.nabble.com>:

> Hallo Sylvester
>
> 2011/5/4 Sylvestre Ledru <sylvestre.ledru at scilab.org>:
>> I am copying and pasting the email of Yuri which has been stuck in the
>> moderation queue (and which I just saw)
>>
>> Kenneth, what is your opinion on this ?
>> I am not familiar enough with launchpad/translation to judge here...
>
> Yes I'll try an answer.
>
>> Hi,
>>
>> написане Wed, 27 Apr 2011 19:15:03 +0300, Kenneth Nielsen [via
>> Scilab /
>> Xcos - Mailing Lists Archives]
>> <[hidden email]>:
>>
>>> 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.

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

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

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

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

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

-------------------------------------------------------------------------------------------

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.

To be serious, if you do not want to loose half (at least) of Scilab  
translators, please change the policy to "Structured" or "Open".  
LP-translators cannot give nor quantity, neither quality of translations,  
but the current translators can.

If you are still not sure, please create "Scilab translators" and approve  
its members by yourself or give open permissions. 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.

Best regards,
Yuri


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