ubuntu-translations-coordinators team mailing list archive
-
ubuntu-translations-coordinators team
-
Mailing list archive
-
Message #00030
Re: Some Kubuntu translations love
On Montag, 29. Juni 2009 16:44:33 Arne Goetje wrote:
> David Planella wrote:
> > Arne Goetje, Ubuntu i18n/l10n Engineer, member of the UTC team (and
> > temporary Ubuntu Translations Coordinator in the past) will send a
> > follow up e-mail to this thread with the technical details.
>
> Hi all,
>
> we will probably be ready to open translations for Karmic
> sometime this or next week and we'd like to work with the Kubuntu
> community to make sure translations are in good shape for the new release.
>
> Due to technical differences, KDE translations and their templates
> currently require some manual work to get them in the right places in
> Launchpad.
>
> As you might know already, there are three things we need to know for
> each translation template:
> 1. which source package is it belonging to?
> 2. the translation domain (i.e. the filename of the actual .po/.pot file)
> 3. the template name in Launchpad (usually the same as the translation
> domain, with '_' replaced by '-')
>
> In the past we could not detect some of the changes in KDE translations
> (e.g. translation templates moved around, removed, added or renamed) in
> Launchpad, which lead to some translations missing for the end user.
About to change ;-)
> Now, whenever these changes happen, we need to apply them to Launchpad
> manually, i.e. move templates over to other source packages, rename
> templates, approve new templates and disable obsolete ones. This is done
> by the Ubuntu Translation Coordinators team (subscribed to this thread).
>
> The Ubuntu Translation Coordinators are team of community members
> experienced with translation and i18n which would also welcome anyone
> from the Kubuntu community to help us with your experience on KDE
> translations.
I am quite sure you would be able to find a KDE liaison via kde-i18n-
doc@xxxxxxx
> However, we don't have any notification system in place, which notifies
> us of such changes. That's why we had all these problems with Kubuntu
> translations in the past.
>
> On the last UDS we have discussed with some Kubuntu developers what
> needs to be done in order to improve this situation.
> Basically, we need to be notified whenever you make an upload that
> affects translation templates (e.g. a minor version upgrade from 4.2.90
> to 4.2.91). Also, we would need a list of those template changes.
>
> It would be nice to have some scripting in place which automates this
> notification somehow. However, I don't understand all aspects of how KDE
> translations work, so it's difficult for me to give suggestions.
WIP
> What we need is a list containing the source package name and
> the .pot or .po filenames for each source package.
>
> Now, if I download the source package for kde-l10n-de for example, it
> contains a lot of subdirectories, one for each project, I suppose, which
> contain the .po files for German in this case. Each .po file carries the
> translation domain in its filename.
>
> When I download the source package of, let's say, kde4libs, it contains
> a Messages.sh script, which is supposed to generate the .pot files on
> build time if I'm not mistaken.
>
> (Somehow I fail to build both source packages on my local machine, so I
> cannot see what is actually happening.)
>
> What I still don't understand is the relationship between those two
> packages. In the kde-l10n-de package, the translations for kde4libs are
> actually in the directory called 'kdelibs'. This suggests me that the
> directory name does not necessarily match the source package name in
> Kubuntu... so, how is this mapping done?
>
> So, what we need is a list like:
>
> #source_pkg #translation_domain
> kde4libs kdelibs4
> kde4libs kdelibs_colors
> ...
>
> We would need this list for every KDE upload, means the lists should be
> versioned.
Wouldn't it be enough to map upstream name to src package name?
AFAIK the domains kde4libs spits out are the same as the ones in the kdelibs
directory of kde-l10n-de, so we really just need to map the package names:
kdelibs => kde4libs
Listing the domains per package seems like maintenace overhead to me.
> For the upcoming Karmic translation opening (hopefully next week), we
> would need this list for the latest release in Jaunty (4.2.2) and for
> the current one in Karmic (4.2.90). Then we can produce a diff and can
> see what has changed.
>
> We would then need to find out what happened to those templates, which
> have changed between those two releases.
> * Is it a new template?
> * Has it been renamed from another name in the older release?
> * Has it moved across source packages?
> * What happened to those templates which were in the old release but
> are missing in the new one? Have they been obsoleted, renamed or moved?
>
> I don't know how things work on the Kubuntu-devel side... so, I cannot
> give any scripting advice. Maybe those template movements can be tracked
> in the svn changelog?
KDE actually has infrastructure in place for this (well, it's really to do the
movements, but the resulting information is the same anyway) :)
The only problem I can imagine right now are untracked new files. In order to
get something into KDE it first needs to go through kdereview, which is a part
of the SVN repository where the application/library will be waiting for enough
reviews to justify the move to main KDE. So ultimately there are two ways by
which an applicaiton can enter KDE:
* extragear/playground (testing ground packages) => kdereview => KDE
* initial commit to kdereview => KDE
In both cases the po movement would at least be tracked from kdereview => KDE.
BUT, if the application/library didn't go through kdereview for whatever
reason the l10n files will not be listed. Also, if an application introduces a
new domain it will not be traced (Amarok did this in 2.0=>2.1).
If we also want those 2 cases to be detected, then we need to compare the file
lists between uploads (which requires loads of processing time and bandwith)
or we try to detect this via SVN (which is a PITA and requires loads of code).
I am not sure what to do :S
> For notifying us and also for genral translation related bug reports, we
> have created a new project in Launchpad with a bugtracker attached:
> https://bugs.edge.launchpad.net/ubuntu-translations
>
> So, you could submit a new bug, like "[karmic] KDE 4.2.90 uploaded with
> template changes" and a list of the changes attached to the bug report.
> The list of changes should be versioned, so that we know which uploads
> you are comparing (e.g. "changes_4.2.2_4.2.90")
>
> Format idea for the changes list:
> * Categories [New], [Moved], [Renamed], [Removed]
> * 'diff' like +/- indicates old and new names
> * 2 columns: source package name and translation domain (.pot filename
> without '.pot'), separated by TAB
>
> [New]
> +kde4libs foo
> +kde4libs bar
> +phonon baz
>
> [Moved]
> -kde4libs template1
> +phonon template1
>
> [Renamed]
> -kde4libs template2
> +kde4libs template2-extras
>
> [Removed]
> -phonon template3
>
> Of course we'd like to automate as much as possible, so, it would be
> nice if the changes list is also parseable. :)
>
> Please feel free to discuss anything here, if you have better ideas,
> please let us know. :)
>
> I will get a list of the current templates we have in Launchpad and I'd
> like to ask you to review the list and tell us which templates to keep,
> which ones to disable and which ones to rename or move.
I am all for that :)
> Thanks a lot!
>
> Cheers
> Arne
> (Ubuntu i18n/l10n engineer)
*hug*
Follow ups
References