> On Okt. 18, 2015, 8:49 vorm., Albert Astals Cid wrote:
> > Two more things:
> > * I think this should only be done if translators() is empty
> > * You should document this is going to fill in KAboutData::translators if
> > empty with those values
So what about this approach:
We just remove QCoreApplication::translate() from KAboutData::translators(),
and we add some comment to the documentation (doxygen) that tells that the
strings set by KAboutData::setTranslator() have to be already-translated, using
ki18nc or similar.
This way we would have one uniform interface for KAboutData: "everything that
goes in has to be translated before" and everything that comes out is
translated.
The complexity of the code would be reduced (I like simple solutions ;-) ) and
we introduce no new dependency.
The code that determines the translator names and their emails would then
shrink to two lines, like this:
const QString &translatorName = d->translatorName;
const QString &translatorEmail = d->translatorEmail;
- Thomas
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125682/#review87000
-----------------------------------------------------------
On Okt. 18, 2015, 2:13 vorm., Michael Pyne wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125682/
> -----------------------------------------------------------
>
> (Updated Okt. 18, 2015, 2:13 vorm.)
>
>
> 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
