davidedmundson added a comment.
> That's different: I see KCMs are libraries, > 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. I don't think so for two reasons. Firstly it's a single domain and we are plugins within another shell. Secondly, from QML our i18n calls go to klocalizedcontext which if a domain is set will explicitly use it. So in order to use KLocalizedString::setApplicationDomain we have to completely remove our d->_qmlObject->setTranslationDomain(aboutData()->componentName()); in configmodule.cpp I don't think that's viable, especially with the staggered release cycles. - I'd be happy to introduce a ConfigModule::setTranslationDomain in kdeclarative. Which would allow doing everything from code without having to make names match. 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
