-----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. > > > 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 > 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 -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEjhl1z5vbYB3YbFTiKnW3yore1c8FAlv/gycACgkQKnW3yore 1c959Q//YzPR0hCcB6bxJiImAEfs+W1rdCvRLXh5OdpNOq9MTXTI5kUYqxGg+bTW VjIDuH5OwkeYpKlTyw4QKHrDM4osMmH4fX+zWHaA99K4SfQOgNyzKiCCyKQeOsY6 cK8V8bAKFO8C2INsBzWoHUXRHdVNI/93ticN7B1cl70TcyadaPcvGdUMmhVz2B+6 0aQzBGIpLoMWsNN/ybULQJf4Op+KXGhWp2rY/0ryyxIWxLCnz4gPWWMCEGKdqyLd JesYtT+CagbbLQnF4eXnZsYt6h5ke7hxvrvb/kCqQyGUIieCXPJyfr3NbZUPlLLZ gMeDkwSs2PFfdUl1++p7axQQM7fxRUggH+R4YVYQwHiNyUac86LMqczJ5Xe/RX+v Muxg+kgvWpNImqZhB6US6roBySEOQ8rPPVjqwutokk4NCIndZaU3wzPEnN2fPOA9 FMplNy1PQs5TqD89zGINJfjUT35VNElGrNPolHQetTMPZY8sQJzv3JkbzVbQjKLO KKrV1hQVhqqaSKJMyeExct0XxgkiRAnTiPeL2oSnZAgKpk7/j8PLPsaMm9aS9Jl0 ukmgH6HBfQXDLwzvZM2IyoqtmqdwNNCe+nvsFR3mb0btRvsDeD8+tfiP1IimqctJ JZF6I6ajiA3O5IMTe1igtGvhoDWVK9J1u/cSkWG+1+xxgrTmfmc= =lt2H -----END PGP SIGNATURE----- --------------------------------------------------------------------- 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
