Investigating missing translations in Krita/other KDE-built binaries

[Tyson Tan]

Hi Halla,

The following translation files you mentioned:
./bin/locale/ru/LC_MESSAGES/kconfig5_qt.qm
./bin/locale/ru/LC_MESSAGES/kitemviews5_qt.qm
./bin/locale/ru/LC_MESSAGES/kwindowsystem5_qt.qm
./bin/locale/ru/LC_MESSAGES/kcoreaddons5_qt.qm
./bin/locale/ru/LC_MESSAGES/kcompletion5_qt.qm
./bin/locale/ru/LC_MESSAGES/kwidgetsaddons5_qt.qm
./bin/locale/ru/LC_MESSAGES/seexpr2_qt.qm

I have already 100% translated and verified all of them before Krita 
4.4.2, as part of my investigation, but none of them showed up in 4.4.2. 
The Seexpr interface part inside of Krita.pot works, but not the stuff 
inside of the library that holds the majority of its options. I don't 
think any of them gets loaded.

However, this one:
kio-extras._desktop_.pot

Although you mentioned it wasn't shipped, I think it was shipped 
somehow? In Krita's Save dialogue, the file type "Krita Document" has no 
entry inside of Krita.pot. The only place I could find across all KDE 
pots was inside of kio-extras, and the translation, although currently 
not reflecting the last-minute changes I've just made, is definitely 
loaded in our official binaries. Or maybe it was used a a building 
dependency only?

It should be noted that although not being a frameworks component, 
seexpr2_qt.pot was not loaded for Krita. While marble_qt.pot, which is 
also not a frameworks component, was correctly loaded for digikam. 
digikam also loaded kxmlgui, but not kwidgetsaddons, which are both 
frameworks libraries. I can't seem to find a pattern.

Tyson Tan

On 2021-01-25 21:15, Halla Rempt wrote:
> On Monday, 25 January 2021 14:00:03 CET Halla Rempt wrote:
> 
>> One problem seems to be that .qm translations are loaded in a 
>> different way from .mo translations. KDE's translation framework is 
>> built on gettext, Qt's is homegrown, and I haven't figured out how to 
>> harmonize the two systems on all platforms, in the case where the 
>> application language is the same as the platform language, and the 
>> case where a different language is chosen.
>> 
> 
> And it looks like ki18n only tries to load Qt's translations, and
> might handle the location of those translations the wrong way. I'm not
> sure the frameworks translations are actually loaded.