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