D12982: Make the new KCMs with QtQuick translatable

[Luigi Toscano]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20180530/a358a856/attachment.html>