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
> >> _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
signature.asc
Description: This is a digitally signed message part.
