Zanshin is in kdereview

[Luigi Toscano]

Kevin Ottens ha scritto:
> Hello,
> 
> 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.
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.

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. 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.

Ciao
-- 
Luigi