On Tue, 2004-03-09 at 05:12, Dan Fandrich wrote:
> In my experience, marking up the internationalizable (is that a
> word?) text in libcurl (and curl) is pretty easy

Yes, this is simple (I contributed a fair bit of code to GNU gettext).

> The "hard part" of lookup up strings and translating them can be left
up
> to the application so libcurl doesn't become bloated with these kinds
> of things that aren't needed by everyone.

I18n of libraries (including libcurl) is orthogonal to i18n of
applications - because you can specify a domain (e.g. "libcurl") when
looking up a translation, you just use dgettext instead of gettext. The
libcurl library would have its own message catalogues installed into the
system, and would perform lookup independent of whether or not the
application was internationalised (this is how libc works, for example).

BUT internationalisation of libcurl is ALSO orthogonal to whether or not
the *_strerror functions have merit.

> but getting libintl
> to work over several versions of autotools is tricky.
> [...]
> Of course, 'curl' is one such application. Rather than shipping GNU
> libintl along with curl (which is how many GNU licensed applications do
> it), you could just link curl with the system libintl at build time.

Yes. Make an installed gettext a build prerequisite for using i18n
functionality, rather than including gettext as a sub-tree of the
distribution. Then all you have to do is look for (g)msgfmt at
./configure time, and use if it you have it. (The #define N_ changes,
too, to do nothing at all.)

The issue of xgettext is an orthogonal developer issue. When my
projects build, I extract with xgettext and then compare with the
message catalogues to see if there are new untranslated messages, and
fail the build if so. I then manually add an English version to the
translation catalogues with a TRANSLATE ME comment (easy to grep for).
In time, my contributors e-mail back patches for the translation
catalogues for their languages.

> I'm not sure to what degree the GNU i18n API has been standardized,
> but I think this could also work on Solaris, not just Linux.

In theory, GNU gettext used the existing method used by Solaris. Very
few GNU enhancements were required.
In practice, the Solaris implementation is largely broken, use GNU
gettext instead.

This thread seems to have strayed a long way from its origins.
Could we please return to the merits or otherwise of the functions
themselves and discuss whole-of-curl i18n implementation in a separate
thread?

By my count there is 1 voice against the *_strerror functions, and 5
voices for.
There seems to be a preference for naming them by their functional group
(curl_easy_strerror) rather than their type (CURLcode_strerror).
Attached is a patch with the alternate names.

-- 
Regards
Peter Miller <millerp_at_canb.auug.org.au>
/\/\*        http://www.canb.auug.org.au/~millerp/
PGP public key ID: 1024D/D0EDB64D
fingerprint = AD0A C5DF C426 4F03 5D53  2BDB 18D8 A4E2 D0ED B64D
See http://www.keyserver.net or any PGP keyserver for public key.