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

Nicolas Fella nicolas.fella at gmx.de
Sun Mar 5 14:42:04 GMT 2023


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



More information about the kde-i18n-doc mailing list