Proposal for (Italian) translation

Valter Mura valtermura at
Fri May 7 19:14:47 BST 2010

Hi All,

I'm new to the list and, since now, I've been a "lurker" :-)

I'm neither a developer nor a programmer. I'm only a translator, and I'm one 
of the few Italian translators for Kubuntu (unfortunately).

I read the discussion in the file you link in the Timelord Page, and I think 
it's the moment, now, to give my humble opinion for the way to follow for a 
rational translation.

I also join the KDE and OpenOffice.orf Italian translation teams, so I know the 
different ways they handle the projects.

Launchpad is a good project management system, and it is easy to use. But, as 
per my experience there, the management of the Ubuntu translation packages 
needs some tunes to work at its best:

1- The translation projects should be separated.
Better explained: Kubuntu packages should be clearly separated from Ubuntu and 
Xubuntu ones, translators needs to search and find them easily.
Only the "shared" packages need to stay together.

2- Upstream packages should stay in a subdirectory of the distro.
KDE, and all the packages "included and mantained" by the Italian KDE team 
should be clearly visible to all. I know which are them and who are the 
translators, but many people inside Luanchpad don't know them and modify and 
suggest inside. Many times is not clear which packets could be translated and 
which not. Many people are normal people, like me, and they don't know which 
packets are kde, which kubuntu, which openoffice and so on. In one word, this 
means "mess".

3- The translation process (tp) should be always "restricted".
This is necessary, IMHO, only for a rational management of the tp and the 
correct style of the translation.
Anybody could, or any robot could, leave suggestions, of course, but the last 
word should be always of the "official" (allowed) translators, the "intrepid" 
ones that showed capacity, knowledge, efforts and trustworthiness throughout 
the process.

4- The tp should follow the translation rules of the main upstream 
In this case, IMHO, KDE, also for Kubuntu self-programmed apps. Better 
explained: in Italian, Gnome uses the impersonal genre to "render" the English 
"you" and the Ubuntu Italian Team follows the same. KDE Italian Team uses the 
2nd singular and Kubuntu should use the same. If the projects are unified, how 
could we manage with this problem? On the other hand, Italian 
Team uses the 2nd plural, and this is a fact, we cannot change it, because it 
is a separate project. The same for KDE.

5- Working online or offline?
Good question. I prefer working "offline", I can manage well my strings, have my 
translation memory and, once finished, upload all the stuff on the site. KDE 
and, mainly, follow this way. Ubuntu not, or well, it is possible 
to translate offline, but it is suggested to use the online system.
While there is a good reason to have a "real time" translation always 
available in the system, many things cannot be handled and you cannot have the 
translation "in your hand". Moreover, presently it is not possible to have 
"fuzzy" strings in Launchpad. This is not good, because they allow translator 
to speed up the tp, making only few (and necessary) changes. The most CAT 
Tools and Pootle do that. For the CAT tools, we can discuss.

6- If a translator has the responsibility of a package, the online system 
should advise him/her if a change in the strings occurred. This is necessary 
to speed up the tp. Imagine a translator who has 100 packets and 30,000 
strings to check... this feature should be integrate, as mimimun requirement, 
inside an user account "translation status view".

7- More responsibility, better work.
if a translator is responsible of a packet, or a group of packets, I think 
he/she will be more responsible during the tp. Responsibility is not 
mandatory, obviously. KDE works in this way.

That's all folks, for the moment.
Sorry for the mistakes and I hope my considerations could be useful to improve 
Kubuntu (which is my only goal).
Waiting for your replies, suggestions, critics... :)

Registered Linux User #466410
Kubuntu Linux:

More information about the kubuntu-devel mailing list