On Thu, Aug 07, 2008 at 02:20:31PM +0200, Jordi Mas wrote: > · We should pack all the languages in the installer for which Planner > has support. Many people does not speak English, then having an English > only installer is really a step backwards for a software that is > localized to so many languages. I have spent the last day and a half on battling with NSIS, intltool and gettext to see how to provide a fully translated installer. For those of you who don't know gettext/intltool, I'll give a simplified explanation of how they work together to use the translations in .po files. gettext[1] can extract strings from C source code and create an initial .po file for translators to edit. It can also update existing .po files with new strings and warn about missing translations. Furthermore it converts a .po file to a binary file that the application will use at run-time to display the translated strings. To support more than just applications written in C, intltool was written. It is used to convert several different (text) file formats into dummy C files that can be processed by gettext. Afterwards it can use the original input file and the .po files to generate a translated output file. I've seen that I can use intltool to handle the format of our NSIS files[2] by simply selecting input type "gettext/quoted". It just grabs all quoted strings when generating a .po file and writes separate output files for each language where the strings have been replaced. Gettext & friends of course all use UTF-8. If I'm not mistaken the regular version of NSIS uses the active windows code page to display characters. Consequently it will not allow me to select Russian when I run the installer on a system using the WinLatin1 encoding (cp1252). Also the NSIS files containing the translated strings will have to be edited in their own code page. There is also Unicode NSIS[3], which uses UTF-16LE everywhere. It only works on Windows 2000 and later, but I don't see that as a problem. Perl will need to be installed for intltool, so we might as well use it to convert the output of intltool from UTF-8 to UTF-16LE so Unicode NSIS can read it. An unfortunate consequence of using Unicode NSIS is that all its script files will also have to be stored in UTF-16LE. This is not a problem for vim on Linux/UNIX, nor for notepad and wordpad on Windows, but the vi version that comes with MSYS does not support it and diffing may not work well in viewvc/svn (not sure). Winmerge and TortoiseSVN work fine with it though. I'd prefer not to have anything non utf-8 in subversion, but if the alternative is an extra conversion step before NSIS can be run then I'm not sure which is better. If anyone can suggest a different approach I'd love to hear it. Regards, Maurice. [1] http://www.gnu.org/software/gettext/manual/gettext.html#Overview [2] http://svn.gnome.org/viewvc/planner/trunk/installer/languages/dutch.nsh?view=markup [3] http://www.scratchpaper.com/ -- Maurice van der Pot Gentoo Linux Developer griffon26 gentoo org http://www.gentoo.org Gnome Planner Developer griffon26 kfk4ever com http://live.gnome.org/Planner
Attachment:
pgpdV0QPYVdcZ.pgp
Description: PGP signature