D5439: API dox: more info about KAboutData's orgDomain/desktopFileName properties

Friedrich W. H. Kossebau noreply at phabricator.kde.org
Sat Apr 15 03:00:06 UTC 2017


kossebau added a comment.


  In https://phabricator.kde.org/D5439#102241, @mpyne wrote:
  
  > Is there any reason why we cannot just do the needed `setlocale(LC_ALL, "")` within ki18n itself (e.g. in the `KLocalizedStringPrivateStatics` ctor which is used to support translation of `i18n` calls?  `QCoreApplication` is going to do this anyways so making it happen earlier at runtime seems like what we want.
  
  
  Thought about this as well before, reasons against it that came into my mind though:
  
  1. ki18n is a util library, not so nice in general by libraries to decide on central settings which affect the complete process and also at random times (whenever the first i18n call would be made), ideally is explicitely asked for by from the main program
  2. first point even more an issue as ki18n is also pulled in into plain Qt applications by the Plasma QPA plugin
  3. apps using the switch-language feature from the KHelpMenu need any i18n calls only done after the qapp instance is creatd, as that feature works by registering a hook-up with  Q_COREAPP_STARTUP_FUNCTION, to then set the custom selected language by setting the LANGUAGE environment variable (see https://cgit.kde.org/kxmlgui.git/tree/src/kswitchlanguagedialog_p.cpp).

REPOSITORY
  R244 KCoreAddons

REVISION DETAIL
  https://phabricator.kde.org/D5439

To: kossebau, #frameworks, stikonas, aacid, ltoscano, mpyne
Cc: dfaure
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20170415/2e3201f1/attachment.html>


More information about the Kde-frameworks-devel mailing list