Can we move kf5_entry.desktop files into kconfigwidgets.git?

[Luigi Toscano]

Alexander Potashev ha scritto:
> Hi Luigi,
> 
> Thanks for the link! While this is a great initiative to deduplicate
> code, I didn't find any specific proposal for how it would replace
> kf5_entry in kconfigwidgets. And if we were to indeed get rid of
> k5_entry in favor of iso-codes, it's going to be tricky: there's no
> 1:1 mapping of KDE localizations to ISO 639 languages, for example:
>  * en_GB is not listed in iso-codes,
>  * The 4 variants of Serbian l10n found in KDE don't have respective 4
> entries in iso-codes.
> 
> The KLocale update also seems to be a plan for KF6. Assuming this is
> the case, we'd need to keep and maintain kf5_entry files [next to .po
> files] for KF5 for another 3-5 years. I would like it better if this
> migration completes in 1 year rather than in 3-5 years.

I think the plan is to introduce it as soon as possible even in KF5 to easy
the porting. Ping Volker for more details.

> 
> 
> The licensing issue is a good point, however I believe the file move I
> proposed in my first email has no effect on licensing because
>  1. The same kf5_entry files are already being copied into the Git
> repo every month as part of the release process, see e.g.
> https://invent.kde.org/frameworks/kconfigwidgets/-/tree/v5.85.0/po/ru
>  2. Similarly, the same kf5_entry files are shipped in release
> tarballs, also once a month.
> That said, the licensing problem you're likely referring to already
> exists and it will not become worse if we move the kf5_entry files'
> source-of-truth from SVN to Git.

That's not relevant. The point is that everything will end up in the same
kconfigwidgets._desktop_ file and unless you want to lose the old messages
that would mean merging, but that's complicated.


> 
> I think the kf5_entry move and fixing the licensing problem are two
> separate pieces of work that can be done independently, in no
> particular order, IOW the licensing problem is not blocking the file
> move. WDYT?
> 


I don't agree they are separate, unless we add a special rule to extract those
messages in a separate po file. That would defeat part of the simplification,
but at least would removes some translatable artifacts from svn.


-- 
Luigi