Hi all,
those of you who have been here for a long time might recall that when I joined the community I assumed that my tasks would be only two: backport patches to the stable TDE series and work on translation. Over time, it turned out that my tasks on the project would be bigger. However, work on translations is still a postponed task.
Recently, I have devoted some time to the tasks that are essential to move us forward with the work on translations. Therefore, I would like to inform you about the results and related plans.
I apologize for long email.
1. Unnecessary updates of POT files during package build
I observed that during the DEB packages build, an attempt was made to update POT files. However, this step makes no sense. Bundling usually takes place in dedicated pure chroot. Therefore, the result of updating POT files would be discarded anyway. So this is unnecessary work.
At the same time, the extractrc tool is used during the POT files update. But this tool is part of the tdesdk-scripts-trinity package. Therefore, when building other packages, it is usually not present. So updating POT files during building could not work well.
That's why I already removed these unnecessary updates of POT files while building DEB packages.
2. Do we still need to use the old modified version of xgettext?
I found out what the current status is and whether there are still reasons to use the old modified version of xgettext (kde-xgettext). Patches for the old version solve two things:
a) adding a way to enter plural forms of strings
b) adding a way to enter translation context
The current versions of gexttext already have both of these options, but they seem to be implemented in a different way. Before we can start using standard xgettext in TDE, we will need to add support for a new way of plural forms of strings and translation contexts.
So far, we need to continue using an old modified version of kde-xgettext.
3. Can modern gettext replace the extractrc tool?
Modern versions of gettext can handle XML files. We use XML files for 'kcfg', 'rc' and 'ui'. Using ITS support in gettext, there is a way to define which texts are to be extracted for translations. I tested this option, but I encountered some problems:
a) Tags are written in strings as html entities: < / > / &. After extraction using xgettext, are left in this form. But the extractrc tool convert them to the appropriate characters '<', '>', '&'. I did not find a way to do this with xgettext and ITS.
b) XPath is used to determine which strings are to be extracted from XML files. Files 'kcfg' use their own XML namespace and I did not find a way how to enter XPath to work properly with ITS in xgettext.
That's why I decided it was better to continue using the extractrc tool.
4. How do we create and update POT files?
In order to provide strings for translation, we first need to create and update POT files. The best place for these files is right in the source code – in GIT. Therefore, these files need to be maintained independently of the building binaries. Therefore, it is obvious that for this task it is not a good time during the build binary packages, nor the usual use of Automake or CMake.
Although the usual use of CMake with CMakeLists.txt for updating POT files is not a good choice, using CMake as such seems to be a good idea. CMake allows using the -P option to process a different file than the usual CMakeLists.txt. In this case, it does not create build folder, it does not create a cache - exactly as it suits us for our purpose.
I decided to use the name CMakeL10n.txt. I have prepared the CMake module TDEL10n.cmake. This module provides functions for simplifing directories handling – function tde_add_l10n_subdirectory as the equivalent for add_subdirectory and function tde_auto_add_l10n_subdirectories as an equivalent for tde_auto_add_subdirectories. And above all, the tde_create_l10n_template macro that provides POT files generation.
This macro provides some benefits that seemed useful:
a) If resource files are processed – for example, *.ui, the work file "rc.cpp" is commonly used to save extracted strings for translation. This file is then processed by kde-xgettext. Links to the original location of strings in the resulting POT file then refer to this "rc.cpp", which is not very useful.
The tde_create_l10n_template macro performs additional processing by replacing references to "rc.cpp" with references to the original resource files. Therefore, the POT file does not refer to a non-existent "rc.cpp" file, but to real locations in resource files.
b) When a new POT file is generated, a comparison is made with the original POT file. If only the date of POT file generation is changed, the original POT file will be left unchanged.
This prevents unnecessary POT file updates. This will allow to run a regular update of POT files without causing unnecessary commits.
5. What's next?
For revisions and comments, I created a pull request containing a CMake module TDEL10n.cmake:
https://mirror.git.trinitydesktop.org/gitea/TDE/tde-common-cmake/pulls/2
...and pull requests with a demonstration of use CMakeL10n in two modules:
https://mirror.git.trinitydesktop.org/gitea/TDE/abakus/pulls/1 https://mirror.git.trinitydesktop.org/gitea/TDE/tdebase/pulls/19
After testing, we will need to add CMakeL10n.txt to generate POT files in all other modules. Once we have automated updating of POT files, translation work can begin!
6. How can users work on translations?
I will leave the answer to this question for later. Whoever was more attentive could have noticed in several earlier commits that "something is being prepared" :)
Cheers
Just let us know when the translation files are ready (with minimal instructions of where they are located and how to upload them once
translated) and I translate them into Spanish and so correct that
even today there are phrases here and there in English using R14.0.5 in Spanish (a friend who is not on the list can translate into French, if no person in the list is presented as a candidate). Hopefully more people will join and we will keep the translations up to date (users without programming skills in C / C ++ can help only in a few areas).
A hug.
_______________________________ De: Slávek Banko slavek.banko@axis.cz Para: trinity-devel@lists.pearsoncomputing.net Enviado: Domingo 25 de noviembre de 2018 2:57 Asunto: [trinity-devel] Preparation for work on translations
Hi all,
those of you who have been here for a long time might recall that when I joined the community I assumed that my tasks would be only two: backport patches to the stable TDE series and work on translation. Over time, it turned out that my tasks on the project would be bigger. However, work on translations is still a postponed task.
Recently, I have devoted some time to the tasks that are essential to move us forward with the work on translations. Therefore, I would like to inform you about the results and related plans.
I apologize for long email.
1. Unnecessary updates of POT files during package build
I observed that during the DEB packages build, an attempt was made to update POT files. However, this step makes no sense. Bundling usually takes place in dedicated pure chroot. Therefore, the result of updating POT files would be discarded anyway. So this is unnecessary work.
At the same time, the extractrc tool is used during the POT files update. But this tool is part of the tdesdk-scripts-trinity package. Therefore, when building other packages, it is usually not present. So updating POT files during building could not work well.
That's why I already removed these unnecessary updates of POT files while building DEB packages.
2. Do we still need to use the old modified version of xgettext?
I found out what the current status is and whether there are still reasons to use the old modified version of xgettext (kde-xgettext). Patches for the old version solve two things:
a) adding a way to enter plural forms of strings
b) adding a way to enter translation context
The current versions of gexttext already have both of these options, but they seem to be implemented in a different way. Before we can start using standard xgettext in TDE, we will need to add support for a new way of plural forms of strings and translation contexts.
So far, we need to continue using an old modified version of kde-xgettext.
3. Can modern gettext replace the extractrc tool?
Modern versions of gettext can handle XML files. We use XML files for 'kcfg', 'rc' and 'ui'. Using ITS support in gettext, there is a way to define which texts are to be extracted for translations. I tested this option, but I encountered some problems:
a) Tags are written in strings as html entities: < / > / &. After extraction using xgettext, are left in this form. But the extractrc tool convert them to the appropriate characters '<', '>', '&'. I did not find a way to do this with xgettext and ITS.
b) XPath is used to determine which strings are to be extracted from XML files. Files 'kcfg' use their own XML namespace and I did not find a way how to enter XPath to work properly with ITS in xgettext.
That's why I decided it was better to continue using the extractrc tool.
4. How do we create and update POT files?
In order to provide strings for translation, we first need to create and update POT files. The best place for these files is right in the source code – in GIT. Therefore, these files need to be maintained independently of the building binaries. Therefore, it is obvious that for this task it is not a good time during the build binary packages, nor the usual use of Automake or CMake.
Although the usual use of CMake with CMakeLists.txt for updating POT files is not a good choice, using CMake as such seems to be a good idea. CMake allows using the -P option to process a different file than the usual CMakeLists.txt. In this case, it does not create build folder, it does not create a cache - exactly as it suits us for our purpose.
I decided to use the name CMakeL10n.txt. I have prepared the CMake module TDEL10n.cmake. This module provides functions for simplifing directories handling – function tde_add_l10n_subdirectory as the equivalent for add_subdirectory and function tde_auto_add_l10n_subdirectories as an equivalent for tde_auto_add_subdirectories. And above all, the tde_create_l10n_template macro that provides POT files generation.
This macro provides some benefits that seemed useful:
a) If resource files are processed – for example, *.ui, the work file "rc.cpp" is commonly used to save extracted strings for translation. This file is then processed by kde-xgettext. Links to the original location of strings in the resulting POT file then refer to this "rc.cpp", which is not very useful.
The tde_create_l10n_template macro performs additional processing by replacing references to "rc.cpp" with references to the original resource files. Therefore, the POT file does not refer to a non-existent "rc.cpp" file, but to real locations in resource files.
b) When a new POT file is generated, a comparison is made with the original POT file. If only the date of POT file generation is changed, the original POT file will be left unchanged.
This prevents unnecessary POT file updates. This will allow to run a regular update of POT files without causing unnecessary commits.
5. What's next?
For revisions and comments, I created a pull request containing a CMake module TDEL10n.cmake:
https://mirror.git.trinitydesktop.org/gitea/TDE/tde-common-cmake/pulls/2
...and pull requests with a demonstration of use CMakeL10n in two modules:
https://mirror.git.trinitydesktop.org/gitea/TDE/abakus/pulls/1 https://mirror.git.trinitydesktop.org/gitea/TDE/tdebase/pulls/19
After testing, we will need to add CMakeL10n.txt to generate POT files in all other modules. Once we have automated updating of POT files, translation work can begin!
6. How can users work on translations?
I will leave the answer to this question for later. Whoever was more attentive could have noticed in several earlier commits that "something is being prepared" :)
Cheers
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 2018/11/25 10:56 AM, Slávek Banko wrote:
Hi all,
those of you who have been here for a long time might recall that when I joined the community I assumed that my tasks would be only two: backport patches to the stable TDE series and work on translation. Over time, it turned out that my tasks on the project would be bigger. However, work on translations is still a postponed task.
Recently, I have devoted some time to the tasks that are essential to move us forward with the work on translations. Therefore, I would like to inform you about the results and related plans.
I apologize for long email.
- Unnecessary updates of POT files during package build
I observed that during the DEB packages build, an attempt was made to update POT files. However, this step makes no sense. Bundling usually takes place in dedicated pure chroot. Therefore, the result of updating POT files would be discarded anyway. So this is unnecessary work.
At the same time, the extractrc tool is used during the POT files update. But this tool is part of the tdesdk-scripts-trinity package. Therefore, when building other packages, it is usually not present. So updating POT files during building could not work well.
That's why I already removed these unnecessary updates of POT files while building DEB packages.
- Do we still need to use the old modified version of xgettext?
I found out what the current status is and whether there are still reasons to use the old modified version of xgettext (kde-xgettext). Patches for the old version solve two things:
a) adding a way to enter plural forms of strings
b) adding a way to enter translation context
The current versions of gexttext already have both of these options, but they seem to be implemented in a different way. Before we can start using standard xgettext in TDE, we will need to add support for a new way of plural forms of strings and translation contexts.
So far, we need to continue using an old modified version of kde-xgettext.
- Can modern gettext replace the extractrc tool?
Modern versions of gettext can handle XML files. We use XML files for 'kcfg', 'rc' and 'ui'. Using ITS support in gettext, there is a way to define which texts are to be extracted for translations. I tested this option, but I encountered some problems:
a) Tags are written in strings as html entities: < / > / &. After extraction using xgettext, are left in this form. But the extractrc tool convert them to the appropriate characters '<', '>', '&'. I did not find a way to do this with xgettext and ITS.
b) XPath is used to determine which strings are to be extracted from XML files. Files 'kcfg' use their own XML namespace and I did not find a way how to enter XPath to work properly with ITS in xgettext.
That's why I decided it was better to continue using the extractrc tool.
- How do we create and update POT files?
In order to provide strings for translation, we first need to create and update POT files. The best place for these files is right in the source code – in GIT. Therefore, these files need to be maintained independently of the building binaries. Therefore, it is obvious that for this task it is not a good time during the build binary packages, nor the usual use of Automake or CMake.
Although the usual use of CMake with CMakeLists.txt for updating POT files is not a good choice, using CMake as such seems to be a good idea. CMake allows using the -P option to process a different file than the usual CMakeLists.txt. In this case, it does not create build folder, it does not create a cache - exactly as it suits us for our purpose.
I decided to use the name CMakeL10n.txt. I have prepared the CMake module TDEL10n.cmake. This module provides functions for simplifing directories handling – function tde_add_l10n_subdirectory as the equivalent for add_subdirectory and function tde_auto_add_l10n_subdirectories as an equivalent for tde_auto_add_subdirectories. And above all, the tde_create_l10n_template macro that provides POT files generation.
This macro provides some benefits that seemed useful:
a) If resource files are processed – for example, *.ui, the work file "rc.cpp" is commonly used to save extracted strings for translation. This file is then processed by kde-xgettext. Links to the original location of strings in the resulting POT file then refer to this "rc.cpp", which is not very useful.
The tde_create_l10n_template macro performs additional processing by replacing references to "rc.cpp" with references to the original resource files. Therefore, the POT file does not refer to a non-existent "rc.cpp" file, but to real locations in resource files.
b) When a new POT file is generated, a comparison is made with the original POT file. If only the date of POT file generation is changed, the original POT file will be left unchanged.
This prevents unnecessary POT file updates. This will allow to run a regular update of POT files without causing unnecessary commits.
- What's next?
For revisions and comments, I created a pull request containing a CMake module TDEL10n.cmake:
https://mirror.git.trinitydesktop.org/gitea/TDE/tde-common-cmake/pulls/2
...and pull requests with a demonstration of use CMakeL10n in two modules:
https://mirror.git.trinitydesktop.org/gitea/TDE/abakus/pulls/1 https://mirror.git.trinitydesktop.org/gitea/TDE/tdebase/pulls/19
After testing, we will need to add CMakeL10n.txt to generate POT files in all other modules. Once we have automated updating of POT files, translation work can begin!
- How can users work on translations?
I will leave the answer to this question for later. Whoever was more attentive could have noticed in several earlier commits that "something is being prepared" :)
Cheers
Hi Slavek, I have tested the PRs (cmake, tdebase) and it works fine and nice. Obviously we have already discussed internally a lot, so I won't spend many more words here. We can proceed with preparation for all modules. Later we can take a look at replacing gettext-kde with gettext and eventually see if we can find a solution for point 3.
To all other users, we look forward for your contribution to translation in your own language :-)
Cheers Michele
Good day, late congrats with upcoming bringing back the translation.
It looks like the cmake-based translation still uses kde-gettext utility, I'm wondering there it could be found?
вс, 25 нояб. 2018 г. в 04:58, Slávek Banko slavek.banko@axis.cz:
Hi all,
those of you who have been here for a long time might recall that when I joined the community I assumed that my tasks would be only two: backport patches to the stable TDE series and work on translation. Over time, it turned out that my tasks on the project would be bigger. However, work on translations is still a postponed task.
Recently, I have devoted some time to the tasks that are essential to move us forward with the work on translations. Therefore, I would like to inform you about the results and related plans.
I apologize for long email.
- Unnecessary updates of POT files during package build
I observed that during the DEB packages build, an attempt was made to update POT files. However, this step makes no sense. Bundling usually takes place in dedicated pure chroot. Therefore, the result of updating POT files would be discarded anyway. So this is unnecessary work.
At the same time, the extractrc tool is used during the POT files update. But this tool is part of the tdesdk-scripts-trinity package. Therefore, when building other packages, it is usually not present. So updating POT files during building could not work well.
That's why I already removed these unnecessary updates of POT files while building DEB packages.
- Do we still need to use the old modified version of xgettext?
I found out what the current status is and whether there are still reasons to use the old modified version of xgettext (kde-xgettext). Patches for the old version solve two things:
a) adding a way to enter plural forms of strings
b) adding a way to enter translation context
The current versions of gexttext already have both of these options, but they seem to be implemented in a different way. Before we can start using standard xgettext in TDE, we will need to add support for a new way of plural forms of strings and translation contexts.
So far, we need to continue using an old modified version of kde-xgettext.
- Can modern gettext replace the extractrc tool?
Modern versions of gettext can handle XML files. We use XML files for 'kcfg', 'rc' and 'ui'. Using ITS support in gettext, there is a way to define which texts are to be extracted for translations. I tested this option, but I encountered some problems:
a) Tags are written in strings as html entities: < / > / &. After extraction using xgettext, are left in this form. But the extractrc tool convert them to the appropriate characters '<', '>', '&'. I did not find a way to do this with xgettext and ITS.
b) XPath is used to determine which strings are to be extracted from XML files. Files 'kcfg' use their own XML namespace and I did not find a way how to enter XPath to work properly with ITS in xgettext.
That's why I decided it was better to continue using the extractrc tool.
- How do we create and update POT files?
In order to provide strings for translation, we first need to create and update POT files. The best place for these files is right in the source code – in GIT. Therefore, these files need to be maintained independently of the building binaries. Therefore, it is obvious that for this task it is not a good time during the build binary packages, nor the usual use of Automake or CMake.
Although the usual use of CMake with CMakeLists.txt for updating POT files is not a good choice, using CMake as such seems to be a good idea. CMake allows using the -P option to process a different file than the usual CMakeLists.txt. In this case, it does not create build folder, it does not create a cache - exactly as it suits us for our purpose.
I decided to use the name CMakeL10n.txt. I have prepared the CMake module TDEL10n.cmake. This module provides functions for simplifing directories handling – function tde_add_l10n_subdirectory as the equivalent for add_subdirectory and function tde_auto_add_l10n_subdirectories as an equivalent for tde_auto_add_subdirectories. And above all, the tde_create_l10n_template macro that provides POT files generation.
This macro provides some benefits that seemed useful:
a) If resource files are processed – for example, *.ui, the work file "rc.cpp" is commonly used to save extracted strings for translation. This file is then processed by kde-xgettext. Links to the original location of strings in the resulting POT file then refer to this "rc.cpp", which is not very useful.
The tde_create_l10n_template macro performs additional processing by replacing references to "rc.cpp" with references to the original resource files. Therefore, the POT file does not refer to a non-existent "rc.cpp" file, but to real locations in resource files.
b) When a new POT file is generated, a comparison is made with the original POT file. If only the date of POT file generation is changed, the original POT file will be left unchanged.
This prevents unnecessary POT file updates. This will allow to run a regular update of POT files without causing unnecessary commits.
- What's next?
For revisions and comments, I created a pull request containing a CMake module TDEL10n.cmake:
https://mirror.git.trinitydesktop.org/gitea/TDE/tde-common-cmake/pulls/2
...and pull requests with a demonstration of use CMakeL10n in two modules:
https://mirror.git.trinitydesktop.org/gitea/TDE/abakus/pulls/1 https://mirror.git.trinitydesktop.org/gitea/TDE/tdebase/pulls/19
After testing, we will need to add CMakeL10n.txt to generate POT files in all other modules. Once we have automated updating of POT files, translation work can begin!
- How can users work on translations?
I will leave the answer to this question for later. Whoever was more attentive could have noticed in several earlier commits that "something is being prepared" :)
Cheers
Slávek
On Friday 01 of March 2019 00:48:14 Fat-Zer wrote:
Good day, late congrats with upcoming bringing back the translation.
It looks like the cmake-based translation still uses kde-gettext utility, I'm wondering there it could be found?
you can found gettext-kde package on QuickBuild: https://quickbuild.io/~slavek-banko/+archive/ubuntu/deps-r14/+packages?field...
...or ppa mirror: http://mirror.ppa.trinitydesktop.org/trinity-sb/pool/deps-r14/g/gettext-kde/
Cheers
Isn't there any source code repository or at least tarballs?
пт, 1 мар. 2019 г. в 04:00, Slávek Banko slavek.banko@axis.cz:
On Friday 01 of March 2019 00:48:14 Fat-Zer wrote:
Good day, late congrats with upcoming bringing back the translation.
It looks like the cmake-based translation still uses kde-gettext utility, I'm wondering there it could be found?
you can found gettext-kde package on QuickBuild: https://quickbuild.io/~slavek-banko/+archive/ubuntu/deps-r14/+packages?field...
...or ppa mirror: http://mirror.ppa.trinitydesktop.org/trinity-sb/pool/deps-r14/g/gettext-kde/
Cheers
Slávek
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
For gettext-kde we did not create git repository. Tarball you can find at a mentioned url - see
http://mirror.ppa.trinitydesktop.org/trinity-sb/pool/deps-r14/g/gettext-kde/...
If you're interested in what changes are in gettext-kde compared to ustream gettext (corresponding to 0.10.35), these you can see in the tdesdk repository:
https://mirror.git.trinitydesktop.org/gitea/TDE/tdesdk/src/branch/master/scr...
Cheers
-
Alexis PM -
Fat-Zer -
Michele Calgaro -
Slávek Banko