Re: [RFC] moving translations off sheets ?

[James Henstridge <james daa com au>]

On Sun, 10 Jun 2001, Cyrille Chepelov wrote:

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

Okay.  So we would just have to change things like
  <description>blah blah blah</description>
to:
  <_description>blah blah blah</_description>

xml-i18n-merge then removes the underscores and adds extra lines with the
correct xml:lang attribute.  We don't need to change the file extension --
the type of merge is based on the command line argument.

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

There should be no need to do any copy and paste -- when you call
xml-i18n-toolize, it copies all the necessary scripts into your build tree
(just like gettextize or libtoolize do).  So someone who has a tarball
will not need xml-i18n-tools installed -- just those building from cvs
(ie. developers).  It does add a perl dependency to the build though.

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

I would not be surprised if xml-i18n-merge works correctly under windows
as well (it is just a perl script).  If there are problems, I am sure they
will accept patches.

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

xml-i18n-tools isn't really a dependency on a gnome component.  It isn't
dragging anything requirements into the build process other than perl.  If
that is a problem, I am sure we can set up the makefiles to include the
merged sheet files in the tarball if this build requirement is a problem.

James.

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