Kross support removed from Lokalize in https://commits.kde.org/lokalize/a0dc91ddc032485f850bc8fd5333e5a8a58024b6.

This seems obsolete.

Yes, I believe the approach with running-and-forgetting the interpreter binary should work for "opensrc" to some extent. One trouble I see though is, it's harder to enforce system requirements to have some GUI in Python to provide feedback for the user, for example if something goes wrong.

One Lokalize script that I personally used for a while was https://invent.kde.org/sysadmin/l10n-scripty/-/blob/master/lokalize/opensrc.py. I actually ported Kross to KF5 because I wanted that specific script to work again. OTOH I hadn't been translating (and therefore using Lokalize) much lately.

Two big questions:

1. What is the chance this gets implemented & released in KF5, before KF6 is ready?
2. Would the languages/locales' dataset be sufficient to replace the list of KDE languages currently hardcoded in KF5::KConfigWidgets? See thread for more background, please consider the case of en_GB.

Random thoughts:

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.

In T13514#237699, @aacid wrote:

"Git should facilitate integration with external translation file trees maintained by Linux distributions (e.g. BaseALT)"
Let me rephrase this for you: "We're doing things wrong, can you please change your upstream behaviour so it's less painful for us to do things wrong?"

Migration to Git is over, abandoning this patch.

Roughly the same was done in https://invent.kde.org/sysadmin/l10n-scripty/-/commit/6bad01a4aea8cb4c43ba57a904c1c882ebc4fbe9 , abandoning this patch.

ping?

I'm assuming we're waiting for Luigi to adapt makemessages and kick start the migration process. @ltoscano, is there anything I can help with to get the Git migration done sooner?

Shall we discuss how the system is going to handle multiple translation branches (e.g. trunk/l10n-kf5, branches/stable/l10n-kf5, ...) ?

@nalvarez, could you please update on the status of this ticket? Are you blocked on something? Do you need help?

In T13514#237629, @pino wrote:

Git should facilitate integration with external translation file trees maintained by Linux distributions (e.g. BaseALT)

@aspotashev can you please explain why these distros care about the layout of our translations? When packaging upstream releases they ought to use translations as available in release tarballs, not pick random files from upstream translation trees.

In T13514#237618, @ltoscano wrote:

In T13514#237617, @aspotashev wrote:

I'm not sure what you mean here, can you please elaborate? The tooling to simplify moving of translations between directories is part of step #4 of the roadmap. Something like super-duper-tool mv kscreenshot/kscreenshot.po spectacle/spectable.po would create a commit in each of the Git translations repositories and git push all of them, possibly retrying this operation in a case of a merge conflict.

I don't want to have a tool to push things in all repositories first without reducing the number of occurrences when this can happen. Also, summit should get that support first.

In T13514#237610, @ltoscano wrote:

The points can be dune until the moving of translations is not automated. Otherwise having to do the operations on a set of per-languages git repositories will be impossible.

Ping?

Thanks!

ping?

FWIW, kde-ruleset.git is also missing COPYING files and license headers.

In D25929#656114, @nalvarez wrote:

I think you should commit this as-is and we can do changes later directly in kde-ruleset.

Feel free to mark https://bugs.kde.org/show_bug.cgi?id=416940 fixed as soon as this patch is submitted. You can add a line "BUG: 416940" to the commit message to have the ticket closed automatically on git push.

Why CTR and not GCM (https://en.wikipedia.org/wiki/Galois/Counter_Mode)?

To clarify: I identified that we can't just migrate to Git and remove the scripty source code from SVN without changing makemessages. Migration can be done as follows:

I think I need to explicitly specify license for these new files. Not sure which license to choose, by default I would pick MIT because it's one of the most permissive ones.

In D26076#627394, @aacid wrote:

Just to be sure, this needs https://phabricator.kde.org/D25929 (or rather the repo resulting from it), right?

As I mentioned in https://phabricator.kde.org/T4803#213612 , I ran svn2git with these rules in December to produce https://github.com/aspotashev/converted-scripty-v2 for evaluation.

ping?

Клик стоил около 20 рублей?

ping?

The migrated repo does not include scripts from */x-test/internal/, is that OK?

In D26168#581665, @kossebau wrote:

Seems you went fully "at it", good work :)

"after string freeze" meant "after relase tagging for string freeze reasons" , right? ;)

will try to push around January 5, 2020 after string freeze

will try to push around January 5, 2020 after string freeze

In D26168#581637, @kossebau wrote:

Looks good to me for what I know as programmer, but none-translator :)
While at it, for consistency the other tab titles could also get a "@title:tab" UI marker context?