Simone Piunno <[EMAIL PROTECTED]> writes:

> I think by pushing this line of reasoning to the extreme you
> shouldn't have added i18n through gettext, should you?

You are right, and I was indeed leery of adding support for gettext
until I was convinced that it would work well both on systems without
gettext, and on systems with gettext that had no translations
installed.  Also, gettext doesn't change behavior of low-level
routines in a fundamental way -- it's just a way of getting different
strings.  On the other hand, wide chars do introduce pretty invasive
changes to the way things work.  The most basic things like printf and
strlen suddenly no longer work.

> I think this is how iconv and widechars can be safely introduced
> into wget, that is, by superimposing some piece of code that only
> gets compiled where it can be (and if not disabled by configure
> option) and making it so that when this piece code is not included
> you get the exact same old one.

Except that Wget will fail to work on all systems with
broken/incomplete support for wide characters and/or iconv, at least
without specifying this special configure option.  If compilation
under Solaris (a fairly common-place OS) is broken, imagine trying it
under Digital Unix, HPUX or IRIX, etc.

More importantly, I'm not convinced that wide chars are needed at all
for Wget's proper operation.  I don't see what would be wrong with
simply escaping foreign messages when they need to be printed on
screen.

Reply via email to