This is only covering an underlying problem where KDeclarative fails to set the translation context on QQmlContext as the engines are shared and it then refuses to set anything on the "internal context". But since I haven't found a solution, perhaps this is better than having non-translated UI

In D16595#352466, @broulik wrote:

This is only covering an underlying problem where KDeclarative fails to set the translation context on QQmlContext as the engines are shared and it then refuses to set anything on the "internal context". But since I haven't found a solution, perhaps this is better than having non-translated UI

Where in kdeclarative/plasma-framework are you trying to set the translation context?

I had a quick look without knowing anything about the architecture and it seems ConfigViewPrivate::init would be the place, but there's nothing there. Or you mean you tried and it didn't work and that's why the code isn't there?

Anyhow the thing is, it can't work, you're using this code "as a library", and what you have to do in library code is hardcode the translation domain since there can only be one "default domain" and obviously that's the applet here and not the kcm (which acts as a library).

The thing is that most of the times in library C++ code we don't see ourselves hardcoding the domain via i18nd calls because we use the -DTRANSLATION_DOMAIN trick to do it for us, but since QML isn't compiled we can't have anything that, so for QML that can show in various processes we need to use i18nd.

We use everything in Plasma "as a library", that's why KDeclarative::QmlObject sets a translation context on the root context, so that plasmoids, wallpaper plugins, and other QML bits can use i18n with no translation domain (only exception really being the look and feel packages). I'm too tired to explain right now but note when you run the KCM from within Plasma you get a warning like:

QQmlContext: Cannot set context object for internal context.
QQmlContext: Cannot set property on internal context.

That is what breaks the translations in this case and used to work until we shared QQmlEngines between the KCM and the window around it. However, if we don't then the KCM uses the Plasma Qt Quick Controls style which is also undesirable. We also don't want separate QQmlEngines as then you run into bugs and crashes since we would have objects (e.g. context properties and singletons) between engines and they clean up each other's stuff and crash.

Ok, understood, there's a plan to maybe make it work but isn't really working.

Can i commit this today so it gets in Plasma 5.14.3 and our users get to understand the UI?

ping?