Hi Jean-Michel!
On Tue, 25 Feb 2014, [email protected] wrote:
Until recently, having such nightly builds would have been difficult,
because we had no real server for the project on the Internet. But I
received 3 days ago a positive answer from one of the main French host
providers for my request to support our project: we will have access to
a virtual machine for free :). We'll host the nightly build process on
that machine.
Great!
The pull command is quite basic, it just calls the Transifex pull
command in a loop. The sync command does much more. A frequent issue I
had with Transifex is that, when I update the POT file of a project, all
the PO files get more recent than my local copy. As a result SVN thinks
all the PO files have changed while, actually, translations may have not
changed at all! There are other cases where Transifex changes files
while translations haven't been touched (eg. changes in header file).
To avoid polluting SVN with dummy changes, I wrote a script
"translation-report" that computes the translation score of PO files
before and after a Transifex pull. The command "./transifex sync" uses
this script to restore files that still have the same score after the
Transifex pull, using the SVN command "revert" (so you need to be up to
date with SVN). Moreover, new PO files coming from Transifex are
automatically added to SVN (svn add) so that I just need to type "svn
commit" for the whole resource.
Ah, thanks for the explanation!
Note that "translation-report" is not the ideal tool for that purpose:
if you just change a comma in a PO file on Transifex, your changes will
be reverted locally since the translation score won't have changed. We
should use a PO diff tool instead (there is a script "podiff.py" in
lang/) to find all the translations that have changed. Using a standard
diff tool can't work because we don't care of changes in comments and
header, and because messages can be split over several lines quite
randomly, on any space. Transifex and command line tools split messages
differently and this leads to dummy SVN changes, again...
NB: you'll also have to deal with PO diff tools to build translation
diff's to be sent to upstream or Debian maintainers.
Good to know.
I think this should be in the source package prerequisites, in
debian/control. This way, when you try to build the package, you may get
an error message generated by Debian tools telling which packages are
missing. Currently the source package seems to have no dependency at
all, this is weird...
Good idea!
I think I always use the --force flag, I can't remember why though.
Probably some updates are not performed if I omit it, likely because of
date stamps as you highlighted.
The flag was not in the transifex script, I had to add it manually I
think.
Actually this will rebuild the package but won't update translations in
*.desktop files, so you won't get the expected result. Application and
category icons (*.desktop and *.directory files) are tricky to be
managed for translations, because they're plain text files, not PO/TS
files. I finally figured out that tools exist to do this, but their use
is a bit complicated. Explanations can be found in the README file of
lang/trunk/env/icons/.
I see. Lots of moving parts here...
That said, a script is available in lang/trunk/env/icons/ to just update
*.desktop and *.directory files with translations: "update-icons.sh".
You have to run it *before* making the package, but this is not enough!
You may have noticed that the package doudoulinux-icons has its own copy
of *.desktop and *.directory files. They come from the lang/ branch
using the SVN feature called svn:externals. Look at SVN properties, in
the bottom of this page:
http://svn.gna.org/viewcvs/doudoulinux/packages/trunk/tweaks/doudoulinux-icons/
Yes, I know about svn:externals and sometimes use them myself.
So you'd also need to commit changes in icon files on SVN before
rebuilding the package. This is an issue in our goal to make an
automatic nightly build. I think we'll have to replace these externals
in the future by a relative path pointing to lang/trunk/env/icons/.
Quite a small change :).
Initially I wanted to totally separate live/, lang/ and packages/ so
that you don't have to wonder from where the package xxx can be built,
or where translations for package yyy are. Unfortunately, there are too
many dependencies between files so I had to introduce either relative
path or SVN externals to avoid making copies manually. This is why you
finally need lang/, packages/ and live/ to be able to update
translations!
What I find a bit disturbing here is that, as I understood the situation,
the source packages for doudoulinux-l10n and doudoulinux-icons are not
really enough to build the package - you have to run other scripts to
prepare the data and (if you like) pull updates from Transifex.
My suggestion would be to move things around so that everything necessary
to build the localization packages would be contained within the subtrees
of the respective source packages. The sources should be served as normal
Debian source package repositories.
Then a user could simply do something like this to have fresh
translations:
apt-get -b source doudoulinux-l10n
dpkg -i doudoulinux-l10n*.deb
or perhaps:
apt-get source doudoulinux-l10n
apt-get build-dep doudoulinux-l10n
cd doudoulinux-l10n*
debian/rules pull-transifex # custom rule (is it allowed?)
debian/rules binary
I think wrapping things up in self-contained source packages would also
make the automatic compilation much easier. What do you think?
-Osma
--
*** Osma Suominen / Osuuskunta Sange *** [email protected] ***
*** PL 197, 00131 Helsinki *** 040 - 5255 882 ***
_______________________________________________
Doudoulinux-lang mailing list
[email protected]
https://mail.gna.org/listinfo/doudoulinux-lang
