----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125682/#review86998 -----------------------------------------------------------
src/kmainwindow.cpp (line 209) <https://git.reviewboard.kde.org/r/125682/#comment59815> This is not going to work, you need to undefine TRANSLATION_DOMAIN include klocalizedstring again and then call this i18nc so it gets it from the "global" (i.e. the app) catalog and not from the kxmlgui5 catalog - Albert Astals Cid On oct. 18, 2015, 2:13 a.m., Michael Pyne wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125682/ > ----------------------------------------------------------- > > (Updated oct. 18, 2015, 2:13 a.m.) > > > Review request for KDE Frameworks, Localization and Translation (l10n) and > Albert Astals Cid. > > > Bugs: 345320 > https://bugs.kde.org/show_bug.cgi?id=345320 > > > Repository: kxmlgui > > > Description > ------- > > KAboutData has a placeholder for information regarding who translated the > running KDE-based application (KAboutData::translators()). However it relies > on the application developer to call KAboutData::setTranslator() since > KCoreAddons (a Tier 1 framework) cannot use KI18n directly. Instead the Qt > translation infrastructure is used where translations are unavoidable, but > that is not compatible with KF5's i18n. This (IIUC) gives different behavior > than KDE4, where KAboutData could (and did!) directly pull the translated > list of translators, so application authors didn't have to do anything > special for their about dialog to have the list of translators. > > For the majority of our applications we can make the ::setTranslator() call > on the application developer's behalf, as recommended by Albert on > kdeframeworks-devel, and by doing so from KMainWindow (a relatively central > location for KF5-using applications) we can use KI18n and get the > accurately-translated message. Feeding the already-translated information > into KAboutData should work to form the list of translators for later use by > KAboutApplicationDialog, or other accessors of that information. > > This patch implements all that. I avoided using a global startup method as > suggested by Albert (since the Qt docs suggest that this startup would happen > *before* the GUI starts up, and I want to make sure KI18n is available); > KMainWindow seems the next best option, and even non-KXmlGuiWindow users > might use this. There are probably other good alternatives too (maybe even > the platform plugin?). > > > Diffs > ----- > > src/kmainwindow.cpp 7c86841 > > Diff: https://git.reviewboard.kde.org/r/125682/diff/ > > > Testing > ------- > > Compiled, apps all still work. > > I find it hard to test whether the translators actually show up or not > though, as I do not use translated KF5 apps. > > > Thanks, > > Michael Pyne > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
