Re: Translations for Glabels 4.0

[Sveinn í Felli <sv1 fellsnet is>]

Þann 1.11.2018 11:31, skrifaði Carmen Bianca Bakker:
> Hey Mario,
>
> On ĵaŭ, 2018-11-01 at 10:04 +0100, Mario Blättermann via gnome-i18n wrote:
> > But Glabels development has been switched from GTK to Qt, and the
> > version control system now resides at Github [1]. The upcoming major
> > version 4.0 will be based on Qt. Along with the Qt port, we are no
> > longer using po files, but ts files.
>
> Apart from Sveinn's fairly valid concerns, I am not really understanding
> why the switch from gettext to Qt Linguist was made.  Is it not possible to
> keep using gettext (and keep all current infrastructure) while still
> using Qt?  I understand that it is not Qt's native solution, but it's
> perfectly feasible.  I know that KDE uses gettext instead of Qt
> Linguist[1].

As I said, it's not overly complicated to convert between TS and PO:

lconvert -if ts -of po -o application<lang>.po application<lang>.ts

Translate with gettext-enabled tools, then convert them back using 
lconvert again:

lconvert -if po -of ts -o application<lang>.ts application<lang>.po

For this to work, you need Qt 4/5 Linguist tools set up.

The question is whether this should be scripted on the server side, so 
that people opting for off-line translation could download their 
preferred format - or if everyone should do it on their own?

There are translation platforms where the functionality is built-in; I 
know that Transifex does, pretty sure that Weblate and Crowdin can also.

P.S: Apparently parts of KDE are nowadays delegated to pure Qt, meaning 
that some buttons/dialogs must be translated in Qt itself. The Qt people 
support much fewer languages than KDE or Gnome, so that can be a problem 
in itself if you're translating some minor language...

Best regards,
Sveinn í Felli