Re: [RFC] moving translations off sheets ?

[Cyrille Chepelov <chepelov calixo net>]

Le dim, jun 10, 2001, à 10:40:23 +0800, James Henstridge a écrit:

> I don't think it is as simple as a simple sed job.  The xml-i18n-tools
> package needs knowledge of each format it supports.  It would not be
> difficult to add support, but it has to be done.

It _is_. xml-i18n-tools works with XML files this way:
basically, you write your xml file as .xml.in ; each element which will need
translation is tagged with an "underscore before the element" (will have to
dig the GNOME CVS to check where exactly the underscore is expected).

Then, you call an automake macro provided by that package, which extracts
the strings and feeds them to xgettext, and filters the underscores out from
the .xml.in file into the (now generated) .xml file.

What we need is to duplicate the few lines in xml-i18n-tools.m4 which teach
automake how to make an .xml file out of an .xml.in, so that it does the
same with .sheet ; we also need to extract the existing translations out of
out .sheet files, add underscores and rename these files to .sheet.in (my
tool is able to write crude snippets of .po files with the translations in
one language or another ; hopefully that won't be too painful to extract).

> > We could use xml-i18n-tools for dia.desktop, too. That wouldn't be bad.
> 
> yep.  May as well use it for that one as well.

However, there's a big issue with xml-i18n-tools (and, to a lesser extent,
with my solution as well): the win32 build process. With xml-i18n-tools, we
need something which runs on Win32 and converts .sheet.in files into .sheet
files.

> Note that xml-i18n-tools adds itself to the build process like libtool and
> gettext do.  That means it is only required for people compiling from CVS
> (and it only takes about 5 minutes or less to install).  Btw, if Debian
> potato has gnome 1.4, then it already has packages using xml-i18n-tools.

No, it doesn't. But that's not a real problem, because potato doesn't have a
dia over 0.86 either. So if someone wants dia 0.92 on potato, she'll have to
compile a recent gtk and a recent gnome for potato as well. Fair enough, I
think. 

The big problem, OTOH, is having a rather hard dependency on a GNOME
component : that'll break builds for people who just want the GTK version
(including Win32). However, if converting from .sheet.in to .sheet is just a
matter of stripping the underscores off, then we might call sed to help to
make the xml-i18n-tools a soft build-dep, the way currently python is a soft
build-dep (ie, the build doesn't fail if python isn't here to build the
*-translation-reports)


> I don't know if using bind_textdomain_codeset is such a good idea.
> Would that would mean that all the return val of _() would always be in
> UTF-8?  If so, that will cause problems since gtk-1.2 expects to get
> strings in the locale's default encoding (unless you reencoded them, which
> would lead to two iconv passes in the normal case which seems a bit
> wasteful).

This *is* wasteful ; but the first iconv() call is done just once, when the
.po file is loaded. The second iconv() will happen all the time as long as
we're using gtk1.2 (and the way I've committed it, this won't happen at all,
since we won't be building "internally all UTF-8" build as long as
UNICODE_WORK_IN_PROGRESS isn't defined.)
 
	-- Cyrille

-- 
Grumpf.