registry entry for internationalization

[Bruno Haible]

Hello Werner,

Thanks for your answers.

> > Will gpg, on a Windows system where the user's regional settings are
> > German, use the German language even if the HKCU\Software\GNU\GnuPG:Lang
> > value is not set?
>
> No, it won't.  The installer however asks for the language to install
> and defaults to the one used on the system.

OK, I see.

This has the (minor) flaw that if the user changes his Regional Settings
after gpg was installed, gpg continues to work in the old language.

> > Do you expect users to set their preferred language once for every
> > program? If no, what is special about GPG that warrants a particular
> > intervention of the user for this program?
>
> Due to different qualities of translations users might not want to use
> eird and unchecked lange XX but choose EN or DE.

To protect against incomplete translations, on Unix a user would either
remove the corresponding .mo file, or access the program through a wrapper
script that sets LANGUAGE=en.

The only protection against translations of bad quality is to allow user
feedback from the users to the translators.

> > GNU gettext uses the Woe32 API call GetThreadLocale(). Do you see
> > anything wrong with that?
>
> All those locale setting under W32 are weird: Thedepend on whether it
> is a GUI or command line application.

Do you have details, please? (I haven't done GUI programs under Woe32 so
far.) Isn't there an easier workaround than registry settings?

I know about the difference in console display charset for command-line
application. This has the consequence that e.g. on a German system,
a program producing output for a GUI (e.g. gpg when invoked from within
Emacs in M-x shell) should emit ISO-8859-1 encoded output, but when
writing to a console window (DOS box) it should emit CP-437 or CP-850
encoded output. This is an old, known problem that is best solved through
setting the OUTPUT_CHARSET environment variable.

> > Is there something which makes the GNU libintl library
> > unsuitable for use on Woe32 systems?
>
> ... libintl requires the use of iconv.dll which we only recently
> started to use.

I agree that iconv.dll is a bit big, but I preferred this, rather than
using the native Woe32 charset conversion APIs, that would sometimes have
resulted in different strings being displayed on Woe32 than on Unix.

> There is also no need for all these translations back
> and forth - we now simply provide utf-8 encoded mo files for Windows.

libintl never does or did conversions "back and forth". It only convers
from the .mo file's encoding to the encoding requested by the application
(or, if the application does not specify one, to the user's locale
encoding). 

Bruno