bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gettext 0.10.37 msgfmt charset naming compatibility on Solaris 8


From: Paul Eggert
Subject: Re: gettext 0.10.37 msgfmt charset naming compatibility on Solaris 8
Date: Wed, 16 May 2001 15:00:24 -0700 (PDT)

> From: Bruno Haible <address@hidden>
> Date: Wed, 16 May 2001 21:24:05 +0200 (CEST)

> > How about instead modifying config.charset so that it will output the
> > tables in question?
> 
> That would be twice as much maintenance work, for little gain.

You're right that it's a bit more maintenance work, if config.charset
is maintained by hand.  But it's not that much more maintenance work,
as the reverse tables are not that hard to derive.  I can even modify
config.charset to generate the reverse tables automatically from the
forward tables: that way, you won't have twice the maintenance work in
the future.

And I'm not sure I see why it's little gain.  It decouples GNU
applications from requiring libiconv, and that is a real gain.

> Yes, it would be helpful, also for other programs like mutt, to have a
> reliable iconv wrapper that doesn't require users to install libiconv
> if all they need to handle is covered by their native iconv.

> The autoconf tests should be one per desired encoding. E.g.

>   AC_ICONV_ENCODING(ISO-8859-1, [{ "iso8859-1", "8859-1" }],
                    
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF,
                    19FA81E1)

> would define ICONV_NAME_ISO_8859_1 to the string to be passed to
> iconv(), or not define it if not present or the quality is
> insufficient.

That exact syntax won't scale well to east Asian codesets, as the
bitmask will be too long.  I guess this could be fixed, though (if
you're willing to settle for spot checks).

This is a bit discouraging, I'm afraid.  In effect, you're suggesting
that every GNU application run extensive tests on every vendor's
conversion tables when the application is built.  That would be nice,
but I wonder whether it's really necessary.  Conversions don't have to
be perfect; they just have to be good enough.  For example, for this
application we needn't check every possible character; just the
characters that are in the .po files.

As things stand I may have to start recommending using --disable-nls
on all hosts other than GNU/Linux hosts, and that is also
discouraging.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]