Hi,
Daniel and I managed to whip up a small tool for generating a pot file
to and from a sgml/xml file. It seems to work pretty well for a quick
hack, and I don't know how complicated this needs to be. It needs a
little cleaning up ('--help' doesn't work and there are other argument
oddities) and a man page as well, but it might be worth starting to work
with it.
Should we try to put this in intl-tools? It's Darin's call of course,
but I think that if it manages to increase the number of translated docs
then it's a good thing. As a non-translator, I'd appreciate it if those
actually doing the translating could provide feedback.
HOW TO USE IT:
==============
I'm including the source file and a simple Makefile. You need
libxml2-devel installed in order to build it, but it should just work on
most modern systems.
To create a pot file, you need to do:
% doc-i18n-tool --output-pot-file file.xml > file.pot
You can add the --sgml flag if want to parse an sgml file.
Additionally, I think we really want to do something like:
% xmllint --noblanks file.xml | doc-i18n-tool --output-pot-file --filename file.xml -- - > file.pot
This will minimize chance that random white-space changes will effect
the doc. It doesn't really matter, so long as we're consistent.
Once you have the pot file, we can translate it, and convert it back by
doing (in Norwegian in this case -- use your own language):
% msgfmt translatedfile.pot -o file.mo
% mkdir -p no/LC_MESSAGES
% cp file.mo no/LC_MESSAGES
Finally, convert it back to SGML by doing:
% LANG=no_NO doc-i18n-tool --package file --localedir `pwd` file.xml | xmllint --format > file-no.xml
Note: If you originally created the pot file using 'xmllint --noblanks',
you need to do the same here.
OTHER ISSUES:
=============
It'd be nice to move to docbook xml ASAP, as we can use the xmllint
tool, then. Daniel, can we add a --sgml style arg to xmllint to handle
docbook-sgml? There's no reason we'd want to ever install these po
files, as this should be done in CVS by the translator.
Another problem is that we are over-sensitive. Ie, if we run into
passages like: <para>... mail to <email>accounts gnome org</email>
with...</para>, we probably don't want to do the <email> section
separately. It think we'll need to add some docbook specific hacks to
catch 'leaf' nodes like this to condense into the doc.
Comment?
Thanks,
-Jonathan
Attachment:
doc-i18n-tool.c
Description: doc-i18n-tool.c
Attachment:
Makefile
Description: Makefile