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