ubuntu-translations-coordinators team mailing list archive

[Harald Sitter <apachelogger@xxxxxxxxxx>]

2009/7/31 David Planella <david.planella@xxxxxxxxxx>:
> Hi,
>
> Thanks for the clarifications, I've been applying the changes from the
> suggestions and explanations during the last few days.
>
> I've still got some questions, though:
>
> El dg 26 de 07 de 2009 a les 22:05 +0200, en/na Harald Sitter va
> escriure:
>> 2009/7/22 David Planella <david.planella@xxxxxxxxxx>:
>> > = Other =
>> >
>> > == Docs ==
>> >
>> > The following source packages and corresponding templates I believe
>> > should be disabled as well, but I'd like to double-check that
>> >
>> >        • kdebase-runtime
>> >        • kdebase-workspace
>> >
>> > I cannot find their templates at
>> > http://websvn.kde.org/tags/KDE/4.2.98/kde-l10n; only in trunk
>> > (http://websvn.kde.org/trunk/l10n-kde4/ca/docmessages/) and not all of
>> > them. I believe they are documentation files, but I'm not sure, since
>> > they are stored under docmessages and there is also a docs folder in
>> > trunk.
>>
>> They actually reside in kdebase in KDE SVN.
>>
>> kdebase-runtime is actually just a subfolder (kdebase/runtime) in KDE
>> SVN, same applies for kdebase-workspace as well as
>> kdelibs-experimental. This is the reason that templates of those
>> source packages will show up in kdebase/kdelibs' folder in KDE SVN.
>>
>
> I could not find those folders neither in
>
> http://websvn.kde.org/branches/stable/l10n-kde4/ca/messages/kdebase/
>
> nor in
>
> http://websvn.kde.org/tags/KDE/4.2.98/kde-l10n/ca/messages/kdebase/
>
> and actually we've got templates for plasma_applet_saverdesktop in
> kdebase-workspace, whereas upstream has got them in kdebase. I don't
> think it is a problem as long as the gettext domain is specified
> correctly, I'm just trying to understand where these kdebase-runtime and
> kdebase-workspace source packages come from and where I can correlate
> them in upstream SVN for translations. As an example:
>
> LP:
> https://translations.launchpad.net/ubuntu/karmic/+source/kdebase-workspace/+pots/plasma-applet-saverdesktop
>
> Upstream:
> http://websvn.kde.org/tags/KDE/4.2.98/kde-l10n/ca/messages/kdebase/plasma_applet_saverdesktop.po?view=log

Well, that is exactly what I was trying to say ;-)
In SVN kdebase-workspace is really kdebase/workspace, so kdebase is
the super component (even though kdebase tarball wise is kdebase/apps,
though we probably should not think to much about the merits of this
weirdness). Therefore all templates end up in one single directory in
KDE SVN, the one for the super component kdebase, so everything we
have in kdebase, kdebase-runtime and kdebase-workspace _should_ be
available in the kdebase directory upstream.

>> > == Desktop files ==
>> >
>> > I could not find out where the .desktop files translations reside in
>> > SVN, so all URL of the type
>> > http://websvn.kde.org/tags/KDE/4.2.98/kde-l10n/ca/messages/kdelibs/desktop_kdelibs.po are currently broken in the wiki page.
>>
>> http://websvn.kde.org/branches/stable/l10n-kde4/templates/messages/kdelibs/desktop_kdelibs.pot
>>
>> Since desktop file translations get repacked into the actual desktop
>> files, the po files will not show up in the tag/tarball.
>> Also, generally I would map the wiki to branches/stable/l10n-kde4
>> rather than a tag, since the branches/stable always represents current
>> stable (meaning >= rc, because trunk gets branched around rc time
>> which is also when we should start uploading/importing the kde-l10n-*
>> packages)
>>
>
> I had a chat with upstream and they further clarified this to me as
> well. Regarding the link to put in the wiki pages for desktop_*.po
> files, it shouldn't be branches/stable/l10n-kde4, since this is
> constantly changing and the wiki page must be distro-specific. Since
> there is no way to have a link to the desktop_*.po files in the tags
> branch (upstream removes them from there), the best way is to add a link
> to the particular SVN revision when the particular KDE release was
> tagged.
>
> After talking to Riddell, we agreed that it might make sense to add this
> revision (as the date of tagging) in the debian/rules from the
> kde-l10n-xx packages, in the rule where desktop files are fetched from
> SVN. In theory, the kde-l10n packages should only be refreshed (as in
> fetching the upstream translations) right after the KDE release to pick
> up the right translations, but in case they need to be refreshed
> afterwards, specifying the SVN revision as the tagging date will avoid
> getting too new translations from the stable branch.

Unless there is an additional advantage of having the tag revision
defined for each kde-l10n package, I really think this should be moved
to one single location (for reliability reasons I suppose). Probably
the CDBS file Kubuntu uses to extract templates etc.

>> > == Extragear, etc ==
>> >
>> > In the extragear section I've put everything I couldn't map to the KDE
>> > modules. I still have to review those.
>>
>> General notes:
>> + should be named extragear/playground (they only differ by
>> reliability of software, translationwise the process is the same, as
>> is the path structure in KDE SVN)
>> + the websvn urls should be mapped to trunk/l10n-kde4 for most of
>> extragear (since extragear apps mostly release from trunk)
>>
>
> Hmmm, that's going to be a problem if we want contributors to be able to
> submit changes for the particular version of the extragear app. If we
> include a link to the ever-changing trunk, there is no way to correlate
> this to the Karmic version.
>
> The right way to do this would be to include a link to the particular
> SVN revision of the version used in Kubuntu, but unless there is an
> automated way to track this, I think it is unfeasible to manually create
> or maintain such a list, since I'm guessing that extragear apps are not
> all released at the same time.

Some are released the same time KDE is. But the real problem is, since
extragear apps have free hand in how they actually do their releases,
they might not do tagging. Otherwise it would be pretty easy to build
a database of each version with associated SVN revision based upon
parsing the tag directory. This can be done for all of the apps
released along KDE + apps using my release script (i.e. digikam +
kipi-plugins + amarok). I am not sure partially reliable data is any
more useful than just adding a general disclaimer about mismatches
between packaged-version and trunk-version.

regards,
Harald