Strings not translated in Kubuntu 10.10 RC

Thu Oct 14 21:49:02 UTC 2010

In data giovedì 14 ottobre 2010 14:33:04, David Planella ha scritto:

> El ds 09 de 10 de 2010 a les 00:44 +0200, en/na Valter Mura va
> 
> escriure:

It's fantastic to see the reply string written in Catalan :-)

Hi David

> I see you've already been doing it in the last replies, but in general
> I'd suggest always keeping the ubuntu-translators mailing list on the
> loop, and include it on CC to any translations-related topics. This way
> anyone in the translations community can answer the questions.

Of course I'll do from now on.
I'm not subscribed on the ubuntu-translators mailing list, I'll do now.

> 
> For issues in a particular language, I'd also recommend to check first
> with the particular translation team, in this case the Italian Ubuntu
> Translators:
> 
>   https://launchpad.net/~ubuntu-l10n-it

Yes, I already checked, I'm a member of the team :-)

> 
> > I tried the Kubuntu Maverick 10.10 CD live and i found that the Italian
> > interface and guide still have problems with translations.
> 
> Due to space constraints, we cannot include all language packs in the
> LiveCD. They are, however, downloaded and installed if there is a
> working Internet connection during the installation.

This is a pity, and my comments were made before I installed 10.10 in my 
system. Some problems remains.

--cut--

> > Kubuntu System Doc is translated, AFAIK, because I have translated them.
> > Why are translation not inserted?
> 
> The Kubuntu Docs translations need to be downloaded from Launchpad and
> included into the package. As Jonathan mentioned, this has not happened
> this cycle yet, but the goal is to include them in an stable release
> update.
> 
> If you'd like to help in this, I'd suggest getting in touch with
> Jonathan and the docs team. I'm sure they will appreciate any help
> anyone can offer.

Of course I'd like to help.

Currently, as active member of the italian KDE Translation Team, I also 
collaborate actively with Italian Ubuntu Team, of which I'm one of the 
administrators (together with Milo Casagrande and Luca Ferretti) and I'm more 
Kubuntu-oriented, I take care of that part of the translation process. That's 
why I also wrote to the devel list.

I have to say that, presently, translators are very few for the Kubuntu part 
(we are three or four, AFAIK). This is because many people choose Ubuntu 
rather than Kubuntu (but I think this is due to marketing and Canonical 
choices and not subject of discussion here).

> > Is it necessary to open a bug for that or not?
> 
> In general it's good to open bugs in translations against the
> ubuntu-translations project:
> 
>         https://bugs.launchpad.net/ubuntu-translatons/+filebug
> 
> Translations are best tested and bugs filed during the development
> cycle, since then they can be fixed more easily. If you want to
> contribute, I'd recommend joining the testing efforts during the
> development cycle.
> 
> However, please do check translations with an installed system first
> before filing bugs.

Ok, I'll follow the entire process.

Gràcies moltes (correcte?) :-)

