Handling of frameworks using Qt-based translations

Thu Mar 20 14:06:58 UTC 2014

On Tue, Mar 18, 2014, at 9:49, Aurélien Gâteau wrote:

On Tue, Mar 18, 2014, at 9:07, Aleix Pol wrote:

On Tue, Mar 18, 2014 at 4:12 PM, Aurélien Gâteau <[1]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 <[2]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

[3]Kde-frameworks-devel at kde.org

[4]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

[5]Kde-frameworks-devel at kde.org

[6]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?

That is right. Let's keep it simple then and not provide a feature
which is not supported by KI18n-powered frameworks.

This means we need to add a generated .cpp file in the framework
target(s). Going to look into it.

Some feedback on this: using Q_COREAPP_STARTUP_FUNCTION works as
expected. I think I have something usable now. Adapting a Qt-translated
framework requires the following changes (using kbookmarks as example
again):

1. Create src/Messages.sh with the following content:

    rm -f $podir/tmp.ts

    lupdate -silent -recursive . -ts $podir/tmp.ts

    lconvert $podir/tmp.ts --sort-contexts --output-format pot -o
$podir/kbookmarks5.pot

    rm $podir/tmp.ts

Note: As much as possible of these lines should move to the l10n
scripts to reduce duplication.

2. Edit the top-level CMakeLists.txt, add the following *before*
add_subdirectory(src):

    include(ECMSetupQtTranslations)

    ecm_setup_qt_translations(

        PO_DIR po

        POT_NAME kbookmarks5.pot

        INSTALL_SUB_DIR kbookmarks

        CREATE_LOADER)

3. Edit src/CMakelists.txt, add ${ECM_QT_TRANSLATION_LOADER} to
kbookmark_SRCS:

    set(kbookmarks_SRCS

      kbookmark.cpp
      #...

      ${ECM_QT_TRANSLATION_LOADER}

    )

This works with the attached ECMSetupQtTranslations.cmake file.

When those changes are done, one gets translations installed and
loaded, as long as the source used to build contains a properly
populated po/ dir. This should be taken care of by the release scripts.

If this makes sense to you, I am going to propose
ECMSetupQtTranslations.cmake for inclusion in extra-cmake-modules.

Aurélien

References

1. mailto:agateau at kde.org
2. mailto:agateau at kde.org
3. mailto:Kde-frameworks-devel at kde.org
4. https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
5. mailto:Kde-frameworks-devel at kde.org
6. https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140320/fa53d78b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ECMSetupQtTranslations.cmake
Type: text/x-cmake
Size: 4232 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140320/fa53d78b/attachment-0001.bin>