[Kst] Kst translations

[Alexander Potashev]

2011/9/15 Barth Netterfield <netterfield at astro.utoronto.ca>:
> As things turn out, kst2 is a pure QT4 app, and doesn't use KDE libs at all.

Do you mean that Kst won't be allowed to enter Extragear or KDE SC?

A simple solution to get more translators and packagers would be to
move Kst to KDE's Playground. It seems to be a good hiding place: no
one will look at the code there, and localization teams still can
reach to translating your application provided you have a script that
exports all translatable messages (those that are surrounded with
"tr()") into a .pot translation template. You can then convert the
Gettext translation files (.po) back to Qt translations (.ts).
However, this idea sounds weird, so please, read below about Marble.

> We did this to make it easier to run on Windows and Mac, where KDE is
> not as well
> supported as it is under linux.  The major costs of this are:
>  -We aren't actually part of extragear, so the distros are not as
> likely to pick us up.
>  -We don't have translations (though they are probably possible.  We
> do use tr() everywhere.)
>  -Weaker KDE desktop integration (icons and KIO are the big ones)
>  -No access to KDE's timezone classes.
>
> We do have porting to KDE in our wishlist, but we haven't actually
> decided if it is the right thing to do.

There are many people who hate it when a piece of software has kdelibs
in dependencies just for a single class/feature. I would recommend you
to definitely keep a Qt-only version of Kst. Of course, there can be
an alternative version for KDE.

The situation with Kst is very similar to Marble one. The have two
versions: a Qt-only one and another one based on kdelibs. May be you
could do they same with translations as they do? On the translators'
side, there are two auto-generated Gettext translation templates:
marble.pot and marble_qt.pot (the names are self-descriptive).
https://projects.kde.org/projects/kde/kdeedu/marble


-- 
Alexander Potashev