[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: Naming scheme and requirements to work for the new KCM modules
From:       Luigi Toscano <luigi.toscano () tiscali ! it>
Date:       2018-05-18 16:16:39
Message-ID: c89b0899-d476-4097-1781-48c3f5beaff7 () tiscali ! it
[Download RAW message or body]

Yuri Chornoivan ha scritto:
> пʼятниця, 18 травня 2018 р. 10:52:16 EEST ви написали:
>> Yuri Chornoivan ha scritto:
>>> Hi,
>>>
>>> Another KCM is ported to Qt Quick.
>>>
>>> https://phabricator.kde.org/D12936
>>>
>>> It seems that there are no clear instructions on how to deal with
>>> translations and nobody can test if they work at all for the ported
>>> modules (and other parts of what was once KDE and now is a set of parts
>>> that sometimes cannot be put together).
>>>
>>> Can somebody point me to some wiki page on what exactly should be made in
>>> the new KCMs to make them really translatable?
>>
>> As far as I know, there is no difference between the old and the new KCMs
>> (and we have already few QtQuick-based ones).
>> As libraries, the name of the catalog should be set only by the defining
>> TRANSLATION_DOMAIN, and that name should match the catalog generated by
>> Messages.sh
> 
> I had several reports that this does not work for a user.
> 
> All KCMs in Plasma 5.12 (Mageia 7) seem to be almost translatable (some
> strings, like "No adapters found" in Bluetooth KCM, were fixed after the
> release. But looking into the untranslated for several releases "System
> Activity" (Ctrl + Esc) "I gotta say it now, better loud than too late".

Sure, we need to fix every untranslatable thing. I'm just not sure how much 
the names of the catalog matters (assuming that it is loaded).

> 
>> So the only rule should be: make sure to not change the name of the domain
>> when porting. Or at most use kcm5_<name> in the name one and ping us.
> 
> Now we have:
> 
> kcm_* - 31 items
> kcm-* - 2 items
> kcm5_* - 12 items (unscalable, sad solution, it would be good if we do not
> have kcm5_, kcm6_ and kcm7_ at once one day)
> kcm* - 37 items
> *_kcm - 1 item
> *-kcm - 1 item

There were really no rules for naming. Many names come from very old times.

I disagree that kcm5_ is the wrong solution: I started using it to solve the 
conflicts between KCMs shipped with kde-runtime and KCMs shipped with Plasma: 
while Plasma 5 replaces Plasma 4, some modules moved from kde-runtime to 
Plasma, and kde-runtime can be co-installed with Plasma.

This may not be a problem anymore in the future, but I trust a bit my 
experience to be prepared for the worst (like open-ended co-installability 
time between things based on Qt 5 and Qt 6).

In fact we have the same issue with KIO slaves, which can be co-installed and 
will need to be co-installed for a while, in the transition times

So going forward there will be more kcm<number>_, and if we want to be 
pro-active, we could consistently start renaming them now (before Plasma 
5.14). We already use this pattern for a reason, and we must keep it at least 
for kio modules for sure.

Of course there should be no mix of different kcm<version> in the same 
translation branch. We need to ensure that "rename the catalog" should be part 
of the future "Frameworks 6 porting guide".

> 
> I'm amazed that the level of untranslated things is so low with such a
> diversity.

Then let's standardize.

Ciao
-- 
Luigi
[prev in list] [next in list] [prev in thread] [next in thread]