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
...and pull requests with a demonstration of use CMakeL10n in two modules:
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" :)
I don't know if this impacts the way that debs are built for TDE.
---------- Forwarded Message ----------
Subject: [britney]: Do you use --control-files or the "legacy package layout"
in your derivative?
Date: Sun December 30 2018, 11:13:00
From: Niels Thykier <niels(a)thykier.net>
To: Raphaël Hertzog <hertzog(a)debian.org>, Matthias Klumpp <mak(a)debian.org>,
Iain Lane <laney(a)debian.org>
CC: "debian-release" <debian-release(a)lists.debian.org>, "debian-derivatives"
I am writing to you, because I know that you are (or have been) involved
in setting up or maintaining a britney instance for a Debian derivative.
If you are no longer involving please let me know who to contact
instead (where applicable).
We are considering to deprecate the "legacy package layout" and remove
the "--control-files" option.
1) Debian no longer uses these two features in our production runs at
all and now instead simply point britney at the metadata of a
2) The "--control-files" option has not being updated and currently
generates incomplete Sources files for the target suite. We have
no test cases to safe guard against that. As it is not a feature
we use, it is unlikely to appear there.
3) The "legacy package layout" is currently used for tests and is
unlikely to disappear immediately. However, if a better layout for
test cases appear, we may migrate to it and remove the old code.
How can I tell if I use these features?
Check your britney command line. If it includes "--control-files" then
you are using both features (as "--control-files" only works with the
"legacy package layout".
Otherwise, check your britney configuration. If the path set for the
"TESTING" configuration points to a standard APT mirror (with a Release
file) you are unaffected by this mail. If it instead points to a file
directory with some "Packages_X" files and a "Sources" file, you are
using what I refer to as the "legacy package layout".
You can also check the output with -v for a line like . This
determine if britney actually believes it is working with a standard
If you use "--control-files":
If you use "--control-files", then you can probably discard it.
If you rely on the updated target suite, please consider reusing
whatever tooling you use to generate your source suite data to also
generate the target suite. This ensures you have a sane full data set
for both source suite(s) and target suites.
If you use the legacy package layout:
If feasible, consider migrating to using a standard mirror layout (e.g.
if you have a local mirror on the machine running britney). This also
enables you to remove the "ARCHITECTURES" and "COMPONENTS" fields from
your configuration file as britney simply reads those from the Release
file of the target suite.
If the mirror format it not an option, please let me know about your use
case to see if there is a better alternative.
Other bits while we are in contact. :)
We are accepting contributions to britney via salsa.debian.org in
form of Merge Requests and bug reports via the BTS as usual (with or
Merge Requests are preferred over patches in the BTS as we have
configured salsa to run our test suite for britney along with our code
coverage report at .
More (technical) details can be found in our docs for contribution.
Request for info about your britney sources/configs/setups:
We would very much like an updated list of links to your britney sources
(e.g. forks/clones), configurations and setups. Our aim is to get a
better understanding of what is out there and how you use britney. If
you use britney to process data generated by other tools than the ones
in use by Debian (like dak), it might be good to mention that as well.
Please send this info to debian-release(a)lists.debian.org.
I: [...] - Found a Release file in testing - using that for defaults
(Exact format depends on which version you are using)
I just wanted to let you know how TDE works on just-released FreeBSD 12:
Basicly everything works as expected, there are just 4 small problems.
- For 2 of them I've added bugs + fixes to the bugtracker.
- The 3rd is the test "tdeio/kmimetypetest" from "tdelibs", which still fails but mimetipes work after "make install".
- the 4rd is again a definition "#define ksize_t socklen_t", but I still have to find where that comes from.
So I'm quite pleased :-)
Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ...
I have ubuntu 18.4 with trinity R14.0.5. If I want to start the arduino
ide from arduino.cc (download and extract arduino-1.8.7-linux64.tar.xz)
there comes the splash-screen for one second and it crashes with this
Picked up JAVA_TOOL_OPTIONS:
TQSettings::sync: failed to open '/etc/tqt3/tqt_plugins_3.5rc.tmp' for
What I have to install or change? Thank you very much for the great Desktop.