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@xxxxxxx>: > > 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 > -- > Slávek --------------------------------------------------------------------- To unsubscribe, e-mail: trinity-devel-unsubscribe@xxxxxxxxxxxxxxxxxxxxxxxxxx For additional commands, e-mail: trinity-devel-help@xxxxxxxxxxxxxxxxxxxxxxxxxx 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
