ubuntu-translations-coordinators team mailing list archive

[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

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

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

In any case, using trunk might be good enough, since at least it might
point translators in the right direction and still most of the strings
in trunk and in Launchpad will be the same.

Regards,
David.

-- 
David Planella
Ubuntu Translations Coordinator
david(dot)planella(at)ubuntu(dot)com
www.ubuntu.com

Attachment: signature.asc
Description: Això és una part d'un missatge signada digitalment