Re: Preparation for KF6, temporary stop of scripty on trunk/l10n-kf5

2023-03-05 Thread Luigi Toscano
Nicolas Fella ha scritto:
> Am 05.03.23 um 14:23 schrieb Luigi Toscano:
>> Karl Ove Hufthammer ha scritto:
>>> Why is kdelibs4support (with its > 3000 messages) included in the l10n-kf6
>>> branch?
>>>
>>> (And shouldn’t we have gotten rid of it a long time ago, when porting all 
>>> the
>>> applications to Frameworks 5?)
>>>
>> Good question: it seems it got a kf5 branch, but the master branch is still
>> around. But its i18n settings under sysadmin/repo-metadata are using the
>> default Frameworks value, so it looks like it's master branch should be
>> tracked by trunk_kf6.
>>
>> The question then (cc-ing kde-frameworks-devel) is: should we fix the 
>> metadata
>> for the porting aids? Should we clean the master branch for those?
> 
> It makes no sense to translate the master branch for:
> 
> - kdelibs4support
> 
> - kemoticons
> 
> - kinit
> 
> - kdesignerplugin
> 
> - kdewebkit
> 
> - khtml
> 
> - kjs
> 
> - kjsembed
> 
> - kmediaplayer
> 
> - kross
> 
> - kxmlrpcclient
> 
> as they won't be released any more with KF6.
> 
>> Should we clean the master branch for those?
> 
> This has been suggested in the past, and the answer seems to be
> "probably yes".

Thank you for the confirmation. I've fixed the i18n tracking information in
the reference location (sysadmin/repo-metadata) and removed the translations
of those modules from trunk/l10n-kf6.

Ciao
-- 
Luigi


Re: Preparation for KF6, temporary stop of scripty on trunk/l10n-kf5

2023-03-05 Thread Nicolas Fella

Am 05.03.23 um 14:23 schrieb Luigi Toscano:

Karl Ove Hufthammer ha scritto:

Luigi Toscano skreiv 02.03.2023 14:24:

it seems that after a bunch of fixes, the master branch of scripty was able to
deal with both trunk/l10n-kf5 and trunk/l10n-kf6. As announced, now
trunk/l10n-kf6 tracks the master branch of Frameworks and the master branch of
Plasma (most of the modules shipped with 5.26, the ones that have switched to
Qt6).
Everything now looks fine to me but please take a look should anything looks
odd.

Why is kdelibs4support (with its > 3000 messages) included in the l10n-kf6
branch?

(And shouldn’t we have gotten rid of it a long time ago, when porting all the
applications to Frameworks 5?)


Good question: it seems it got a kf5 branch, but the master branch is still
around. But its i18n settings under sysadmin/repo-metadata are using the
default Frameworks value, so it looks like it's master branch should be
tracked by trunk_kf6.

The question then (cc-ing kde-frameworks-devel) is: should we fix the metadata
for the porting aids? Should we clean the master branch for those?


It makes no sense to translate the master branch for:

- kdelibs4support

- kemoticons

- kinit

- kdesignerplugin

- kdewebkit

- khtml

- kjs

- kjsembed

- kmediaplayer

- kross

- kxmlrpcclient

as they won't be released any more with KF6.

> Should we clean the master branch for those?

This has been suggested in the past, and the answer seems to be
"probably yes".

Cheers

Nico



Re: Preparation for KF6, temporary stop of scripty on trunk/l10n-kf5

2023-03-05 Thread Luigi Toscano
Karl Ove Hufthammer ha scritto:
> Luigi Toscano skreiv 02.03.2023 14:24:
>> it seems that after a bunch of fixes, the master branch of scripty was able 
>> to
>> deal with both trunk/l10n-kf5 and trunk/l10n-kf6. As announced, now
>> trunk/l10n-kf6 tracks the master branch of Frameworks and the master branch 
>> of
>> Plasma (most of the modules shipped with 5.26, the ones that have switched to
>> Qt6).
>> Everything now looks fine to me but please take a look should anything looks
>> odd.
> 
> Why is kdelibs4support (with its > 3000 messages) included in the l10n-kf6
> branch?
> 
> (And shouldn’t we have gotten rid of it a long time ago, when porting all the
> applications to Frameworks 5?)
> 

Good question: it seems it got a kf5 branch, but the master branch is still
around. But its i18n settings under sysadmin/repo-metadata are using the
default Frameworks value, so it looks like it's master branch should be
tracked by trunk_kf6.

The question then (cc-ing kde-frameworks-devel) is: should we fix the metadata
for the porting aids? Should we clean the master branch for those?

Ciao
-- 
Luigi