Re: [RFC] moving translations off sheets ?

[Cyrille Chepelov <chepelov calixo net>]

Le dim, jun 10, 2001, à 07:27:50 +0800, James Henstridge a écrit:

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

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

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

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

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.
	
What do you think of this ?

	-- Cyrille

-- 
Grumpf.