This problem exist on Gentoo. Build test Qt-application: #include <QtGui> int main(int argc, char *argv[]) { QApplication a(argc, argv); bool ok; QFileDialog::getExistingDirectory(); QColorDialog::getColor (); QFontDialog::getFont(&ok); QTimer::singleShot(1000, QApplication::instance(), SLOT(quit())); return a.exec(); } and run in KDE environment. Reproducible: Always Steps to Reproduce: Build test Qt-application: #include <QtGui> int main(int argc, char *argv[]) { QApplication a(argc, argv); bool ok; QFileDialog::getExistingDirectory(); QColorDialog::getColor (); QFontDialog::getFont(&ok); QTimer::singleShot(1000, QApplication::instance(), SLOT(quit())); return a.exec(); } and run in KDE environment with not default locale (ru_RU.UTF-8 in my case) Actual Results: Dialogs are not localized. Expected Results: Dialogs are localized. In strace log we can see: access("/home/eegorov/.kde4/share/locale/ru/LC_MESSAGES/kfilemodule.mo", R_OK) = -1 ENOENT (No such file or directory) access("/usr/share/locale/ru/LC_MESSAGES/kfilemodule.mo", R_OK) = -1 ENOENT (No such file or directory) access("/home/eegorov/.kde4/share/locale/ru_RU/LC_MESSAGES/kfilemodule.mo", R_OK) = -1 ENOENT (No such file or directory) access("/usr/share/locale/ru_RU/LC_MESSAGES/kfilemodule.mo", R_OK) = -1 ENOENT (No such file or directory) access("/home/eegorov/.kde4/share/locale/ru/LC_MESSAGES/kfilemodule.mo", R_OK) = -1 ENOENT (No such file or directory) access("/usr/share/locale/ru/LC_MESSAGES/kfilemodule.mo", R_OK) = -1 ENOENT (No such file or directory) access("/home/eegorov/.kde4/share/locale/ru_RU/LC_MESSAGES/kfilemodule.mo", R_OK) = -1 ENOENT (No such file or directory) access("/usr/share/locale/ru_RU/LC_MESSAGES/kfilemodule.mo", R_OK) = -1 ENOENT (No such file or directory) access("/home/eegorov/.kde4/share/locale/ru/LC_MESSAGES/kfilemodule.mo", R_OK) = -1 ENOENT (No such file or directory) access("/usr/share/locale/ru/LC_MESSAGES/kfilemodule.mo", R_OK) = -1 ENOENT (No such file or directory) access("/home/eegorov/.kde4/share/locale/en_US/LC_MESSAGES/kdelibs4.mo", R_OK) = -1 ENOENT (No such file or directory) => workaround: mkdir -p ~/.kde4/share/locale/ru/LC_MESSAGES/ cd ~/.kde4/share/locale/ru/LC_MESSAGES/ ln -s /usr/share/locale/ru/LC_MESSAGES/kdialog.mo kfilemodule.mo After this all localized fine. Gentoo team closed downstream bug as upstream issue: https://bugs.gentoo.org/show_bug.cgi?id=480724
Are you saying your system locale is "ru_RU.utf8", or you changed it just for this test Qt application? I cannot reproduce your problem with neither of 1. KDE SC 4.12.5 on Gentoo Linux, 2. KDE SC 4.13.3 on Russian Fedora 20. On both systems your test application happily loads kio4.po with Russian translation and all three dialogs appear in Russian.
The problem you might have in older version of kdelibs must have been fixed in http://commits.kde.org/kdelibs/09d4d52dd9312bdd17ce71cc55df3ce3860de73d
* With kde 4.13 compiled from sources I have the file and font dialog fully and the color dialog partly translated (locale x-test + de) * the patch mentioned in Comment #2 does only make the kde file dialog translated and was introduced in kdelibs 4.12, therefore I do not understand why the reporter with kdelibs 4.13.2 has an untranslated file dialog. * I fail to see why kde is responsible to load the translations for QColorDialog and QFontDialog, this has to happen via loading the qt translations in the app using QColorDialog and QFontDialog * The file dialog is a different case, apparently the QFileDialog launches the native file dialog of the desktop environment (kde) via a xdg call. This way the catalog kio4 + kde system catalogs are pulled in and make the QColorDialog and QFontDialog in the test application by accident partly translated Summary from my pov: 1) Using QFileDialog from a qapplication in a kde desktop environment I have a translated dialog, this part of the bug is not reproducable here 2) Using QColorDialog and QFontDialog from a qapplication in a kde desktop environment it is not kde's responsibility to load the qt translations, this part of the bug report is invalid.
Yes, I hastened to publish a bug here after closing the downstream bug. The problem does not exist on the latest version. Excuse me.