Handling of frameworks using Qt-based translations

[Aleix Pol]

On Tue, Mar 18, 2014 at 4:12 PM, Aurélien Gâteau <agateau at kde.org> wrote:

>  On Tue, Mar 18, 2014, at 6:20, Aleix Pol wrote:
>
> On Tue, Mar 18, 2014 at 2:05 PM, Aurélien Gâteau <agateau at kde.org> wrote:
>
>
> Hi,
>
>  I started working on how to handle Qt based translations, and make it as
>  simple as possible to work with for framework maintainers as well as
>  framework users.
>
>  I picked KBookmarks as my guinea pig and got to the point where
>  kbookmarkdialogtest shows a translated dialog.
>
>  Here is how it currently works. All of this is liberally inspired from
>  the way Trojita works:
>
>  # String extraction
>
>  I created a src/Messages.sh which contains the following:
>
>  lupdate -silent -recursive . -ts $podir/tmp.ts
>  lconvert $podir/tmp.ts --sort-contexts --output-format pot -o
>  $podir/kbookmarks5.pot
>  rm $podir/tmp.ts
>
>  # String compilation
>
>  I modified the toplevel CMakeLists.txt, adding these lines:
>
>  if (EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/po)
>      include(${CMAKE_CURRENT_SOURCE_DIR}/QmSupport.cmake)
>      qm_setup(kbookmarks5 po)
>  endif()
>
>  I created a QmSupport.cmake file, which exposes a qm_setup() function.
>  This function does three things:
>  1. Create a "qm" target which turns all .po into .qm files.
>
>  2. Call install(FILES...) on the generated qm files, installing them in
>  share/${name}/locale, where ${name} is the firt argument of qm_setup().
>
>  3. Generate a "${name}_translation.h" which contain two inline functions
>  to make it easy to load the translations.
>  Using the translation is then just a matter of including
>  ${name}_translation.h and calling ${name}_installTranslator(). If more
>  control is needed, ${name}_installTranslator() also accepts an optional
>  argument: the language. For even finer control, the .h also contains a
>  ${name}_createTranslator() function, which returns a QTranslator loaded
>  with strings for the right language.
>
>  # Questions
>
>  Does this approach sounds sane to you?
>
>  I think QmSupport.cmake should go to extra-cmake-modules. Any
>  objections?
>
>  Right now qm_setup() is very inflexible: it installs files and creates
>  the _translation.h file based on the name argument, meaning in my
>  example it creates share/kbookmarks5/locale/kbookmarks5_*.qm and
>  include/kbookmarks5_translation.h, which contains the functions
>  kbookmarks5_createTranslator and kbookmarks5_installTranslator.
>
>  I think we want to be able to customize the install dir of the
>  _translation.h file because some frameworks install header files in a
>  subdir, others do not.
>
>  Should we also be able to customize the install data dir for qm files,
>  as well as the prefix of the function names from _translation.h? I am
>  tempted to default to ${PROJECT_NAME} for the prefix of the function
>  names, its lowercase version for the install data dir and add an
>  optional PROJECT_NAME argument to qm_setup(). Opinions?
>
>  I am attaching the diff of the current state. I do not intend to commit
>  it as is since po files are not supposed to be in the framework
>  repository, but it should make it easy for you to try it if you are
>  interested.
>
>  Aurélien
>
> _______________________________________________
>  Kde-frameworks-devel mailing list
>  Kde-frameworks-devel at kde.org
>  https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>
>
>
>  Hi Aurélien,
> Wouldn't it make sense that the library called the createTranslation
> itself, instead of expecting the application to call it? I can easily see
> applications forgetting it.
> Maybe using Q_COREAPP_STARTUP_FUNCTION?
>
>
> That could work, but would remove the ability to change the language later
> (Some Qt apps like to let the user use a different language than the system
> one for some reason). Not sure we care about this. It certainly sounds more
> foolproof. On the other hand, you already *must* load translations yourself
> if you are using any Qt standard dialog, otherwise it won't be translated
> either.
>
> Aurélien
>
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


Well, for KI18n changing the language at run-time is not possible.

Maybe we can set it up magically for general use and still install the
createTranslation thing in case the application likes to do it specifically?

Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140318/12e3c23d/attachment.html>