README for libintl-perl
=======================

The package libintl-perl is an internationalization library for Perl
that aims to be compatible with the Uniforum message translations
system as implemented for example in GNU gettext.

See the file COPYING and the source code for licensing.

Requirements
------------

The library is entirely written in Perl.  It should run on every
system with a Perl5 interpreter.  The minimum required Perl version
should be 5.004.

The behavior of the package varies a little depending on the Perl
version:

- Perl 5.8 or better

Recommended.  Perl 5.8 offers maximum performance and support for
various multi-byte encodings (even more if Encode::Han is installed).
Additionally the output charset is chosen automatically according to
the information provided by I18N::Langinfo.  In fact, I18N::Langinfo
is already available for Perl 5.7 but this developer version is
probably not much in use any more.

- Perl 5.6 or better

Still offers high-performance UTF-8 handling but no support for other
multi-byte encodings unless the package Encode is installed.

- Earlier Perl versions

Full UTF-8 support but quiet slow since all conversion routines are
written in Perl.  More exactly: Encoding from 8 bit charsets into
UTF-8 is reasonably fast and usable.  Decoding UTF-8 is slow, however.

Note that these are actually the requirements for the *users* of your
software internationalized with libintl-perl.

As a maintainer of a Perl package that uses libintl-perl, you will
also need a recent version of GNU gettext (see the file README in the
subdirectory "sample/" of the source distribution of libintl-perl).
Translators of your software can basically do their job with any text
editor, but it usually makes sense for them, too, to have GNU gettext
installed.  End users of your software, or people that install an
internationalized Perl package do *not* need it, unless they want to
add a new language to your software.

Installation
------------

If libintl-perl is not installed on your system, you have to build it
from the sources, which is a lot easier than you may think.  You need
the program "make" for that and a command line shell.  No C compiler is
required.

Unpack the package in a directory of your choice, cd into that
directory and then type

     perl Makefile.PL
     make

This will build the package.  You can then run the tests with

     make test

To install the package, type

     make install

You will probably need root permissions to do that.

Of course, you can also use the CPAN module to install the package.

Feedback
--------

