• autocorrect: we need to find (separate issue) where those files should live (probably the last leftover from the kdelibs split)
• step files are probably not needed anymore, as the object info messages are now handled through po files (see step_objinfo_files.pot)

You're right about the step files, just removed them

kdeedu-data ktuberling khangman are blocked by sr magicly shared cmake file cmake_modules/srDataMacros.cmake

Any idea how to proceed with it?

kajongg only has german voices https://invent.kde.org/games/kajongg/-/merge_requests/2

I think we should remember to report all the authors in the commit messages when importing the content.

While extracting the commits and importing them with a full history would be the cleanest solution, maybe we can just list some details about the original svn commits ("imported from svn revision r... first added in r...") and list all the authors with lines like
Co-Authored-By: name <email>

Also, if there is just one author, maybe we could just commit the change using the proper authorship information.

I guess we need to continue with this. I was told LFS works on our repositories, so at least we could resume this when there are no other blockers.

In T13618#240765, @aacid wrote:

kdeedu-data ktuberling khangman are blocked by sr magicly shared cmake file cmake_modules/srDataMacros.cmake

Any idea how to proceed with it?

@ilic do you think we can find a way to untangle the dependency?

The only way i can think of is, make it more generic, make it not use perl and move it to ecm

But it's quite a lot of work :/

The original solution with srDataMacros was appropriate for the time of single language packs, but in this case (where various maintainers would have to deal with it directly, even if in ecm) I think it would cause too much confusion.

I propose that I locally statically resolve the data files for different sr@* variants, commit them (to both trunk and stable?), and then conversion can go on as usual.

That's also an option, simply remove the need for it 👍

Done! (trunk r1592930, branch r1592931)

I've removed the kturtle data, it was all for a very old version of kturtle, the new version of kturtle doesn't support those data files

khangman at https://invent.kde.org/education/khangman/-/merge_requests/12

autocorrect is a PAIN because it's used by both pimcommon and calligra, so were do we put it? Currently we're not putting it anywhere so it's not being even used ^_^

kdeedu-data https://invent.kde.org/education/kdeedu-data/-/merge_requests/4

klettres https://invent.kde.org/education/klettres/-/merge_requests/11

lokalize https://invent.kde.org/sdk/lokalize/-/merge_requests/23

https://invent.kde.org/education/kstars/-/merge_requests/763

@aacid, I see that khangman is marked as ‘done’, but I can’t find the .kvtml files (e.g., for language ‘nn’) in the khangman Git repository. Only the .txt file containing the list of extra characters in the alphabet has been added. Are the .kvtml files stored somewhere else?

khangman did not have any kvtml file

https://websvn.kde.org/trunk/l10n-kf5/nn/data/khangman/khangman/?pathrev=1605218

You probably mean the kvtml files of kdeedu-data

https://websvn.kde.org/trunk/l10n-kf5/nn/data/kdeedu-data/kdeedu-data/?pathrev=1605218

Those have been moved to kdeedu-data

https://invent.kde.org/education/kdeedu-data/-/tree/master/data/kvtml

ktuberling https://invent.kde.org/games/ktuberling/commit/63fe5cb74b47e7a1a299ab11cd910cea5013c7f6

autocorrect moved to calligra were at least it's being used https://invent.kde.org/office/calligra/commit/c6c6c899a3b640555df551d96d0668bb16ae0042

the pimcommon code is broken, will send emails about it