Re: [RFC] moving translations off sheets ?

[James Henstridge <james daa com au>]

On Sun, 10 Jun 2001, Cyrille Chepelov wrote:

> Ah ? xml-i18n-merge looks up the .po files for translations and merges them
> back into the resulting XML file ? Nice: we don't even have to modify the
> code we have, then. That is Good(tm).

Sounds like it would be a good idea to switch over then.  One last thing
to check up on is how it handles encodings.  Do you want to make this
change pre or post 0.89? (you said it would be a good idea to get a 0.89
release out the door).

> > > 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.
>
> Yes. And that's a hard build-dependency, but I think it's not a too
> far-fetched one (neither is python, IMO).
>
> > 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.
>
> Do we have a developer with a working win32 toolchain (remember dia
> currently hasn't been built with mingw32, just a plugin has. The core
> currently is built using MSVC), and with an open enough view on translated
> software to be willing to participate in this ?
>
> Note as current dia-win32 doesn't include any translations, we would just
> sed the .sheet.in files into "C"-only .sheet files, for the Win32 build (as
> a temporary measure, of course).

I belive that xml-i18n-merge doesn't rely on any of the gettext tools
(msg*, xgettext and gettext).  It parses the .po files directly.  There
are various Perl distros for win32 (the ActivePerl and cygwin packages
come to mind), I don't believe this will be too much of a problem.  If it
is, we can always get it so that the processed .sheet files are included
in the source tarballs.

> > 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.
>
> Looks fine.
>
> It looks like what we currently have in CVS is in a better shape than
> 0.88.1 wrt crashes and annoyances. OTOH, there are quite big works ahead
> (I'm going to spend a fair part of the week doing an (hopefully) exhaustive
> audit of string handling, which will mean moving from *(p++) kind of string
> handling to using the interface from charconv. Also, I'm currently extending
> a bit properties.[ch] to support what lazyprops does. I want to kill
> lazyprops before it spreads too much (there's an object in EML/ which uses
> it). etc.) For these reasons I'd feel more comfortable if we tagged the
> current CVS as 0.89 (going through the proposed few-days "sync win32"
> release candidate cycle).
>
> In short, the plan could be the following:
>
>       - ASAP: 0.89-rc1 (from the current CVS)
>       - ASAP+few days: 0.89 proper (everything's perfect, isn't it ?)

sounds good.  I can make the release candidate and final tarballs if you
want (along with making sure "make dist" works :).

>       - for 0.90: string handling audit ; xml-i18n-tools ; actual removal
>       of renderobjects and libsybase.so ; if we're bold, flipping the
>       UNICODE_WORK_IN_PROGRESS switch.

Making all operations on text data from the diagram files (and keyboard
input that gets passed to objects) UTF8 sounds like a good thing to aim
for in 0.90.  Making gettext reencode all strings returned by _() doesn't
seem like a good idea.  It will require an extra iconv pass so the strings
can be displayed in the GUI.  The two options are:

 1) _() returns UTF8 -> we need to iconv() them back to the locale's
    encoding every time we want to display them in the GUI.  When we
    upgrade to gtk 2.0, remove all the extra iconv pass as we want strings
    in UTF8.

 2) leave _() as using the locale's encoding.  No extra iconv pass is
    necessary when using the strings in the GUI.  When we upgrade to gtk
    2.0, we tell gettext to return UTF8.  There is no need to change any
    of the code that displays strings in the GUI, because it will be
    using the correct encoding now.

With option (2), it will still be necessary to reencode translated strings
in some cases (eg. some of the strings in UML classes which get drawn on
the canvas).

I will look into any possible issues we may run into with xml-i18n-tools.

>       - after 0.90: removing the UNICODE_WIP symbol (making its code the
>       default) [*]
>
> (of course, I haven't talked about the GUI area or Bonobo stuff, which while
> important, isn't much into my area of knowledge)

I don't think the above changes will affect the dia bonobo control much/at
all.

> Lower priority but important too: kill lazyprops (no fun job, but I feel
> it's my mess -- I welcome help, of course !), bring objects into
> modernity (and in the mean time, have at least a Connection and an Element
> polished and tagged as "reference objects" for new object writers).
>
> [*] that doesn't mean UNICODE mandatory. This is a separate issue.

At some point, we will have to make it mandatory (when we port to gtk 2.0
at the latest).

At the moment, diagram files are not portable accross locales with
different encodings, which is bad.  If unicode for diagrams is a compile
time option, we may be in a situation where diagrams made in the same
locale are sometimes incompatible.  If UTF-8 encoding for diagrams is
mandatory, then diagrams will be portable.

That is my reasonning for not making unicode optional (as well as making
it easier to make sure releases work correctly).

> What do you think of this ?

Sounds like a good plan for the next few releases.

James.