[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    D12982: Make the new KCMs with QtQuick translatable
From:       David Edmundson <noreply () phabricator ! kde ! org>
Date:       2018-05-30 21:01:09
Message-ID: 20180530210109.1.F60C9F88BA10DAE5 () phabricator ! kde ! org
[Download RAW message or body]

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


[Attachment #3 (unknown)]

<table><tr><td style="">davidedmundson added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: \
right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: \
#F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: \
inline-block; border: 1px solid rgba(71,87,120,.2);" \
href="https://phabricator.kde.org/D12982">View Revision</a></tr></table><br \
/><div><div><blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; \
font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: \
#f8f9fc;"><p>That&#039;s different: I see KCMs are libraries,</p></blockquote>



<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: \
italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>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.</p></blockquote>

<p>I don&#039;t think so for two reasons. Firstly it&#039;s a single domain and we \
are plugins within another shell.</p>

<p>Secondly, from QML our i18n calls go to klocalizedcontext which if a domain is set \
will explicitly use it. So in order to use</p>

<p>KLocalizedString::setApplicationDomain we have to completely remove our</p>

<p>d-&gt;_qmlObject-&gt;setTranslationDomain(aboutData()-&gt;componentName()); in \
configmodule.cpp</p>

<p>I don&#039;t think that&#039;s viable, especially with the staggered release \
cycles.</p>

<ul class="remarkup-list">
<li class="remarkup-list-item"></li>
</ul>

<p>I&#039;d be happy to introduce a ConfigModule::setTranslationDomain in \
kdeclarative. <br /> Which would allow doing everything from code without having to \
make names match.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R119 \
Plasma Desktop</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a \
href="https://phabricator.kde.org/D12982">https://phabricator.kde.org/D12982</a></div></div><br \
/><div><strong>To: </strong>yurchor, Plasma, kde-i18n-doc, ltoscano, \
davidedmundson<br /><strong>Cc: </strong>davidedmundson, mart, hein, aacid, ltoscano, \
plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, \
abetts, sebas, apol<br /></div>



[prev in list] [next in list] [prev in thread] [next in thread]