> 
> El ds 09 de 10 de 2010 a les 02:02 +0200, en/na Alessandro Ghersi va
> 
> escriure:
> > Anyway, I suggest (if it's possible) to move our translations into KDE
> > repository to don't let Launchpad breaks anymore our translation.
> 
> Alessandro,
> 
> 
> As I've said in the past when this has been brought up, this should be
> discussed with translators as well. If such a decision were to be taken,
> a concrete roadmap with the migration to an alternative translation
> infrastructure and how to deal with Kubuntu-specific translations would
> most probably be necessary.
> 
> If you'd like to lead this effort, I'd suggest starting with such a
> proposal.
> 
> However, I do think that going away from Launchpad Translations would
> mean losing a lot of translation contributions from Ubuntu translators
> and increase the contribution barrier for translation contributions in
> Kubuntu.

I think this could be possible but, as I already stated before, the 
translation process in KDE is a bit different from Launchpad one.
KDE creates mainly software and has also external software contributions (eg. 
from opendesktop.org). These processes split the localization in two branches, 
stable and trunk.

*Stable* branch is the KDE "core" branch; and languages need to be "ready" for 
the official releases of the "core" current Software Compilation/Releases.
*Trunk* one is the branch in which are contained apps not kde core-related.
The trunk branch contains also the *playground* space, in which we find 
packages related to software "under testing", such as KPackagekit, for 
example.
The translations in this area are not compulsory, the packages are official 
parts of the stable branch. One day they will be, hopefully.

Obviously, if a (let me say, beautiful) distro, such as Kubuntu, includes by 
default software that is still under KDE Team testing (KPackageKit, for 
example), and its translation is assigne to KDE, it may happen to have non-
translated parts in the Interfaces and guides.

I cannot decide what to include in Kubuntu distro or not. Users and developers 
can choose.

But I can say that, from an (average) user point of view, and from a *l18n* 
point of view, I'm not satisfied of the results.
If I were a normal, average, in my case Italian, user with few knowledge, for 
any reason, of English language, I would be upset if I found non-localised UI 
parts, for the only reason that I cannot understand them.

For these two points of views, here are, IMHO, some considerations, even if 
you, David, thanks again, have already answered in many points below:

- "freeze" the translation process for all parts upstream-related and let 
upstream to make all the work: users to be warned that they could find some 
untranslated UI, due to development/testing/etc in progress

- "freeze" the upstream at one point, and give to the Launchpad Team a 
reasonable time to finish the work, at the risk of not having an app at its 
latest update: in this way we'll probably get a full localized UI and, maybe, 
guides; the risk is that translations will surely diverge from upstream, this 
wouldn't sound good...

- "exclude" non stable parts from the distro, giving the possibility, 
obviously, to get and install them or giving them a sort of initial choice 
(let's say something like "MS browser's choice" in Vista and 7) What's MS? :-D

--cut--
> > I thought that WAS what KUbuntu did for translations.  Anything KDE,
> > they take the upstream ones, and only use LP for Kubuntu-specific
> > stuff.

I generally agree with this.

> 
> In KDE, as in any upstream project, we import all upstream translations
> and give them precedence, as per our policy [3].
> 
> As explained in other occasions (I'll be happy to go into more detail if
> necessary), we do not have a "translations locking" feature in
> Launchpad.
> 
> Instead, we rely on the translation teams to decide on their preferred
> workflow and upstream cooperation. There are many existing Ubuntu
> translation teams with members both in the downstream and upstream
> teams, which facilitate this collaboration. For new teams, we make sure
> they know about upstream [4] [5] and encourage them to participate
> there.

That's what I am :-)

> 
> This works differently in different teams. The two most common
> approaches for dealing with upstream translations are:
> 
> Workflow 1: Translation upstream, import downstream.
> With this approach, you do all translations in the upstream projects
> using their translation interfaces if they've got any. Translations will
> then be imported in all downstream distributions.
> 
>       * Pros: you only have to care about translating in every upstream.
>         Then translations will flow downstream.
>       * Cons: many upstream translation projects have translation
>         methods that might not be for everyone - too technical in many
>         cases.

I agree with you and I think this is the best method.

But I think, as I have exposed above, this is not apply when you have different 
workflows (priorities?) for different branches, such as KDE process.

> 
> Workflow 2: Translation downstream, commits upstream.
> With this approach, you do all translations in using the Launchpad web
> interface and when you are ready you export them and commit them in the
> upstream projects.
> 
>       * Pros: translation for all projects is done through a centralized
>         and easy to use translation interface, which also has
>         permissions and review functionality for QA. Low barrier for
>         contribution: no prior technical knowledge required
>       * Cons: there is no automated way to send back translations to
>         upstreams yet, so there should be a manual step for a
>         coordinator or a team member with technical knowledge to export
>         translations and commit them or send them to upstreams.

This is a possibility, but the translation approach between KDE and Launchpad 
is different: packages in kde are assigned to single translators, as per KDE 
policy, and the Launchpad translator(s) work cannot be the same of KDE.

In plain words, I cannot translate a package assigned to another one, even if 
I could. It wouldn't be the right way to act.

> 
> El ds 09 de 10 de 2010 a les 09:23 +0200, en/na Valter Mura va escriure:
> 
> More:
> > - OpenOffice.org (all packages, but I suspect that, once everything
> 
> installed,
> 
> This is, again, due to the LiveCD not including Italian. The installed
> system should be all localized.

Yes, now everything is ok :-)

> 
> A note on OpenOffice.org translations: we are shipping upstream
> translations and we disabled translations in Launchpad since a few
> cycles back, as there wasn't anyone who could take care of including the
> translations from Launchpad in the package (they cannot be included in
> language packs due to their special format). For more info on how
> OpenOffice.org translations are (were) handled, see [6].

I'm also a member of OOo Translation Team and I have welcome this decision: 
OpenOffice.org project is very large and easier and better to manage in separate 
organization and infrastructure. The new Pootle, ready at the end of October, 
will grant to us more functionalities and speed.

Warm regards,
-- 
Valter
Registered Linux User #466410  http://counter.li.org
Kubuntu Linux: www.kubuntu.org
OpenOffice.org: www.openoffice.org