Loading Qt 5 translations

Aurélien Gâteau agateau at kde.org
Tue Jun 10 12:02:16 UTC 2014


On Sun, Jun 8, 2014, at 15:04, Albert Astals Cid wrote:
> El Dimarts, 27 de maig de 2014, a les 07:08:45, Aurélien Gâteau va
> escriure:
> > On Mon, May 26, 2014, at 9:41, Alexander Potashev wrote:
> > > 2014-05-26 18:17 GMT+04:00 Aurélien Gâteau <agateau at kde.org>:
> > > > Not sure where we could put this. Frameworks load their translations, I
> > > > believe it should be up to Qt to load its own translations. The only
> > > > framework where it could maybe make sense to add such feature is in
> > > > KI18n, but even there it feels a bit out of place.
> > > 
> > > Aurélien,
> > > 
> > > You can't put .qm loading code in KI18n because Tier 1 frameworks
> > > should not depend on KI18n.
> > 
> > I know, but I think we can assume devs who only use Qt and tier 1
> > frameworks are aware that they need to load Qt translations themselves.
> > This problem is not limited to frameworks: if you create a Qt-only
> > application and make use of QDialogButtonBox or QMessageBox, then you
> > already have to load Qt translations yourself, regardless of whether you
> > are using KDE frameworks or not.
> 
> So we have a cmake macro that loads code to load your own Qt catalog. Can
> we 
> have one cmake macro that creates the code to load the Qt "default"
> catalogs? 
> 
> Would that help? I don't want to make it hard, otherwise most devels will 
> forget.

It feels wrong to dynamically generate code which is always the same. I
would rather assume that all end-user code we care about eventually uses
KI18n and therefore add code loading Qt translations in KI18n, with a
way to opt-out of it. But the real fix IMO would be for Qt to take care
of it itself.

Aurélien


More information about the Kde-frameworks-devel mailing list