Looking to move away from intltool (due to the grief it caused), I'm going to push a patch at some point which removes the transportability of the desktop integration files in the suite. (And drops intltool).
I've been looking at how to avoid loosing the benefits that this provided. (e.g. letting translators update the desktop integration files by editing the main .po files). http://repo.or.cz/w/geda-gaf/pcjc2.git?a=commitdiff;h=e451b030ddfbd7d35b9fd0844a838bfb1a1fb5db Shows a small program which actually generates the geda-gschem.desktop with printf's. For the translatable strings (which are marked), the program loops over all languages it can find .po files for (in ../po/*.po), and attempts a translation. I'd very much like it if someone on a non GNU system could test if this works. I got the feeling that changing languages on the fly at runtime was "magic". Another slight drawback to it is that it uses the translation files installed on the system (wherever the package is set to install). This is because otherwise you'd need to make a temporary locale directory structure, install the <locale>.gmo files to the appropriate places. I don't propose to hook it into the build system, since without extensive magic, it would break cross-compilation. (The script needs to run on the "build" machine. The idea is that it is a tool shipped in the data/ directory of gschem (similar to come for gattrib and libgeda) which can be run to regenerate an otherwise checked-in file. To use, you need the latest translated version of the package in question installed, you then run the program from the data/ directory, piping output to the required .desktop file. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
