I moved this patch to GitLab: https://invent.kde.org/sdk/lokalize/-/merge_requests/60

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

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

khangman did not have any kvtml file

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

@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?

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

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

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

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

Thanks for opening that request against Lokalize to plug into Weblate's existing API. A workflow that uses Weblate to remove the need to deal with git/svn to encourage contributions from non-Computer Science types while still allowing for those who have used Lokalize to continue using Lokalize is the best way forward I feel.

I agree it could be a good solution but I'm looking at it from a different angle.

Online tools generally slow down high-volume translators. Plus, they are slow, and require an internet connection. Downloading and uploading translations are always a hassle, and error-prone.

Would someone (@ltoscano ?) be able to give a short status update on this at Akademy? Where discussion/work/testing is required?

Last activity here was a year ago, has there been any further thoughts or updates on this?

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 ^_^

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

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

@cblack Thank you so much, it was a kind offer but I don't want to increase the amount of workload on you. Thank you!
@aacid We can try and make some automation for approved strings but I can't estimate the effort required for SVN.

Well, this tangent is kinda moot now since some chatting & it's probably not going to work out having Hebrew team work on the instance I set up for the Toki Pona team.

That's probably acceptable but I am going to maybe wrongly assume you don't also speak Hebrew?

I'm going to warn you against that, you can't create a system to automatically commit things from other people into KDE servers without human interaction, that's basically giving out your user for anyone else to [ab]use, and that's obviously not allowed.

@aacid That's maybe relevant to pootle, in Weblate there's an ACL and a string approval system.

I'm going to warn you against that, you can't create a system to automatically commit things from other people into KDE servers without human interaction, that's basically giving out your user for anyone else to [ab]use, and that's obviously not allowed.

Could we chat on a more real-time platform to hash out the details of that? My matrix is @pontaoski:kde.org and Telegram is https://t.me/pontaoski

@cblack Yes, I'd love that.

You want to use the Weblate instance set up for the Toki Poka team for the Hebrew localisation?

Sorry, I don't understand what you're trying to say here.

@cblack What will it take to simply join them?

@cblack What will it take to simply join them?

Another data point: the toki pona team uses a Weblate instance working directly against the SVN. Works fine, other than the fiddling of the internal checkout Weblate uses required to prevent it from dying on how many files we have in its "scanning" phase.

The website has been refreshed and is ready to be extracted by Scripty.

In T13514#248309, @aspotashev wrote:

Btw I've started slowly rewriting scripty in Go because

• I like Go more than bash.
• It's easier to make it more configurable than in the current state with a set of scripts calling each other. We need configurability to share codebase across branches and to let users run parts of scripty end-to-end (will be useful for www that needs more frequent syncs).
• it's easier to parallelize things in Go, so we could shorten the running time.
  
  I didn't share my code yet. Don't expect fast progress, maybe I'll be able to release something by May 2021.

Just in case, this is the thing I'm working on, but it's still heavily WIP, especially the injector interface (something is already working with the example legacy extractor):
https://invent.kde.org/ltoscano/noktra/

Done! (trunk r1592930, branch r1592931)

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

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.

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