GNOME Bugzilla – Bug 56059
Switch sheet files over to using xml-i18n-tools
Last modified: 2004-12-22 21:47:04 UTC
This bug is to hold the details about switching to xml-i18n-tools. For sheet files, we need to rename them to *.sheet.in. Then rename the <description>...</description> elements to <_description>...</_description>, and add the sheet.in files to the POTFILES file. Translations currently in sheet files should then be moved to the correct .po file. The xml-i18n-merge program is used to merge translations from the .po files with the .sheet.in files to create .sheet files that match the current format we are using. Some issues to think about are: - Do we dist the processed .sheet files in the source tarball? - What encoding should sheets have? (probably UTF-8) - what encoding does xml-i18n-merge leave us with? (should ask xml-i18n-tools maintainers about this) While converting to xml-i18n-tools, dia.desktop and app/GNOME_Dia.oaf should also be switched over to xml-i18n-tools. This will give translators a single source for translations (po/dia.pot). As for dependencies, this will require that people building from CVS (ie. developers) have xml-i18n-tools installed on their system, and people compiling from tarballs (ie. users) have perl on their system.
if xml-i18n-merge ultimately uses libxml2, it's extremely likely that we end up with UTF-8 text. I'm currently planning things that way. (FWIW, python 1.5.2's xml module returns UTF8 as well). Dealing with lots of UTF-8 XML files will greatly push us towards using libxml2 -- and supporting both is becoming a nightmare. The little Python code I have can extract translations from .sheet files to something vaguely resembling .po files. That'll probably be enough to charm gettext.
xml-i18n-merge doesn't use any XML parser actually -- it just looks for certain regular expressions in the file (similar to how xgettext doesn't have a complete C parser in it).
Phew ! I'm about to commit this.
Done.