atom feed24 messages in org.kde.kde-core-develRe: Native gettext support for Qt (wa...
FromSent OnAttachments
Kevin OttensJun 6, 2011 3:04 pm 
Albert Astals CidJun 6, 2011 3:17 pm 
Kevin OttensJun 6, 2011 4:14 pm 
Albert Astals CidJun 6, 2011 4:26 pm 
Kevin OttensJun 6, 2011 4:38 pm 
Inge WallinJun 6, 2011 11:39 pm 
Albert Astals CidJun 7, 2011 12:46 am 
Aaron J. SeigoJun 7, 2011 1:21 am 
Manuel "Sput" NickschasJun 7, 2011 2:51 am 
Andreas PakulatJun 7, 2011 3:39 am 
John LaytJun 7, 2011 3:41 am 
John LaytJun 7, 2011 4:20 am 
Albert Astals CidJun 7, 2011 10:57 am 
MarkJun 8, 2011 11:48 am 
John LaytJun 8, 2011 12:27 pm 
John LaytJun 8, 2011 12:27 pm 
Albert Astals CidJun 8, 2011 1:29 pm 
Ingo KlöckerJun 26, 2011 12:45 pm 
Albert Astals CidJun 26, 2011 1:12 pm 
Ingo KlöckerJun 27, 2011 1:18 pm 
Aaron J. SeigoJun 28, 2011 9:27 am 
John LaytJun 28, 2011 2:57 pm 
Nicolás AlvarezJul 2, 2011 7:31 pm 
David JarvieJul 5, 2011 4:18 am 
Subject:Re: Native gettext support for Qt (was: Intended organization of KDE Frameworks)
From:John Layt (john@googlemail.com)
Date:Jun 7, 2011 4:20:51 am
List:org.kde.kde-core-devel

On Tuesday 07 Jun 2011 10:51:29 Manuel "Sput" Nickschas wrote:

On Tuesday 07 June 2011 08:46:54 Albert Astals Cid wrote:

This means that if you want Tier 1 frameworks to be translatable you need either to teach Qt to understand gettext files natively or to make Tier 1 frameworks use pure based Qt/Linguist solutions which does not fit either in what scripty is able to do neither in what our translators are used to.

Wouldn't that be a sane thing anyway? I never really understood why Qt needs to have its own, completely incompatible translation system while the rest of the world happily uses gettext. In Quassel, this has hurt us a lot because we cannot easily tap into existing translation teams and resources. As it turns out (and understandably so), translation teams like that of KDE have their established workflows centered around gettext, and are not too willing to start using Linguist or other tools to translate an application that is Qt- based.

A while ago, we have tweaked Quassel's build system to accept .po files and generate .qm files at build time from those. But this is error-prone and requires tools (e.g. lrelease) that are not found on all systems by default. Still, offering gettext translations has significantly increased translator contributions for us...

This whole situation is such a mess that we actually looked into taking KDE's i18n stuff and friends, and port it over to Qt (by way of deriving QTranslator), just to be able to reap the benefits of KDE's translation resources. Turned out that i18n() depends on too much of other kdelibs stuff to make that a feasible, maintainable option though.

I really think one should look into the opportunity given to us by the move to Qt5 to bring native gettext support to Qt, and retire the old tr() system, or at least make it just another option. This would tremendously help Qt-based apps to get good localization support, and even more so applications like Quassel that can be built with and without KDE support.

~ Sputnick

We discussed translation briefly at Platform 11 and Qt moving to or supporting .po is something we really want to push for at QCS. I really hope we have some people knowledgable about translation at QCS able to argue the point, otherwise please let me know the key arguments in favour.

As part of the whole modularisation discussion the idea was also floated that if Qt is unwilling to move to .po then our translation module could be an attractive option for other projects looking for a sane and fully featured transaltion solution.

John.