[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Support for non UTF8 encodings



Le vendredi 26 février 2010 à 17:45 +0000, Roger Leigh a écrit :
> On Fri, Feb 26, 2010 at 04:14:27PM +0000, Roger Leigh wrote:
> > On Fri, Feb 26, 2010 at 03:35:20PM +0100, Julien Valroff wrote:
> > > A user recently reported a bug[0] regarding localized messages from
> > > rkhunter not being correctly displayed with other encodings than UTF-8.
> > > 
> > > This is simply caused by the translations being encoded in UTF-8.
> > > 
> > > UTF-8 being the default encoding for new installations, I am not sure
> > > whether other encodings should absolutely be supported. Am I right?
> > > What do you think of it?
> [...]
> > That said, this doesn't look like this is what is happening in this
> > case.  In this case, the localised messages are not being recoded
> > from UTF-8 to the locale charmap at runtime, and this is the cause
> > of the corrupted output.  This is a bug.  Localisation systems
> > such as gettext (what pretty much everything uses) will automatically
> > recode from the .po/.mo translation encoding to the locale encoding
> > ('locale -k charmap').  If this isn't happening, rkhunter's
> > localisation is broken.
> 
> I can't see any evidence of a de translation in the source.  I
> can only see the Debian debconf translations in debian/po, and
> some other type of translation in files/i18n (but no .de).  That
> directory does have two zh files (one for UTF-8, one other, maybe
> BIG-5?).  Looking at how rkhunter is doing its localisation
> internally, it's just mapping to keys in this file, and there's
> no recoding, which *is* buggy.
> 
> Personally, I'd just recommend that rkhunter should switch to
> using GNU gettext, which can be called from shell scripts using
> gettext(1), and will automatically do the necessary recoding.

I will suggest this to upstream development team, thanks for your
suggestion ;)

Cheers,
Julien


Reply to: