Re: Handling of frameworks using Qt-based translations
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]agat...@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]agat...@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@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@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
Re: Handling of frameworks using Qt-based translations
El Dijous, 20 de març de 2014, a les 07:06:58, Aurélien Gâteau va escriure:
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]agat...@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]agat...@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@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@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
Handling of frameworks using Qt-based translations
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
diff --git a/CMakeLists.txt b/CMakeLists.txt
index ecb6d87..86bec2e 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -40,6 +40,10 @@ endif()
add_subdirectory(src)
add_subdirectory(tests)
add_subdirectory(autotests)
+if (EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/po)
+include(${CMAKE_CURRENT_SOURCE_DIR}/QmSupport.cmake)
+qm_setup(kbookmarks5 po)
+endif()
# create a Config.cmake and a ConfigVersion.cmake file and install them
set(CMAKECONFIG_INSTALL_DIR ${CMAKECONFIG_INSTALL_PREFIX}/KF5Bookmarks)
diff --git a/QmSupport.cmake b/QmSupport.cmake
new file mode 100644
index 000..7c63064
--- /dev/null
+++ b/QmSupport.cmake
@@ -0,0 +1,53 @@
+# This gives us Qt5::lrelease and Qt5::lupdate but unfortunately no Qt5::lconvert
+find_package(Qt5LinguistTools CONFIG REQUIRED)
+
+# Find lconvert
+get_target_property(lrelease_location Qt5::lrelease LOCATION)
+get_filename_component(lrelease_path ${lrelease_location} PATH)
+find_program(lconvert_executable
+NAMES lconvert-qt5 lconvert
+PATHS ${lrelease_path}
+)
+
+function(_qm_create_target name)
+foreach (it ${ARGN})
+get_filename_component(it ${it} ABSOLUTE)
+# PO files are foo-en_GB.po not foo_en_GB.po like Qt expects
+get_filename_component(fileWithDash ${it} NAME_WE)
+string(REPLACE - _ filenameBase ${fileWithDash})
+file(MAKE_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR})
+set(tsfile ${CMAKE_CURRENT_BINARY_DIR}/${filenameBase}.ts)
+set(qmfile ${CMAKE_CURRENT_BINARY_DIR}/${filenameBase}.qm)
+
+# lconvert from PO to TS and then run lupdate to generate the correct strings
+# finally run lrelease as used above
+add_custom_command(OUTPUT ${qmfile}
+COMMAND ${lconvert_executable}
+ARGS -i ${it} -o ${tsfile}
+COMMAND Qt5::lupdate
+ARGS ${CMAKE_SOURCE_DIR}/src -silent -noobsolete -ts ${tsfile}
+COMMAND Qt5::lrelease
+ARGS -compress -removeidentical -silent ${tsfile} -qm ${qmfile}
+DEPENDS ${it}
+)
+set(qmfiles ${qmfiles}
Re: Handling of frameworks using Qt-based translations
On Tue, Mar 18, 2014 at 2:05 PM, Aurélien Gâteau agat...@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@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?
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Handling of frameworks using Qt-based translations
On Tuesday 18 March 2014 14:20:53 Aleix Pol wrote:
On Tue, Mar 18, 2014 at 2:05 PM, Aurélien Gâteau agat...@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@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.
Being a developer who never got how the translation system works and considers
it as black magic: yes that would break if it has to be done by the
application.
Cheers
Martin
signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Handling of frameworks using Qt-based translations
On Tue, Mar 18, 2014, at 6:20, Aleix Pol wrote:
On Tue, Mar 18, 2014 at 2:05 PM, Aurélien Gâteau [1]agat...@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
[2]Kde-frameworks-devel@kde.org
[3]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
References
1. mailto:agat...@kde.org
2. mailto:Kde-frameworks-devel@kde.org
3. https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Handling of frameworks using Qt-based translations
On Tue, Mar 18, 2014 at 4:12 PM, Aurélien Gâteau agat...@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 agat...@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@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@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
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Handling of frameworks using Qt-based translations
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]agat...@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]agat...@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@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@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.
Aurélien
References
1. mailto:agat...@kde.org
2. mailto:agat...@kde.org
3. mailto:Kde-frameworks-devel@kde.org
4. https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
5. mailto:Kde-frameworks-devel@kde.org
6. https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
