Re: [RFC] moving translations off sheets ?

[James Henstridge <james daa com au>]

On Sat, 9 Jun 2001, Cyrille Chepelov wrote:

> Le sam, jun 09, 2001, à 09:05:11 +0800, James Henstridge a écrit:
>
> > It acts as a small wrapper around the gettext build scripts
> > (po/Makefile.in.in), adding support for extracting and merging from
> > various other formats.  It should be trivial to add support for dia sheet
> > files, and once that is done, the strings in the sheet files will make
> > their way into the dia.pot file and be handled by translators just like
> > any other string.
>
> Mmmmhhh... Looks like it does what my code does (but in a more generic way).
> My little script (attached here) is more crude: it just snarfs all strings
> and dumps them in a C file (I was too chicken to attempt merging stuff into
> dia.pot myself :-) ). Unfortunately, that means that the message's location
> identification is to be lost.
>
> It seems that all what's we need to make xml-i18n-tools accept .sheet files
> is to pipe two or three lines of xml-i18n's M4 file into sed
> 's/xml/sheet/g', do what's written in the README file, rip the translations
> out of current sheet files (my tool can do that, so that current
> translations can be manually merged into .po files), and sprinkle
> translation files with underscores (though the exact place where underscores
> are expected by xml-i18n-merge isn't crystal-clear).

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.

>
> 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, having xml-i18n-tools in the build process means that dia won't be
> buildable on Debian "potato" without also recompiling xml-i18n-tools for
> potato beforehand (same as for libunicode anyway).... I'm not sure it's
> really a problem.

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.

>
> > As part of dia's build process, it calls the xml-i18n-tools merge program
> > which merges translations back into the sheet files from the po files (it
> > may even be able to do a conversion to utf8 -- I haven't checked all the
> > details).
>
> gettext can be told to re-encode the messages into UTF8: it's just a call to
> bind_textdomain_codeset(PACKAGE,"UTF-8") between calling bindtextdomain() and
> textdomain(). In fact, I've just committed this (under
> UNICODE_WORK_IN_PROGRESS).

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).

James.

-- 
Email: james@daa.com.au
WWW:   http://www.daa.com.au/~james/