Buttons like [OK] and [Cancel] are missing translation in Kate's OWN builds (Windows/macOS/Linux). But the DISTRO builds have them. This has been a common problem across all KDE official standalone packages since ever. Recently the Krita developers have solved the problem: https://bugs.kde.org/show_bug.cgi?id=395338 https://invent.kde.org/graphics/krita/commit/6ddad6502f3742c08ca89c3d1db36f331cf95e55 It's now working correctly in Krita's latest nighlies. Maybe we can use the same trick to fix Kate's too?
Created attachment 139369 [details] Kate missing translations of basic dialogue buttons (Simplified Chinese)
Created attachment 139370 [details] Kate missing translations of basic dialogue buttons (French)
Tested with Microsoft Store version, Windows 10 (21H1) X64 (Simplified Chinese).
Could you try a recent nightly build from https://binary-factory.kde.org/view/Windows%2064-bit/job/Kate_Release_win64/ We tried to ship the Qt translations now, too.
I tried the latest nightly builds, both Windows and appimage, but neither of them had the missing translations I mentioned.
Ok, thanks for testing, guess just bundling the qt translations is then not enough :(
I have looked at below the fix in Krita. Naturally we can "steal" that code, but that will e.g. not fix other KDE Gear applications we want to have as application bundles everywhere like Okular, .. Albert, have you some idea here about a more generic fix or who to ask?
I don't understand the question. Wasn't this already fixed in craft? Or you're saying that the fix isn't working?
Yes, the fix seems not to work, e.g. just bundling the qt translations doesn't seem to do the trick. Look below for what Krita does, seems weird that one needs to special handle this in the application code.
(In reply to Christoph Cullmann from comment #9) > Yes, the fix seems not to work, e.g. just bundling the qt translations > doesn't seem to do the trick. Look below for what Krita does, seems weird > that one needs to special handle this in the application code. k18n loads the qt catalog and that chain loads the rest of qtbase, etc. catalogs https://invent.kde.org/frameworks/ki18n/-/blob/master/src/main.cpp#L16 My only guess is that QLibraryInfo::location(QLibraryInfo::TranslationsPath) is not returning the same path of wherever the translations are being installed and thus it's failing.
You are right, I think the packaging for translations is just not correct in craft. At least if I understand e.g. https://doc.qt.io/qt-5/qt-conf.html correctly, the default search path is "translations" relative to the application binary, but we package "translations" toplevel, not inside the bin dir. Perhaps I am wrong here, let's ask Hannah.
Hi, I tried that now: if I move the "translations" folder to the bin dir, for me all is "consistent". I am just too dumb to find the right place to alter that in craft. Hannah, have you some pointers?
Started to work on some solution by creating a qt.conf https://invent.kde.org/packaging/craft/-/merge_requests/44
*** Bug 415272 has been marked as a duplicate of this bug. ***
For what it's worth, the gpg4win installer (which includes Kleopatra) installs all translations in "$INSTDIR\bin\translations". So putting the translations there seems to be the most sensible solution for Windows builds. For the AppImage of Kleopatra the linuxdeploy tool puts the translations into [.../AppDir]/usr/translations. One problem with this was that linuxdeploy only included the translations of Qt libraries that are actually used, but that the qt.qm meta translation file also included .qm files of unused Qt libraries. This made the loading of qt.qm fail, so that all Qt translations were missing even though all needed qt_foo.qm files were there. I have fixed this problem with https://invent.kde.org/frameworks/ki18n/-/commit/98e9a57b677441fd2efa2c2c17993ab7622bb275. I have just tested this with the latest Kate Release AppImage. The Qt translations seems to work now.
A possibly relevant merge request was started @ https://invent.kde.org/packaging/craft/-/merge_requests/84
A possibly relevant merge request was started @ https://invent.kde.org/packaging/craft-blueprints-kde/-/merge_requests/447
Git commit 2df2d52229f14db93f97011dcacf52368e8ab621 by Ingo Klöcker, on behalf of Ingo Klöcker. Committed on 09/09/2022 at 15:28. Pushed by kloecker into branch 'master'. On Windows, Qt expects translations files below bin Therefore, on Windows, we move the translations folder below the bin folder (similar as for the plugins and qml folders). M +11 -6 bin/Packager/CollectionPackagerBase.py M +2 -0 bin/options.py https://invent.kde.org/packaging/craft/commit/2df2d52229f14db93f97011dcacf52368e8ab621
The fix is wrong.
A possibly relevant merge request was started @ https://invent.kde.org/packaging/craft/-/merge_requests/85
Git commit 1b1a881711b0db1569517f65ddeec7fc153f31cd by Ingo Klöcker, on behalf of Ingo Klöcker. Committed on 12/09/2022 at 13:07. Pushed by vonreth into branch 'master'. Fix moving of translations folder into bin folder I misunderstood what is done for the plugins and the qml files. We need to move the translations folder into the bin folder, so that the *.qm files end up in bin/translations. The previous change moved the *.qm files into the bin folder which is wrong. M +7 -3 bin/Packager/CollectionPackagerBase.py https://invent.kde.org/packaging/craft/commit/1b1a881711b0db1569517f65ddeec7fc153f31cd
If the user has configured a different language than the system language for Kate, then the problem could most likely still be experienced (see bug 464694). This remaining issue has now been fixed, so that also this bug should now really be fixed (if kate uses the upcoming KF5 1.104).