Re: Problem with gettext on Solaris

[Bruno Haible]

Hello Brian, hello Ienup,

> I believe Solaris currently supports Revision 0 correctly.

Well, there probably still is a small bug, affecting portability
of message catalogs from/to PowerPC systems, if they contain non-ASCII
msgids. GNU gettext and GNU libc had the same bug. Namely, the hash code
function for a msgid string is platform dependent: it depends on whether
'char' is signed or unsigned. The affected functions are
  get_hashid() in 
http://svn.genunix.org/repos/on/trunk/usr/src/lib/libc/port/i18n/gettext_util.c
and
  hashpjw() in 
http://svn.genunix.org/repos/on/trunk/usr/src/cmd/msgfmt/gnu_hash.c
The fix in GNU gettext and GNU libc was to use put each byte into an
'unsigned char' variable before doing arithmetic with it.

Also it might be useful to verify the claim that Solaris supports
GNU MO files revision 0, by running GNU gettext's testsuite
(in gettext-0.14.5/gettext-tools/tests/) with a modified build that
uses the gettext() function from libc.

> We are still
> trying to determine if supporting revision 1 would be a big benefit
> to Sun users.  So any feedback about what breaks if we only support
> revision 0 would be useful.

The GNU MO file revisions vs. features are:
  - major 0, minor 0: the classical one, extended to handle plural forms.
  - major 0, minor 1: support for gettext ("file size: %" PRIdMAX " bytes")
  - major 1, minor 1: support for "%Id" in the translations

Major 0, minor 1 is useful only for the very few applications which use
this feature.

Major 1, minor 1 is essential for Farsi, which makes the distinction
between latin digits and arabic digits. It is used in GNOME.

Major 1, minor 1 is implemented using the same "system dependent segment"
technique of major 0, minor 1. I.e. Major 1, minor 1 and major 0, minor 1
share the same implementation technique. (But it's easier to support
just the "%Id" feature of major 1, minor 1, compared to the whole support
for major 0, minor 1, because here the system dependent segments occur only
in the translations and thus don't affect the hash codes of the msgids.)

> I wonder why the AM_GNU_GETTEXT macro does not check the
> __GNU_GETTEXT_SUPPORTED_REVISION macro to see what version the
> system supports rather than checking internal symbols that may
> not be the same on each system (such as the _nl* functions).

Sadly, the __GNU_GETTEXT_SUPPORTED_REVISION macro was introduced too late:
gettext 0.10.xx doesn't have this macro in <libintl.h>. And to make things
worse, glibc's <libintl.h> has the macro but it is incorrect for
major = 1 :-(

> Looking at the way AM_GNU_GETTEXT is defined it seems to check if a few
> internal symbols such as,_nl_msg_cat_cntr, _nl_domain_bindings, and
> _nl_expand_alias to find out whether GNU gettext is being supported in
> the system or not and also what revision is supported by the system.
> This does not seem very portable.

Since the purpose is to test for particular versions of GNU gettext, and
exclude Solaris 7 gettext() and NetBSD gettext() and similar incompatible
implementations, it does the job.

> If it works (or can be made to work) with
> revision 0, then perhaps we could improve things by simply getting the
> Solaris gettext() people to make sure that we define
> __GNU_GETTEXT_SUPPORTED_REVISION(0).  We currently do not do this.

That would be good. Then the AM_GNU_GETTEXT macro could use
__GNU_GETTEXT_SUPPORTED_REVISION at least on Solaris.

> Is this correct?  If so, what would be the best way to approach getting
> this issue resolved in AM_GNU_GETTEXT?  Is there a bug reporting tool
> I should use to file a bug, or is this mail list the right place to
> report such issues?

This mailing list is the right channel. I would use the bug tracker
(at savannah.gnu.org) only if you get the feeling that the issue is not
handled in a timely manner.

Best regards,
                           Bruno