> >
> >> I think the best solution is: DO NOTconvert the GETTEXT(3) returned
> >> messages, write it ***AS IS***, since GETTEXT(3) already do the
> >> correct conversion for us.
> >
> > Well, even though gettext may want us to believe otherwise, this doesn't
> > work for cross platform applications: e.g. in windows the locale for
output
> > on the console may be different from the locale for other uses. Back
when we
> > went with gettext (2004?), we've hashed this through pretty thoroughly.
I
> > hope that discussion is still available in the archives.
> >
>
> As I said in the first email of this thread, gettext 0.18.2 and 0.14.1
> give me the different behavior, it seems that gettext 0.14.1 do not do
> the correct thing. But do we still need support this OLD and BUGGY
> version ?
That was not my point nor the point we discussed back then. As long as
gettext tries to convert its translations to *any* encoding, it's flawed by
design, because some systems have multiple active output encodings (e.g.
Windows).
Unless this design has changed between 0.14 and 0.18, gettext() is still as
broken as it was. Translating or not translating doesn't matter: it'll just
be broken on other systems. Too bad the rest of it is actually pretty good.
Bye,
Erik.
Received on 2013-05-23 17:38:54 CEST