| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | None | T11545 Remove Kross | ||
| Open | None | T11613 Port lokalize away from Kross |
I guess this is more tricky, considering that here python files are used. Copy/Pasting whatever Krita uses could be an option :D
I think importing cross and the interpreter would be really ugly and that is a ton of code.
Also there seems to be made use of the cross forms. Not sure if one would be better off using the Qt python bindings to create GUIs.
Though this means one would need to port the scripts themselves and keep the Kross stuff for compat if translators have custom scripts. Not sure if this is the case.
@aspotashev vkrause Any thoughts?
I have no idea about those features in Lokalize, but maybe it's worth asking on the i18n lists for all the scripts in use right now? That should allow us to reach a large part of the userbase, and might give us a better idea on how big that problem really is.
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.
Assuming Kross won't be included in KF6 and I somehow want to have the open-source-file functionality again in KF6-based Lokalize, I would probably consider one of these options:
- Reimplement the open-source-file functionality in Lokalize in a compiled language, IOW without scripting
- Revive Kross, put it somewhere in the KDE Playground and make it a soft dependency (this seems painful, so it's a less likely solution.)
Can't comment on others' preferences since no one proactively asked me about the opensrc.py script. I can only confirm 1 other person on the Russian team has tried it.
@aspotashev Thanks for the reply!
When looking at the code I see the line (path, pofilename)=os.path.split(Editor.currentFile()). Besides that there does not seem to be much usage of the Editor or Lokalize module.
Considering that we only read the filename there could we not just call the script as a QProcess? See my sugestion of an external tools like mechanism in the mail.
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.
In the meantime I've just found https://bugs.kde.org/show_bug.cgi?id=437772 - oopsie :P
In the meantime I've just found https://bugs.kde.org/show_bug.cgi?id=437772 - oopsie :P
Seems like a clear indication that Kross is no longer actively developed and porting away from it is the right thing;)
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.
I am wondering if one should then just use KDialog from the python script and mark it as a runtime dependency.
@aspotashev Though your example shows that there are scripts used which are not shipped as part of lokalize.
TBH I am not sure how to proceed on this task, on the ML thread (https://mail.kde.org/pipermail/kde-i18n-doc//2021-August/000659) was not any comment.
If course one could interpret no comment as having no usecase for the scripting..
Kross support removed from Lokalize in https://commits.kde.org/lokalize/a0dc91ddc032485f850bc8fd5333e5a8a58024b6.