Re: glade localization woes

[Thierry Vignaud <tvignaud mandrakesoft com>]

Jan Hudec <bulb ucw cz> writes:

> > > > you need to call "some_module::bind_textdomain_codeset("mydomain",
> > > > 'UTF8');" in order to get utf8 strings
> > >
> > > That's a bug in the bindings. The binding of gettext SHOULD
> > > *convert* the string to utf-8 from whatever gettext returns and mark
> > > it as utf-8 string. After all, in other languages that only have
> > > utf-8 strings it has to do the same.
> >
> > no, read the gettext API: the program has to tell gettext in which
> > encoding it expects strings, else gettext assume the program will use
> > the encoding specified by the current locale.
>
> Yes. And since perl knows about unicode strings, it should always tell
> it wants unicode. 

internally managing strings in utf8 does not imply my program shall
print unicode strings.

this is bad.

as a package, i've already fix enough buggy packages that either print
truncated strings under X11 or garbage on the console to no want this.

simple example: translation of --help message ...

when one print sg on the console, it has better to follow the locale
encoding since the odds're high this'll work smoothly.

> Though, well, the I18N support in perl is lacking, unfinished and
> broken. It's a horror to get perl to properly honor locales.

it's not.
lot of perl programs work smoothly with l10n.
mandrakelinux tools properly suppport 71 languages including bidi
support, CJK support, ...

> > b) gtk+2 perl bindinb does not include any gettext support. it just
> >    expect you to pass it unicode strings.
> >
> >    BUT gettext will give it strings encoded in the *locale encoding*
> >    (the value of nl_langinfo (CODESET)', which depends on the
> >    `LC_CTYPE')
> >
> >    just RTFM !
>
> That's OK -- for the C version. But not for the bindings. The bindings
> can simply:
>
>     * Use bind_textdomain_charset to se utf-8 in the binding of
>       bindtextdomain -- there is no point in not using unicode.
>       (note: bind_textdomain_charset is broken -- it should take empty
>       domain as "override for each and every domain", but it does
>     not)

how can the gtk2-perl binding know which domain the app may want to
use ?

what's more, i may want some messsages to be displayed in old ISO page
codes b/c all terminals are not utf8 capable so i may want a domain
not set to utf8 or i may not use utf8 even if gtk+ initialize smoothly
b/c the program find it lacks sg, ...

as a package, i've already fix enough buggy packages that either print
truncated strings under X11 or garbage on the console to no want this.

this has nothing to do in perl-Gtk2 since you're enforcing a policy
into the toolkit. what's more, it would add a useless dependancy in
perl-Gtk2 on gettext.

last but not least, since Locale::Gettext has no knowledge of
gtk2-perl and cannot and shouldn't know whether gtk+2 is used or not,
there's no reason that this package should enforce utf8

>     * Mark return from gettext function as utf-8 string (it was forced
>       to be one)

if you do the first point, this is useless.

if you do not, you are assuming that gettxt will return utf8 strings,
which is wrong since the encoding will be eventually the locale one.

last but not least, since Locale::Gettext has no knowledge of
gtk2-perl and cannot and shouldn't know whether gtk+2 is used or not,
there's no reason that this package should enforce utf8

> Perhaps we should have own bindings in Glib-perl, that will do just
> this...

properly use gettext ist just more sane