Send negative (and positive!) feedback to me.  Bug reports can be send
directly to me or you can use the
[RT bugtracking system](http://rt.cpan.org/ "Link to RT").

If you use libintl-perl for your project, private or public, free or
commercial, please let me know.  I am interested in such information.

If you really like (or dislike?) libintl-perl, tell the world about.
You can star it on [github](http://github.com/gflohr/libintl-perl).  You
can rate it and even write a review at
[cpanratings](http://cpanratings.perl.org/)
(search for "libintl-perl").

Design Goals
------------

The primary design goal of libintl-perl is maximum compatibility with
the gettext functions available for other programming languages.  It
is intended that programmers, translators, and end users can fully
benefit from all existing i18n tools like xgettext for message
extraction, msgfmt, msgmerge, etc. for catalog manipulation, Emacs PO
mode (or KBabel, PO-Edit, ...) for catalog editing and so on.

Another design goal is maximum portability.  The library should be
functional without any additional software but with a wide range of
Perl versions.  Wherever possible, hooks have been inserted to benefit
from advanced features in the runtime environment, but the basic
functionality should be present everywhere.

Overview
--------

The core of the library is the module Locale::gettext_pp.  It is a
pure Perl re-implementation of the module Locale::gettext available on
CPAN.  However, the XS version Locale::gettext lacks some functions
(notably plural handling and output conversion) that are already
present in Locale::gettext_pp.  Locale::gettext_pp provides the
internationalization functions that are available in your system
library (libc) or additional C libraries (for example libintl in the
case of GNU gettext).

The class Locale::Messages is an additional abstraction layer that is
prepared for dynamic switching between different gettext implementations (for
example Locale::gettext_pp and Locale::gettext).  It provides
basically the same interface as Locale::gettext_pp but in an
implementation-independent manner.

The module Locale::TextDomain is the only module that you should
actually use in your software.  It represents the message translation
system for a particular text domain (a text domain is a unique
identifier for your software package), makes use of Locale::Messages
for message translation and catalog location, and it provides
additional utility functions, for example common shortcut names for
i18n routines, tied hashes for hash-like lookups into the translation
database, and finally an interpolation mechanism suitable for
internationalized messages.

The package also contains a charset conversion library
Locale::Recode.  This library is used internally by Locale::gettext_pp
to allow on-the-fly charset conversion between the charset in a
message catalog and the preferred (end) user charset.  Its main
advantage about the Encode package available for recent Perl versions
is its portability, since it does not require the Unicode capabilities
of Perl that were introduced with Perl 5.6.  It fully supports UTF-8
with every Perl version and a wealth of common 8 bit encodings.  If
you have to do charset conversion with older Perl versions, then
Locale::Recode may be worth a try although it is really only a helper
library, not intended as a competitor to Encode.

Documentation
-------------

For a basic understanding of message translation in Perl with
libintl-perl you should read the perldoc of Locale::TextDomain.  Don't
bother about the documentation of the other modules in the library,
you will not need it unless you want to hack the library yourself.

In order to make use of the software, you will also need various tools
from GNU gettext [savannah](http://savannah.gnu.org/projects/gettext/). The documentation is located at [www.gnu.org](http://www.gnu.org/manual/gettext/).
You will find there a language-independent overview of
internationalization with GNU gettext, and in the Perl-specific
sections you will find details about the parser that extracts
translatable messages from your Perl sources.

Quick-Start
-----------

The subdirectory "sample" of the source distribution of libintl-perl
contains a full-fledged example for an internationalized Perl package,
including a working Makefile.  The README of that subdirectory
explains all necessary steps.

However, if you are on a recent GNU/Linux system or similar (cygwin
should also do), chances are that you can get the following example to
run:

	#! /usr/local/bin/perl -w

	use strict;

	# This assumes that the textdomain 'libc' is available on your
	# system.  Try "locate libc.mo" or "locate libc.gmo" (or
	# "find / -type f -name libc.mo" if locate is not available on
	# your system).
	#
	# By the way, the "use Locale::TextDomain (TEXTDOMAIN) is the
	# equivalent of
	#
	#      textdomain ("TEXTDOMAIN");
	#
	# in C or similar languages.
	use Locale::TextDomain ('libc');

	# The locale category LC_MESSAGES is not exported by the POSIX
	# module on older Perl versions.
	use Locale::Messages qw (LC_MESSAGES);

	use POSIX ('setlocale');

	# Set the locale according to our environment.
	setlocale (LC_MESSAGES, '');

	# This makes the assumption that your system libc defines a
	# message "No such file or directory".  Check the exact
	# spelling on your system with something like
	# "ls NON-EXISTANT".
	# Note the double underscore in front of the string.  This is
	# really a function call to the function __() that is
	# automagically imported by Locale::TextDomain into your
	# namespace.  This function takes its argument, looks up a
	# translation for it, and returns that, or the unmodified
	# string in case of failure.
	print __"No such file or directory", ".\n";

	__END__

Now run the command "locale -a" or "nlsinfo" to get a list of
available locales on your system.  Try the section "Finding locales"
in "perldoc perllocale" if you have problems.

If, for example, the locale "fr_FR" is available on your system, set
the environment variable LANG to that value, for a POSIX shell

     LANG=fr_FR
     export LANG

for the C shell

     setenv LANG fr_FR

and run your little Perl script.  It should tell you what the error
message for "No such file or directory" is in French, or whatever
language you chose.  Not a real example, because we have "stolen" a
message from a system catalog.  But it should give you the general
idea, especially if you are already familiar with gettext in C.

If you still see the English message, this does not necessarily mean a
failure, since the string is maybe not translated on your system (try
"locate libc.mo" to get a list of available translations).  Even for
the translations listed there, that particular message might be
missing.  Try a common locale like "de_DE" or "fr_FR" that are usually
fully translated then.

Your next steps should be "perldoc Locale::TextDomain", and then study
the example in the subdirectory "sample" of this distribution.

Have fun with libintl-perl!

Guido Flohr

Hi,

old versions of my modules can be found here:

	http://history.perl.org/backpan/authors/id/G/GU/GUIDO/

This is an effort to keep CPAN and its mirrors clean.

Regards,
Guido

README for libintl-perl
=======================

The package libintl-perl is an internationalization library for Perl
that aims to be compatible with the Uniforum message translations
system as implemented for example in GNU gettext.

See the file COPYING and the source code for licensing.

Requirements
------------

The library is entirely written in Perl.  It should run on every
system with a Perl5 interpreter.  The minimum required Perl version
should be 5.004.

The behavior of the package varies a little depending on the Perl
version:

- Perl 5.8 or better

Recommended.  Perl 5.8 offers maximum performance and support for
various multi-byte encodings (even more if Encode::Han is installed).
Additionally the output charset is chosen automatically according to
the information provided by I18N::Langinfo.  In fact, I18N::Langinfo
is already available for Perl 5.7 but this developer version is
probably not much in use any more.

- Perl 5.6 or better

Still offers high-performance UTF-8 handling but no support for other
multi-byte encodings unless the package Encode is installed.

- Earlier Perl versions

Full UTF-8 support but quiet slow since all conversion routines are
written in Perl.  More exactly: Encoding from 8 bit charsets into
UTF-8 is reasonably fast and usable.  Decoding UTF-8 is slow, however.

Note that these are actually the requirements for the *users* of your
software internationalized with libintl-perl.

As a maintainer of a Perl package that uses libintl-perl, you will
also need a recent version of GNU gettext (see the file README in the
subdirectory "sample/" of the source distribution of libintl-perl).
Translators of your software can basically do their job with any text
editor, but it usually makes sense for them, too, to have GNU gettext
installed.  End users of your software, or people that install an
internationalized Perl package do *not* need it, unless they want to
add a new language to your software.

Installation
------------

If libintl-perl is not installed on your system, you have to build it
from the sources, which is a lot easier than you may think.  You need
the program "make" for that and a command line shell.  No C compiler is
required.

Unpack the package in a directory of your choice, cd into that
directory and then type

     perl Makefile.PL
     make

This will build the package.  You can then run the tests with

     make test

To install the package, type

     make install

You will probably need root permissions to do that.

Of course, you can also use the CPAN module to install the package.

Feedback
--------

Send negative (and positive!) feedback to me.  Bug reports can be send
directly to me or you can use the
[RT bugtracking system](http://rt.cpan.org/ "Link to RT").

If you use libintl-perl for your project, private or public, free or
commercial, please let me know.  I am interested in such information.

If you really like (or dislike?) libintl-perl, tell the world about.
You can star it on [github](http://github.com/gflohr/libintl-perl).  You
can rate it and even write a review at
[cpanratings](http://cpanratings.perl.org/)
(search for "libintl-perl").

Design Goals
------------

The primary design goal of libintl-perl is maximum compatibility with
the gettext functions available for other programming languages.  It
is intended that programmers, translators, and end users can fully
benefit from all existing i18n tools like xgettext for message
extraction, msgfmt, msgmerge, etc. for catalog manipulation, Emacs PO
mode (or KBabel, PO-Edit, ...) for catalog editing and so on.

Another design goal is maximum portability.  The library should be
functional without any additional software but with a wide range of
Perl versions.  Wherever possible, hooks have been inserted to benefit
from advanced features in the runtime environment, but the basic
functionality should be present everywhere.

Overview
--------

The core of the library is the module Locale::gettext_pp.  It is a
pure Perl re-implementation of the module Locale::gettext available on
CPAN.  However, the XS version Locale::gettext lacks some functions
(notably plural handling and output conversion) that are already
present in Locale::gettext_pp.  Locale::gettext_pp provides the
internationalization functions that are available in your system
library (libc) or additional C libraries (for example libintl in the
case of GNU gettext).

The class Locale::Messages is an additional abstraction layer that is
prepared for dynamic switching between different gettext implementations (for
example Locale::gettext_pp and Locale::gettext).  It provides
basically the same interface as Locale::gettext_pp but in an
implementation-independent manner.

The module Locale::TextDomain is the only module that you should
actually use in your software.  It represents the message translation
system for a particular text domain (a text domain is a unique
identifier for your software package), makes use of Locale::Messages
for message translation and catalog location, and it provides
additional utility functions, for example common shortcut names for
i18n routines, tied hashes for hash-like lookups into the translation
database, and finally an interpolation mechanism suitable for
internationalized messages.

The package also contains a charset conversion library
Locale::Recode.  This library is used internally by Locale::gettext_pp
to allow on-the-fly charset conversion between the charset in a
message catalog and the preferred (end) user charset.  Its main
advantage about the Encode package available for recent Perl versions
is its portability, since it does not require the Unicode capabilities
of Perl that were introduced with Perl 5.6.  It fully supports UTF-8
with every Perl version and a wealth of common 8 bit encodings.  If
you have to do charset conversion with older Perl versions, then
Locale::Recode may be worth a try although it is really only a helper
library, not intended as a competitor to Encode.

Documentation
-------------

For a basic understanding of message translation in Perl with
libintl-perl you should read the perldoc of Locale::TextDomain.  Don't
bother about the documentation of the other modules in the library,
you will not need it unless you want to hack the library yourself.

In order to make use of the software, you will also need various tools
from GNU gettext [savannah](http://savannah.gnu.org/projects/gettext/). The documentation is located at [www.gnu.org](http://www.gnu.org/manual/gettext/).
You will find there a language-independent overview of
internationalization with GNU gettext, and in the Perl-specific
sections you will find details about the parser that extracts
translatable messages from your Perl sources.

Quick-Start
-----------

The subdirectory "sample" of the source distribution of libintl-perl
contains a full-fledged example for an internationalized Perl package,
including a working Makefile.  The README of that subdirectory
explains all necessary steps.

However, if you are on a recent GNU/Linux system or similar (cygwin
should also do), chances are that you can get the following example to
run:

	#! /usr/local/bin/perl -w

	use strict;

	# This assumes that the textdomain 'libc' is available on your
	# system.  Try "locate libc.mo" or "locate libc.gmo" (or
	# "find / -type f -name libc.mo" if locate is not available on
	# your system).
	#
	# By the way, the "use Locale::TextDomain (TEXTDOMAIN) is the
	# equivalent of
	#
	#      textdomain ("TEXTDOMAIN");
	#
	# in C or similar languages.
	use Locale::TextDomain ('libc');

	# The locale category LC_MESSAGES is not exported by the POSIX
	# module on older Perl versions.
	use Locale::Messages qw (LC_MESSAGES);

	use POSIX ('setlocale');

	# Set the locale according to our environment.
	setlocale (LC_MESSAGES, '');

	# This makes the assumption that your system libc defines a
	# message "No such file or directory".  Check the exact
	# spelling on your system with something like
	# "ls NON-EXISTANT".
	# Note the double underscore in front of the string.  This is
	# really a function call to the function __() that is
	# automagically imported by Locale::TextDomain into your
	# namespace.  This function takes its argument, looks up a
	# translation for it, and returns that, or the unmodified
	# string in case of failure.
	print __"No such file or directory", ".\n";

	__END__

Now run the command "locale -a" or "nlsinfo" to get a list of
available locales on your system.  Try the section "Finding locales"
in "perldoc perllocale" if you have problems.

If, for example, the locale "fr_FR" is available on your system, set
the environment variable LANG to that value, for a POSIX shell

     LANG=fr_FR
     export LANG

for the C shell

     setenv LANG fr_FR

and run your little Perl script.  It should tell you what the error
message for "No such file or directory" is in French, or whatever
language you chose.  Not a real example, because we have "stolen" a
message from a system catalog.  But it should give you the general
idea, especially if you are already familiar with gettext in C.

If you still see the English message, this does not necessarily mean a
failure, since the string is maybe not translated on your system (try
"locate libc.mo" to get a list of available translations).  Even for
the translations listed there, that particular message might be
missing.  Try a common locale like "de_DE" or "fr_FR" that are usually
fully translated then.

Your next steps should be "perldoc Locale::TextDomain", and then study
the example in the subdirectory "sample" of this distribution.

Have fun with libintl-perl!

Guido Flohr

Special Notes for Sun Solaris
=============================

Recent versions of Solaris ship with a libintl that is mostly compatible
with GNU gettext.  Even the plural handling functions (ngettext,
dngettext, dcngettext, ...) and output character conversion functions
(bind_textdomain_codeset) are included.

On my test system, the behavior of the Solaris version differs in one
important point from the pure Perl version or the GNU gettext version:
In a locale environment that is a regional variant of another locale
(for example "fr_CA" is a regional variant of "fr"), both the pure Perl
version from libintl-perl and the C version from GNU gettext will fall
back to translations for the superordinate message catalog ("fr") if
no special translation for the selected locale ("fr_CA") can be found.
This fallback mechanism is missing in the Solaris implementation.

This could be considered harmless, because Solaris users are probably
used to this behavior.  On the other hand, the pure Perl version of
gettext in libintl-perl aims to be as compatible as possible to the
GNU gettext implementation.  Furthermore, if the pure Perl and the
C/XS version behave differently, users may be unnecessarily confused.

If you think you can live with that little inconsistence, you are not
completely lost: Edit the toplevel Makefile.PL, in the function
WriteMakefile(), change the value for the hash slot "DIR" from
the value depending on "$result" to simply "['gettext_xs']".  If you
have a look at the source code of Makefile.PL, you will see that this
has already been prepared.

If you do this, the test suite will fail, because the above described
behavior ("fr_CA" vs. "fr" ...) is checked by the tests.  In this case,
expect the following failures:

Failed Test                    Stat Wstat Total Fail  Failed  List of Failed
-------------------------------------------------------------------------------
./tests/03bind_textdomain_codeset_xs.t        9    2  22.22%  5 9
./tests/03dcgettext_xs.t                      9    2  22.22%  3 7
./tests/03dcngettext_xs.t                    83   51  61.45%  22-31 43-83
./tests/03dgettext_xs.t                       9    2  22.22%  3 7
./tests/03dngettext_xs.t                     83   51  61.45%  22-31 43-83
./tests/03gettext_xs.t                        6    1  16.67%  3
./tests/03ngettext_xs.t                      85   51  60.00%  23-32 45-85

But even if you have installed GNU gettext, you may run into this error
when trying to compile the XS version:

"gettext_xs.xs", line 32: #error: "<libintl.h> is not GNU gettext.  Maybe you have to adjust your include path."
cc: acomp failed for gettext_xs.c
make[1]: *** [gettext_xs.o] Error 2
make[1]: Leaving directory `/root/libintl-perl-1.15/gettext_xs'
make: *** [subdirs] Error 2

What has happened here?  Have a look at the source code of <libintl.h>
that ships with GNU gettext:

/* We define an additional symbol to signal that we use the GNU
   implementation of gettext.  */
#define __USE_GNU_GETTEXT 1

...

/* We redirect the functions to those prefixed with "libintl_".  This is
   necessary, because some systems define gettext/textdomain/... in the C
   library (namely, Solaris 2.4 and newer, and GNU libc 2.0 and newer).
   If we used the unprefixed names, there would be cases where the
   definition in the C library would override the one in the libintl.so
   shared library.  Recall that on ELF systems, the symbols are looked
   up in the following order:
     1. in the executable,
     2. in the shared libraries specified on the link command line, in order,
     3. in the dependencies of the shared libraries specified on the link
        command line,
     4. in the dlopen()ed shared libraries, in the order in which they were
        dlopen()ed.
   The definition in the C library would override the one in libintl.so if
   either
     * -lc is given on the link command line and -lintl isn't, or
     * -lc is given on the link command line before -lintl, or
     * libintl.so is a dependency of a dlopen()ed shared library but not
       linked to the executable at link time.
   Since Solaris gettext() behaves differently than GNU gettext(), this
   would be unacceptable.

   The redirection happens by default through macros in C, so that &gettext
   is independent of the compilation unit, but through inline functions in
   C++, in order not to interfere with the name mangling of class fields or
   class methods called 'gettext'.  */

In brief: The GNU libraries libintl.so and libintl.a prefix all functions
with "libintl_" in order to avoid symbol name conflicts with the vanilla
Solaris verssion.  These precautions still give room to a popular
misconfiguration: If you install GNU gettext with the default prefix
"/usr/local", libraries will get installed in "/usr/local/lib", the
header files - notably <libintl.h> - will get installed in
"/usr/local/include", so far so good.  Now set the environment variable
LD_LIBRARY_PATH to "/usr/local/lib", so that the GNU version of libintl.so
will be found by the dynamic loader at runtime.  Yet, if
"/usr/local/include" comes after "/usr/include" in your C compiler's
include path, the above described trick does not work, the functions
like "gettext", "dgettext" etc. will not get re-defined to "libintl_gettext",
"libintl_dgettext" and so on.  Remember, the preprocessor trick used by
GNU gettext will change every reference to the function gettext() into
a reference to libintl_gettext() for gettext() into a definition for
libintl_gettext().  If your C compiler includes the "wrong" include file
(/usr/include/libintl.h) instead of the "correct" one
(/usr/local/include/libintl.h), your C sources will still reference
gettext() instead of libintl_gettext().  At run-time, even if the dynamic
loader considers the GNU version of libintl.so (in "/usr/local/lib"), it
will not use it, because it looks for the "wrong" symbol gettext()
instead of libintl_gettext().

Too complicated? Okay: The order for C header files for the C compiler
(actually the preprocessor) differs from the inclusion order for
libraries and this must lead to trouble.  If you understand WHY, you
will find a way to fix it.  If not, ignore the problem: Do not
build the problem, and be assured, that the pure Perl version is
fast enough.  It is very, very unlikely that using the pure Perl
instead of the XS version of will be the bottleneck of any application
you use.

Life is complicated under the sun, ain't it? ;-)

Guido

When building libintl-perl under 32 bit versions of MS-DOS, you have several
options, depending on the facilities available on your system, and on the Perl
version you use.

Cygwin Perl
===========

When using the Perl interpreter that ships with cygwin, you are in a pretty
Unix-like environment, and you should be able to build and use libintl-perl
like on ordinary operating system.

ActiveState Perl
================

By default, the XS version of libintl-perl is not built.  You will not win
a lot, by trying to build the XS version, but if you can't help, here are
the instructions that worked on my system.  Your mileage may vary, however.

C Compiler
----------

Windows does not ship with a C compiler.  Since ActiveState Perl is built
with Microsoft Visual C, you probably will not have a choice, and have to
purchase MSVC.

Building libiconv and GNU gettext
---------------------------------

The XS version of libintl-perl requires the runtime facilities provided by
GNU gettext, which in turn rely on libiconv.  You can both in source form
from ftp://ftp.gnu.org/pub/gnu.

First, unpack both the libiconv and gettext sources in a directory of your
choice, open the MS-DOS cripple shell ("cmd.exe"), and cd into the directory
where you have unpacked the libiconv sources.  There read the file
"README.woe32" or just type

    nmake -f Makefile.msvc MFLAGS=-MD DLL=1 NO_NLS=1
    nmake -f Makefile.msvc MFLAGS=-MD DLL=1 NO_NLS=1 check
    nmake -f Makefile.msvc MFLAGS=-MD DLL=1 NO_NLS=1 install

The second command line will run the test suite (you may omit this step).

Now cd to the directory where you have unpacked the gettext sources, and
read "README.woe32", or just type

    nmake -f Makefile.msvc MFLAGS=-MD DLL=1
    nmake -f Makefile.msvc MFLAGS=-MD DLL=1 check
    nmake -f Makefile.msvc MFLAGS=-MD DLL=1 install

You should now go back into the libiconv build directory, and re-build
the package again with native language support:

    nmake -f Makefile.msvc MFLAGS=-MD DLL=1 NO_NLS=1 distclean
    nmake -f Makefile.msvc MFLAGS=-MD DLL=1
    nmake -f Makefile.msvc MFLAGS=-MD DLL=1 check
    nmake -f Makefile.msvc MFLAGS=-MD DLL=1 install

You should now have the gettext and libiconv DLLs installed in "\usr\bin",
and libraries in "\usr\lib".  It should be theoretically possible to build
static versions (instead of DLLs) of both gettext and libiconv, but I
did not manage to do so here.

Build libintl-perl
------------------

The Makefile.PL provided with libintl-perl normally autodetects the presence
of the required gettext shared libraries, but this test (intentionally) fails
under Windows.  You have to bypass the mechanism by saying

    perl Makefile.PL DIR=gettext_xs

This should produce an output like this:

    Checking whether we can compile the XS version ... no
    => Cannot build the XS version of libintl-perl (see 'config.log' for
    => details).  This is harmless!
    Writing Makefile Locale::gettext_xs
    Writing Makefile for libintl-perl

Ignore the warning, that the XS version cannot be built.  It will be
built anyhow.

Now do the usual:

    nmake
    nmake test
    nmake install

Please run the testsuite!  If it fails, and you cannot sort out the reason,
re-build the module without the XS version.

Distribution
------------

If you want a binary version of libintl-perl, you either have to bundle it
with the DLLs and libraries for GNU gettext and libiconv, or you have to
build and link against static versions of the two libraries (which I didn't
manage to do).  In any case, please take care that your distribution does
not violate the licenses under which GNU gettext, libiconv, and libintl-perl
are provided! Please read the following statement by Bruno Haible,
maintainer of GNU gettext and libiconv:

  Note that DLLs created with MSVC 7.0 cannot be distributed: They depend
  on a closed-source library 'msvcr70.dll' which is not normally part of a
  Woe32 installation, therefore the distribution of such DLLs - with or
  without msvcr70.dll - would be a violation of the LGPL. This problem does
  not occur with MSVC 6.0 and earlier.

Guido Flohr <guido.flohr@cantanea.com>