Zanshin is in kdereview

[Kevin Ottens]

Hello,

On Monday, 19 June 2017 21:50:16 CEST Luigi Toscano wrote:
> Kevin Ottens ha scritto:
> > On Monday, 19 June 2017 18:56:39 CEST Luigi Toscano wrote:
> >> On Monday, 19 June 2017 18:50:23 CEST Kevin Ottens wrote:
> >>> On Tuesday, 13 June 2017 00:07:01 CEST Albert Astals Cid wrote:
> >>>> Have you read the page that speaks about how to write Messages.sh
> >>>> files?
> >>>> It's quite good. Please read it and explain what you don't understand.
> >>> 
> >>> It's more that I don't quite see clearly the distribution of the .po and
> >>> such after the Message.sh is run.
> >>> 
> >>> That being said, wouldn't that be more natural to either extend
> >>> extractrc
> >>> to spit out mock QObject::tr() calls? Or to have the Message.sh run perl
> >>> on the file?
> >>> 
> >>> Sounds cleaner to me than having several catalogs loaded for an
> >>> otherwise
> >>> self-contained application.
> >> 
> >> I haven't checked the code, but the idea is that:
> >> - messages handled by Qt translation system should end up in the
> >> <module>_qt file;
> >> - messages from KI18n should end up in a file or a set of files named as
> >> you want (you just need to set the proper domain which matches the file
> >> name).
> >> 
> >> So please try to follow these guidelines. If the application already uses
> >> KI18n directly or indirectly, I would just use it for everything.
> > 
> > I find unfortunate we actively discourage being able to work without ki18n
> > in such case. But OK, got better things to do I'll stop fighting this
> > one.
> We are not discouraging anyone.

Technically we do, too many hoops to go through. I didn't mean *you* were 
discouraging me, I'm just saying that the fact that I have kparts in the mix 
makes it somewhat harder.

> You can definitely work without KI18n, or mixing Qt-only modules with
> KI18n-managed modules. Marble and Step are two example of this, and this is
> not because we like it or not but there are specific technical reasons for
> it.

Sure, I guess we'd be more similar to the Marble case.

> In this case, every module which links to kparts should use KI18n, but you
> can have pure Qt libraries (even static) which uses ::tr. And of course you
> need two translations files.
> 
> I'm not sure why you didn't like the above solution.

Just more work over time, and I don't have the bandwidth ATM. Typically we 
tend to assume ki18n and a single catalog as the common case (and rightly so), 
so does releaseme assume that too? And then I have to think about both files 
for shipping, etc.

I just don't have the energy to think all that through so I'd rather go the 
lazy and easy path with the patch I did.

> Now, can we properly discuss this? I don't want people coming back and
> saying that a solution was forced for $reasons when it was not forced at
> all.
> (that said, KI18n is better, but again you don't need to use it).
> 
> > This one switches it all to i18n: https://phabricator.kde.org/D6283
> 
> I'm going to put a -1 until we discuss this properly.

Hope the above clarifies my reasons a bit.

In a nutshell: tr() was used for an hypothetical mobile port, this port is 
still not in sight with the bandwidth I currently have and tr() is creating me 
troubles mainly due to the kparts plugins; so either I drop said plugins or I 
switch to i18n to be like everyone else. I'm going for being like everyone 
else.

It can always be revisited later if there's really a mobile port or such 
emerging.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20170620/e1c8d328/attachment.sig>