Bug 49182 - Non-ASCII characters gets mangled in translated messages.
Summary: Non-ASCII characters gets mangled in translated messages.
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gnupg   
(Show other bugs)
Version: 7.3
Hardware: i386 Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Aaron Brown
Depends On:
TreeView+ depends on / blocked
Reported: 2001-07-16 17:41 UTC by Göran Uddeborg
Modified: 2007-04-18 16:34 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-08-10 03:59:44 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch to make gnupg work with non-ASCII messages. (1.06 KB, patch)
2001-07-16 17:42 UTC, Göran Uddeborg
no flags Details | Diff
Patch to spec file. (Maybe obvious, but anyway.) (707 bytes, patch)
2001-07-16 17:44 UTC, Göran Uddeborg
no flags Details | Diff

Description Göran Uddeborg 2001-07-16 17:41:11 UTC
Some time ago problems when using translations for gnupg with recent glibc
(bug report 16222 with at  least one duplicate, maybe 35859 is related). 
Glibc converts messages from the character set used in the message catalog
to the one used by the user as specified by the LC_CTYPE locale category
setting.  Since gnupg only sets the LC_MESSAGES, the effect is that all
characters of translated messages not present in ASCII will be replaced
with question marks.

I suggested doing a setlocale(LC_ALL,...) rather than
setlocale(LC_MESSAGES,...).  But apparently this has problems since gnupg
uses functions from <ctype.h> with the assumption they behave as in the C
locale rather than the user's choosen locale.

Since then I've got tired of seing all these mangled messages from gnupg. 
So when I realised the problem remains in this beta 1, I took a closer look
into the problem.  Please take a look at my new
suggested patch.  The idea is to first do a setlocale() for the LC_CTYPE
category, ask what character set was choosen with nl_langinfo(), and then
explicitly ask for this character set to be used with the
bind_textdomain_codeset() function.  Then immediately go back to the C
locale.  Do you think this could be used?  Please find the details in the
enclosed patch.

I'm suggesting the same patch to the GnuPG maintainer, and hopefully this
will find its way to the main version one day.  But in the meantime, maybe
we could have the Red Hat packaging fixed.  Chances are there will not be
any new gnupg release in time for the RH 7.2 release, at least.

Comment 1 Göran Uddeborg 2001-07-16 17:42:48 UTC
Created attachment 23727 [details]
Patch to make gnupg work with non-ASCII messages.

Comment 2 Göran Uddeborg 2001-07-16 17:44:10 UTC
Created attachment 23728 [details]
Patch to spec file.  (Maybe obvious, but anyway.)

Comment 3 Glen Foster 2001-07-16 18:53:30 UTC
This defect considered MUST-FIX for Fairfax gold-release.

Comment 4 Nalin Dahyabhai 2001-08-10 03:59:39 UTC
Sounds like a reasonable approach to take.  The patch will be added to
gnupg-1.0.6-3.  Thanks!

Note You need to log in before you can comment on or make changes to this bug.