Re: [RFC] moving translations off sheets ?

[Cyrille Chepelov <chepelov calixo net>]

Le lun, jun 11, 2001, à 02:29:14 +0800, James Henstridge a écrit:
> 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).

Post 0.89. I don't want to be beat by a sudden ".sheet files are UTF-8"
change. But either just after 0.89 or a little while after (libxml1 does
have stuff to query for an encoding or another), that's fine.

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

OK.

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

.... hmmm, except strings which are sent to the edit controls and brought
back. And strings which are sent to the gdk renderer.

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

... which amounts to grepping for gtk_text_insert, gtk_editable_get_chars,
gtk_entry_[sg]et_text, and modifying app/gdk_renderer.c(draw_string). Sounds
fair enough. I'll comment out the call to bind_textdomain_codeset() (it's
disabled for the moment anyway).

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

No, I was just giving a nod in that direction :-)

> > [*] 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).

definitely. But gtk 2.0 will direct the flak to itself for us :-)

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

Nope. libxml will do the conversion for us (either we HAVE_UNICODE and we
ask libxml to give us UTF-8, or we don't, and we ask libxml to give us
either the locale's encoding if we can get it, or latin1 if we can't). Ditto
when saving. #ifdef'd one-liners in both directions.

Of course, if it was just me, I'd just go ahead and make libunicode mandatory.

	-- Cyrille

-- 
Grumpf.