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.