ltoscano added a comment.
In D12982#270846 <https://phabricator.kde.org/D12982#270846>, @davidedmundson wrote: > > is this something that needs to be fixed in kdeclarative > > I don't think so. > This patch seems fine, it's no different to our current state of how applet translations work following a fixed pot schema. That's different: I see KCMs are libraries, but they introduce an exception in the way the translation domain is defined for a library. And even for applets I would argue that the case may be needed, but let's move it. Applet won't need to co-exist, KCMs may need to do it. > > >> would a patch to fix this (define the translation domain in the same way as the other libraries, not related to component name) accepted? > > Accepted, sure. But the QtQuick loading is quite separate from the library here, so I'm not sure it's easy. I think it would be acceptable to use KLocalizedString::setApplicationDomain, even if introduces an exception, but at least not *another* way to set the translation domain. Would that work/be easier to implement for this dynamic setting? > If we want to have QtQuick only KCMs (something I think probably isn't useful, but I know Marco wants) we would still need to load pots based on plugin metadata names like it is currently. I still think that there is a use case for translation domain unrelated to metadata (if you mean static KAboutData settings). REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D12982 To: yurchor, #plasma, kde-i18n-doc, ltoscano, davidedmundson Cc: davidedmundson, mart, hein, aacid, ltoscano, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol
