Hi Osma! > Thanks for your quick response! Thanks to your comments I have now > gotten > much further and succeeded in updating some of the translations in my > system. I'll first respond to your message and in the end describe > how far I got.
Great news! > I'm not sure if introducing a *third* way to install message files is > such > a good idea. After all, there are already two parallel systems - the > original Debian packages install their own message catalogs, which > DDL l10n packages then override. Ok. Assuming we end with an automated nightly build, issuing a « transifex-update » or a « apt-get upgrade » doesn't change much things for the final user, you're right. I didn't remember this part of our former discussion. > One option would be to have somewhere a nightly cron script that > pulls > updated translations from Transifex and recompiles the l10n packages, > which could then be made available as a deb repository. This way an > interested user could at least install updated translations the next > day using apt-get upgrade. 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. > BTW, what's the difference between "transifex pull" and "transifex > sync"? > It says somewhere that pull is deprecated and sync should be used > instead. > When I used sync, it seemed to get updates for all languages > regardless of what I told it. 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. 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. > No, but if you want to sound Finnish you can introduce yourself as > Jani-Mikko ;) Though I haven't actually heard of anyone with that > combination of names - both are common, but separately. :) Jani-Mikko sounds good to me! > 0. Install prerequisites: > > # apt-get install subversion unaccent debhelper fakeroot > python-argparse > python-polib python-pip libqt4-dev intltool translate-toolkit gcc > # pip install transifex-client 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... > $ ./transifex pull all fi > > (works when I have fixed the URL problems and added --force) 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. > However, this did not update the icon names, on which I have done a > lot of > updates in Transifex in January. After some digging, I found out that > I need to build updated doudoulinux-icons packages. I tried this: > > $ ./build-debs.sh doudoulinux-icons > > [...] > > I can't really see what's failing here, any ideas what's wrong? 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/. 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/ 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! Cheers, JM. _______________________________________________ Doudoulinux-lang mailing list [email protected] https://mail.gna.org/listinfo/doudoulinux-lang
