----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125682/#review87108 -----------------------------------------------------------
Though I made the suggested changes I'm now worried we might need API changes in KAboutData to do this properly... it seems to me that KAboutData::applicationData() is improperly specified to return a copy of KAboutData instead of a reference to it. In this case if we update the list of translators it would be wiped out as soon as KMainWindowPrivate::init() exits its scope. I couldn't find any find shared pointer usage in KAboutData that would make value semantics work like a ref here, so unless I'm missing something I might have to think of something else. Will need to see with a test case in kcoreaddons I guess. :) - Michael Pyne On Oct. 20, 2015, 2:36 a.m., Michael Pyne wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125682/ > ----------------------------------------------------------- > > (Updated Oct. 20, 2015, 2:36 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.h 11dcfca > 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
