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