Bug 49182

Summary: Non-ASCII characters gets mangled in translated messages.
Product: [Retired] Red Hat Linux Reporter: Göran Uddeborg <goeran>
Component: gnupgAssignee: Nalin Dahyabhai <nalin>
Status: CLOSED RAWHIDE QA Contact: Aaron Brown <abrown>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-08-10 03:59:44 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Patch to make gnupg work with non-ASCII messages.
none
Patch to spec file. (Maybe obvious, but anyway.) none

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!