Current extraction and applying translations are broken.
Patch mostly by Victor Ryzhykh.
No Linters Available |
No Unit Test Coverage |
Buildable 26064 | |
Build 26082: arc lint + arc unit |
kcmkwin/kwinrules/Messages.sh | ||
---|---|---|
2 ↗ | (On Diff #81482) | If we rename the pot file to kcm_kwinrules.pot and adjust TRANSLATION_DOMAIN in CMakeLists.txt, will we still need to use i18nd? |
kcmkwin/kwinrules/Messages.sh | ||
---|---|---|
2 ↗ | (On Diff #81482) | TRANSLATION_DOMAIN is a C/C++ define, it does not apply to strings in QML files. |
kcmkwin/kwinrules/Messages.sh | ||
---|---|---|
2 ↗ | (On Diff #81482) | Could someone explain why we don't need to use i18nd in Destop Effects or Virtual Desktops KCM? |
I bet the KAboutData in the KCM c++ is wrong. The component name determines the translation domain to be used on the KCM QML side.
Some time ago I asked if it was a way to have the QML-based KCMs use the same way for setting the translation domain as the C++ ones. This is also needed for all KCMs defined outside Plasma, because technically they should be called kcm5_<foo> to prevent co-installability issues (with kdelibs 4.x back then, with the KF6 ones in a few months). Would it be possible to revisit this point? We are going to have installation conflicts when KF6 is out otherwise.
Would it be possible to revisit this point? We are going to have installation conflicts when KF6 is out otherwise.
Feel free to add a task to the allmighty KF6 board https://phabricator.kde.org/tag/kf6/
Added T13056, even though it is not KF6-specific (but I guess it would be easier to implement it directly there).
Set the value to "auto about = new KAboutData(QStringLiteral("kcmkwinrules"),"
Got such an error.
If you rename it to “kcm_kwinrules” with the attached patch, then the translation works.
Now my packages are going to check.
Yes, renaming to “kcm_kwinrules” corrects the display of the translation.
No, not everywhere translation works.
It took one more patch to the previous one.
After
So what is the resolution? What should I do with this?
Thanks in advance for your advice.
kcmkwin/kwinrules/Messages.sh | ||
---|---|---|
2 ↗ | (On Diff #81482) | It all comes from configmodule.cpp in kdeclarative QQuickItem *ConfigModule::mainUi() d->_qmlObject->setTranslationDomain(aboutData()->componentName()); If this is set then anything loaded within this QML Context will have the right domain.
So as Vlad says from what I can tell if this pot is renamed it should magically start working without i18nd. |
KAboutData is used for translation context and for finding the plug-in. Make sure to update the install location in kpackage5/ in CMake when changing it
This cannot be easily merged anymore (files were changed meanwhile) so I prefer to abandon this revision.
@broulik Can you fix it if you know how to do this please?
Maybe I should make a new patch?
Today I planned to build kwin with this commit https://cgit.kde.org/kwin.git/commit/?id=1a3cb256d74166ba175f4634904abea84928b635
Although you can wait with this.:)
Whatever you want.
Personally, I think that the whole system is wrong. Every single release someone break the translation of KCM, there is no conventional naming, conventional style, and written rules. Just a prediction: the next release of Plasma will have broken KCMs too.
It will not be accepted because it uses i18nd(). @broulik wants this problem to be resolved on KAboutData/CMakeLists.txt level.
Just please patch Messages.sh to rename the file, I will take care of moving it.
Regarding the more general issue of the name of the template, as I mentioned earlier, I created T13056 . It would be good if it was fixed before KF6 though.
It would be nice.
And when I tried this option, this error got out
Because you need to fix the damn location where the package is installed
I will not create additional differential revisions. I do not know what "kcmkwinrules" should be left and what should be replaced with "kcm_kwinrules" and cannot test by myself.
Dear Plasma developers, can you resolve this problem without incompetent translators?
I did with the patch from this post
https://phabricator.kde.org/D29270#659987
At first I was pleased that everything was translated.
Then I saw an error in setting the window title, and made another patch, which is here https://phabricator.kde.org/D29270#660131