Strings not translated in Kubuntu 10.10 RC

David Planella david.planella at
Thu Oct 14 13:33:04 BST 2010

El ds 09 de 10 de 2010 a les 00:44 +0200, en/na Valter Mura va
> Hi All,
> I suppose it is not the time to write down here this notes, and probably this 
> could be matter of discussion for a new translation plan, if any. And how 
> useful they are.

Hi Valter,

Thanks a lot for the testing and the feedback on Kubuntu translations.
I'll try to answer your questions and others on this thread.

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.

For issues in a particular language, I'd also recommend to check first
with the particular translation team, in this case the Italian Ubuntu

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

In Maverick only the following languages were included in the Kubuntu


Italian could unfortunately not be included, as many others. Therefore,
I'd suggest to test with an installed system and report back.

> Some parts of the System Settings subdialogs are still in English and the 
> Kubuntu System Doc, also.

See the comment above.

> 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

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.

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

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.

> Interface:
> I suppose this gap is due to the different KDE upstream branch Launchpad takes 
> the po files from.
> Because KDE splits between stable and trunk (and several of them are still in 
> playground), and Kubuntu uses apps from both of them (e.g., read 
> "Kpackagekit", it's 2 years I cannot obtain get its complete translation, even 
> if I'm always translating it), it is very difficult to get a complete 
> translation.
> The other reason is, obviously, the difference between release dates :-)
> So I wonder: is it possible to have a system that warns the Ubuntu approved 
> translators when a po file change?
> Better if an user, with a number of po files subscriptions, could receive a 
> sort of "digest" of the changes to his/her email address.
> Another question: is it possible to have the source indication for files that 
> have been picked upstream? This will facilitate enormously some our tasks, 
> such as going to see if a file is only Launchpad-related or also, in our case, 
> KDE-related.
> Thanks for the attention, ciao

El ds 09 de 10 de 2010 a les 02:02 +0200, en/na Alessandro Ghersi va
> Anyway, I suggest (if it's possible) to move our translations into KDE
> repository to don't let Launchpad breaks anymore our translation.


I do acknowledge the fact that there are issues with the integration of
KDE translations into language packs. We've discussed them in the past,
but I'll be happy to discuss them again in more detail if necessary.

So far though, and apart from [1] and [2], there weren't any other
related to this on this thread, if I remember correctly. If there are
any, please feel free to point to an existing bug or to file new ones if

>  Get
> rid of Launchpad for the translations maybe can be a thing to put into
> the list of possible discussion at UDS.

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

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

El dv 08 de 10 de 2010 a les 23:23 -0400, en/na Mackenzie Morgan va
escriure: On Friday, October 08, 2010 08:02:07 pm Alessandro Ghersi
> > translation.  Get rid of Launchpad for the translations maybe can be
> > a thing to put into the list of possible discussion at UDS.
> I thought that WAS what KUbuntu did for translations.  Anything KDE,
> they take the upstream ones, and only use LP for Kubuntu-specific
> stuff.

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

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

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

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. 

El ds 09 de 10 de 2010 a les 09:23 +0200, en/na Valter Mura va escriure:
> - (all packages, but I suspect that, once everything

This is, again, due to the LiveCD not including Italian. The installed
system should be all localized.

A note on 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 translations are (were) handled, see [6].

El ds 09 de 10 de 2010 a les 15:21 -0400, en/na Scott Kitterman va
> They still get loaded stripped and uploaded into language packs with
> opportunities along the way for LP translators and infrastructure to
> "improve" the situation.

Hi Scott,

That's correct. Our existing language pack infrastructure allows us to
provide translation updates to stable releases throughout the lifecycle
of a distro even when upstream translations are no longer shipped due to
our SRU policy. Kubuntu translators can choose to complete translations
and fix mistakes if necessary, and their work will be shipped in the
language packs.

Here's also more info on why we do what we do:

I also acknowledge the fact that in Kubuntu this might require
additional work for developers (and some special-casing in the Launchpad

> We've repeatedly asked for existing KDE translations to be locked so
> that the only thing Ubuntu translators can do is provide missing
> strings.  It's not a priority apparently.

It's not one of the current priorities, that's also correct. To provide
more background, let me include the reply I sent to ubuntu-devel some
days ago on this:

Your request has been echoed before, and it is not something trivial to
implement: while some translation teams might want to work upstream
exclusively, others might want to work on Launchpad only and then send
translations upstream. I've seen both workflows, and right now this is
something better controlled by the translation teams themselves than on
a Launchpad-wide setting. Since the time we requested all translation
teams to be moderated and the global policy on translations for Ubuntu
to be Restricted, this has been working quite well.

We've got scarce development resources for working on Launchpad
Translations, and defining the priorities to work requires always a
balance between new features and work that provides an immediate benefit
to translators and upstreams. Right now the Launchpad Translations
developers are working in providing a better upstream integration
experience, which I believe to be a higher priority at this time.

Therefore, they won't likely have the time to work on any new feature
such as template locking in the near future. In any case, that should
not discourage anyone in contributing to this, and the Launchpad
Translations development team will be happy to mentor anyone willing to
step up and work on such a feature (or any other). Here's how:

You can also see some of the priorities, as expressed by the community
on several surveys some months ago. Notice that template locking was
indeed a request, it just wasn't on the top list:

El ds 09 de 10 de 2010 a les 19:58 +0200, en/na Valter Mura va escriure:
> I also opened a "question" in Launchpad, I don't know it will be
> useful:

All feedback is always useful and very welcome. Thanks for taking the
time to write down your thoughts and submitting them.

I'll let the Launchpad Translations developers reply in more detail to
them. Also please take into account the comments above on resources and
priorities. If some of the features are not implemented, I just want to
make sure it is clear why.

Phew, this was a long reply. I hope you find it useful. If any part is
not clear, or if you've got more questions related to translations,
please feel free to ask on the translators list or on the
#ubuntu-translators IRC channel on Freenode.




David Planella
Ubuntu Translations Coordinator / /

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
Url : 

More information about the kubuntu-devel mailing list