Hi Harald,
У пон, 04. 05 2009. у 11:33 +0200, Harald Sitter пише:
> Within the last couple of days we, at Kubuntu, have been working out a list
> of
> major issues we are facing with the current translation process. They are of
> considerable impact since I know quite some people who actually decided to
> not
> translate Kubuntu any longer, or even stopped using it. But not only users
> are
> affected, I think if we continue to ship Kubuntu with such poor quality we
> will also see a decrease in contributors as well. Why would somone who lives
> in France, spend his spare time on Kubuntu when he can't even make his mom or
> brother use it because they wouldn't understand half the system.
Thanks for writing to the list. And sorry for not responding earlier.
> First off I'd like to direct your attention to
> http://www.flickr.com/photos/19616...@n00/sets/72157608562200171/
> Which provides a set of pictures documenting the state of translation in
> Kubuntu and openSUSE, starting with 8.04. It especially gives a quite good
> impression of what is going on in-development and how the end result relates
> to that. Now, I know that especially for language packs there is a certain
> need for short-term breakage, however it happens way too often for Kubuntu
> (and I would suppose Ubuntu as well). This prevents sensible QA as well as
> using the product.
Actually, Ubuntu is never as badly affected as Kubuntu: KDE uses
completely different set up of translations, and especially KDE4
introduced a huge number of changes to the layout of templates. They
were all changes that neither Launchpad nor language pack infrastructure
were ready to handle.
This is not only about majority of Ubuntu/Launchpad developers being
GNOME-oriented (though, that plays a part too): KDE uses different l10n
layout compared to most other free software.
> One of the most incredible things that happened in the 9.04 cycle were, that
> the pkgbinarymangler (i.e. the component that is responsible for stripping
> translations from packages, in favor of the ubuntu language packs) was
> changed
> to remove translations from desktop files. Incredible is that no one told the
> Kubuntu devs beforehand, that no one even tested if that change would cause
> problems, that this change was done less than a month before release.
> Such things just can not happen anymore.
Personally, I don't like the .desktop hack that Ubuntu uses for GNOME
either: it's only a half-solution, and I believe more effort should be
spent on providing a full solution for regenerated content translation
via language packs. However, that would require a lot more time to
achieve.
If this was done only a month before release, that sounds terribly bad,
though. In general, Kubuntu l10n suffers from lack of testing (or maybe
bug reporting?) early in the development cycle, but introducing a change
a month before release is definitely bad. :(
> It is this and a lot of smaller regressions that drain Kubuntu's development
> performance (change all of upstream KDE's langauge packs to include the
> proper
> desktop file .pots is certainly no fun and not done within a couple of
> minutes).
>
> So here comes the list of issues:
> http://docs.google.com/Doc?id=ajk6csn6c2vn_0c6d8rp6w
I'll try to address some of the issues here that I believe are
important:
> * Upstream
> * Make it easy to get from Rosetta to the upstream Po/Pot files
> (i.e. include links to websvn.kde.org )
At the moment, each POT file in Launchpad can have an arbitrary
description. Links are not highlighted there atm, but we can easily fix
that and promote its use more. Still, this would have to be manually
maintained since it's not something that can be easily automated.
Also, we'd like to have a read only copy updated daily of all upstream
translations in Launchpad, to be able to offer them as suggestions
across the system. Our recent work on Bazaar integration is a step in
that direction as well.
> * Translations can only be changed if their original strings were
> altered by a patch or when there is sufficient evidence that the
> change is necessary.
Apart from technical difficulties in achieving this, I wouldn't like to
do this because it's also the wrong thing to do (IMHO, at least).
Updates to translations in Ubuntu can happen even after upstream (i.e.
KDE) stops releasing updates for that package.
Also, I don't see why we should stop people from using Launchpad merely
as a web-based collaborative PO editor to translate anything in Ubuntu,
including KDE, and then submit those PO files upstream.
> * Make it easy to push changes upstream.
We try to do that as much as possible; as you rightly note, nobody would
accept direct commits from Launchpad, and I am pretty sure upstream
translation teams would accuse us of spamming if we started emailing
them with every few changes on a translation. So, at this moment, we do
the best we can: we offer easy download of "p
