From kde-i18n-doc Thu Oct 22 00:31:33 2015 From: "Michael Pyne" Date: Thu, 22 Oct 2015 00:31:33 +0000 To: kde-i18n-doc Subject: Re: Review Request 125682: Pre-fill translator information for KAboutApplicationDialog Message-Id: <20151022003133.14267.23528 () mimi ! kde ! org> X-MARC-Message: https://marc.info/?l=kde-i18n-doc&m=144547392806388 --===============6818669669213172545== MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125682/ ----------------------------------------------------------- (Updated Oct. 22, 2015, 12:31 a.m.) Status ------ This change has been marked as submitted. Review request for KDE Frameworks, Localization and Translation (l10n) and Albert Astals Cid. Changes ------- Submitted with commit e4d10c796ae8a3a7ecc6e7a338d6126259fa2583 by Michael Pyne to branch master. 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 --===============6818669669213172545== MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit
This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125682/

This change has been marked as submitted.

Review request for KDE Frameworks, Localization and Translation (l10n) and Albert Astals Cid.
By Michael Pyne.

Updated Oct. 22, 2015, 12:31 a.m.

Changes

Submitted with commit e4d10c796ae8a3a7ecc6e7a338d6126259fa2583 by Michael Pyne to branch master.
Bugs: 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?).

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.

Diffs

  • src/kmainwindow.h (11dcfca)
  • src/kmainwindow.cpp (7c86841)

View Diff
--===============6818669669213172545==--