Mail Archives: djgpp/2019/06/29/23:12:39
This is a port of GNU gettext 0.20.1 to MSDOS/DJGPP.
The GNU gettext package provides the needed tools and library functions
for authors or maintainers of other packages or programs which they want
to see internationalized.
DJGPP specific changes.
=======================
- There are no user visible DJGPP specific changes to the sources.
The official GNU distribution has build-in DJGPP to some degree
but this support has ceased, so that new changes must be ported
to DJGPP. Especially for included support libraries like libxml2
and the posix specific library relocation support that has been
completely disabled by me because it makes no sense on DOS/DJGPP.
- It is important to understand that this port does not have nor will
ever provide code to identify SFN aliases that have numeric tails.
IOW, it is the user's responsability to disable numeric tail generation
on all OS where this is possible before installing packages that have
NLS support or the program compiled with this library will fail when
LFN support has been disabled. E.g.: the port will be able to find
a file like charset.alias if LFN support is enabled and it will be
able to find charset.ali if LFN support is disabled but it will never
be able to find charset~1.ali. On WIN95/98 systems and plain DOS with
DOSLFN, the user _must_ always turn off the generation of numeric tails
for 8.3 aliases the OS creats for long file names _before_ package
installation or the package will not work in a dual DOS/WIN9X (SFN/LFN)
environment (it will work on Win[9X|2K|XP] where the long file name
(charset.alias) is available but it will not work on plain DOS where an
alias like charset~1.ali will be visible instead of the 8.3 truncated
short file name, this is charset.ali).
- Due to various new issues DXE3 modules will not be provided.
- To be able to compile AND to use this port, the iconv library must be
installed. The required port is available as:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/licv116b.zip
Please do not mix libraries. This port has been compiled with the
above libraries and is supposed to be used with them. I have never
tried any of the old ports of libiconv and I have serious doubts that
it will work.
- To be able to compile your applications using the DXE3 version of the
library you will need the a port of binutils that supports resolving
multiple symbol definitions during linking. The linker provided by:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/bnu2291b.zip
and later port versions will provide these features.
- To be able to configure and compile the sources LFN support is required.
- The test suite will fail for approximately half of the checks. The
reason is that the used shell scripts do not work with the bash port.
It usually fails trying to duplicate the file descriptor of STDIN and
things like that. I do not have the time to fix all these pending
issues. The port has been tested by using it.
- The port has been compiled with NLS support enabled so you can expect
that the binaries will talk to you in your mother tongue. If you prefer
no NLS, then reconfigure the sources passing the no-nls option to the
config.bat file.
- Please note that the port does not support neither java, python nor C#
nor whatever else languages may exist that have not been ported with
DJGPP.
- Please note that the original library filenames are not SFN clean.
This concerns the following libraries:
libgettextlib.a --> libgtxtlib.a
libgettextpo.a --> libgtxtpo.a
libgettextsrc.a --> libgtxtsrc.a
The libraries have been renamed to become unique when installed on
plain DOS without LFN support or with LFN support enabled but with
numeric tails disabled.
The linker provided by:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/bnu2291b.zip
and later versions of this port provides a lib name mapping feature
that will allow to use the long library file name in makefiles but
have the libraries installed with short file names. If the linker
cannot load the library using the long file name it will try to load
a mapping file and search in it for a short file name associated to
the long file name. If the linker can load the library using the
short file it will continue linking without warning or error message.
- The produced binaries and libraries have been splitted into two packages.
The binary archive, called gtxt201b.zip, contains only those programs
and libraries together with their documentation required to be able to
provide NLS support for GNU programs that already provides their .po
translation files. All the rest of the programs and libraries together
with sources required to implement NLS support in new projects has been
packed into an archive called gtxt201a.zip. Most of the users
will only need gtxt201b.zip. Without this splitting the binary
archive would have had a size of around 41MB and the installed products
would require about 94 MB.
- The NLS controling environment variables, LANG and LANGUAGE, must been
set. The values of the two environment variables LANG and LANGUAGE
should be set like this:
LANG=xx_CC
LANGUAGE=yy:zz
in your /dir/env/DJDIR/djgpp.env.
The LANG entry is obligatory, the LANGUAGE entry may be omited.
xx, yy, zz stand for some language code while CC stands for some country
related to that language. The LANGUAGE variable allows you to select an
alternate catalog than the one stipulated by LANG. It should be noted
that LANGUAGE has always higher priority than LANG when both have been
set. It should also be noted that the LANG variable not only selects a
catalog, it also specifies the dos codepage that will be used as locale
charset. All this means that the translation strings contained in the
catalogs (.mo files) will be recoded at runtime to the dos codepage
stipulated by the value of LANG. This runtime recoding is needed because
the .mo files may have been written using a charset that is not compatible
with the charset that will be used on the machine and OS where the .mo
file contents will be displayed. The .po files of the GNU packages,
from which the .mo files are generated, are typical examples of this.
Usualy, they have been written using some ISO-8859-nn charset (an unix
charset) and shall be displayed on a DOS/WIN32 machine that uses some
dos codepage.
Some examples:
If you only want to use the catalog containing the translations for
your mother tongue (in my case the spanish translations) the above
lines will only use the LANG variable and will look like this:
LANG=es
In this case, LANG defines the translation to be used and at the same
time the locale charset (CP850 in this case) to be used for the on-the-
fly recoding of the catalog (.mo file) contents. If you want to use
the spanish (es) and german (de) catalogs the above lines will look
like this:
LANG=es
LANGUAGE=es:de
In this case a DJGPP binary that has been compiled with NLS support
will first search for the spanish translation of a string. If a
translation for that particular string can not be found in the spanish
.mo file then it will search for a german translation of that string
in the german .mo file and if a german translation of that string can
also not been found it will default to display the build-in english
string. No mather if a spanish, a german or an english build-in
string is selected, the string is always recoded to the dos codepage
stipulated by LANG. In this case:
CP850.
If you want to reverse this search order the above lines would look
like this one:
LANG=es
LANGUAGE=de:es
Now let us assume that an user wants to use the swedish catalogs on
a machine that loads codepage CP437 when it is booted. It should be
noted that the locale charset for Sweden is CP850 and not CP437. In
this case, the lines must look like this:
LANG=en_US
LANGUAGE=sv
LANG reflects the available codepage/charset and LANGUAGE selects the
wanted translation catalog. en_US means CP437. Now, the contents of
the catalog are recoded to CP437 instead to CP850 because CP437 is the
codepage used to display messages on screen. Of course, not every
combination of catalogs and locale charset (dos codepages) makes sense.
E.G.: selecting as locale charset chinese (LANG=zh_TW) and the french
translations (LANGUAGE=fr) will certainly not generate an usefull screen
output. The content of LANG is a language code. Examples are fr for
french, en_US for US english, etc. This language code is an alias for
the locale charset (codepage) to be used for runtime recoding. The
complete list of all available aliases can be found in /dev/env/DJDIR/lib/charset.alias.
This file is a table with two entries: left entry is the alias (en_US,
de_AT, etc.), right entry is the corresponding dos codepage that will
be used for that language code (alias). It should be noted that it is
also possible to select a codepage directely. E.G.: Instead of setting:
LANG=en_US
you may directely set:
LANG=CP437
This overwrites any settings in charset.alias. Please note that if
you omit the LANG environment variable, the LANGUAGE variable will
not be honored at all. Because the information about what locale
charset shall be used is needed, if LANG is omitted by the user,
LANGUAGE will be ignored and no translation will be done at all.
If for some reason you want to disable NLS, then you should comment
out the LANG variable, select 'C' as your catalog:
LANG=C
or clear it.
- This port provides NLS support. It has been configured with NLS
support enabled. If you prefer no NLS, then reconfigure the sources
passing the no-nls flag to the config.bat file.
- The port has been configured and compiled on WinXP SP3 and Win98SE.
There is no guarantee that this may be possible with any other DOS-
like OS. Due to the use of long file names it will not be possible
to configure and compile without LFN support.
All the changes done to the original distribution are documented in the
diffs file and located together with all the files needed to configure
the package (config.bat, config.sed, config.site, etc.) in the /djgpp
directory.
For further information about GNU gettext please read the info docs and
NEWS file.
Here is an extract of the NEWS file showing the user visible changes from
the last port (GNU gettext 0.19.8.1) to this one (again, please not
that the DJGPP port does not support anything else than C):
-------------------------------------------------------------------------------
Version 0.20.1 - May 2019
* Important bug fix:
- Fixed a wrong shared library versioning of libintl.so.
Version 0.20 - May 2019
* Support for reproducible builds:
- msgfmt now eliminates the POT-Creation-Date header field from .mo files.
* Improvements for translators:
- update-po target in Makefile.in.in now uses msgmerge --previous.
* Improvements for maintainers:
- msgmerge now has an option --for-msgfmt, that produces a PO file meant
for use by msgfmt only. This option saves processing time, in particular
by omitting fuzzy matching that is not useful in this situation.
- The .pot file in a 'po' directory is now erased by "make maintainer-clean".
- It is now possible to override xgettext options from the po/Makefile.in.in
through options in XGETTEXT_OPTIONS (declared in po/Makevars).
- The --intl option of the gettextize program (deprecated since 2010) is
no longer available. Instead of including the intl sources in your package,
we suggest making the libintl library an optional prerequisite of your
package. This will simplify the build system of your package.
- Accordingly, the Autoconf macro AM_GNU_GETTEXT_INTL_SUBDIR is gone as well.
* Programming languages support:
- C, C++:
xgettext now supports strings in u8"..." syntax, as specified in C11
and C++11.
- C, C++:
xgettext now supports 'p'/'P' exponent markers in number tokens, as
specified in C99 and C++17.
- C++:
xgettext now supports underscores in number tokens.
- C++:
xgettext now supports single-quotes in number tokens, as specified in
C++14.
- Shell:
o The programs 'gettext', 'ngettext' now support a --context argument.
o gettext.sh contains new function eval_pgettext and eval_npgettext
for producing translations of messages with context.
- Java:
o xgettext now supports UTF-8 encoded .properties files (a new feature
of Java 9).
o The build system and tools now support Java 9, 10, and 11. On the
other hand, support for old versions of Java (Java 5 and older,
GCJ 4.2.x and older) has been dropped.
- Perl:
o Native support for context functions (pgettext, dpgettext, dcpgettext,
npgettext, dnpgettext, dcnpgettext).
o better detection of question mark and slash as operators (as opposed
to regular expression delimiters).
- Scheme:
xgettext now parses the syntax for specialized byte vectors (#u8(...),
#vu8(...), etc.) correctly.
- Pascal:
xgettext can now extract strings from .rsj files, produced by the
Free Pascal compiler version 3.0.0 or newer.
- Vala:
xgettext now parses escape sequences in strings more accurately.
- JavaScript
xgettext now parses template literals correctly.
* Runtime behaviour:
- The interpretation of the language preferences on macOS has been fixed.
- Per-thread locales are now also supported on Solaris 11.4.
- The replacements for the printf()/fprintf()/... functions that are
provided through <libintl.h> on native Windows and NetBSD are now POSIX
compliant. There is no conflict any more between these replacements
and other possible replacements provided by gnulib or mingw.
* Libtextstyle:
- This package installs a new library 'libtextstyle', together with a new
header file <textstyle.h>. It is a library for styling text output sent
to a console or terminal emulator.
Packagers: please see the suggested packaging hints in the file PACKAGING.
-------------------------------------------------------------------------------
The port consists of the usual four packages that have been produced
using djdev205 and can be downloaded from ftp.delorie.com and mirrors
as (time stamp 2019-06-29):
Gettext 0.20.1 additional libraries and tools to create catalogs:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtxt201a.zip
Gettext 0.20.1 binaries, info and man format documentation:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtxt201b.zip
Gettext 0.20.1 dvi, html, pdf and ps format documentation:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtxt201d.zip
Gettext 0.20.1 source:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gtxt201s.zip
Send GNU gettext specific bug reports to <bug-gettext AT gnu DOT org>.
Send suggestions and bug reports concerning the DJGPP port
to comp.os.msdos.djgpp or <djgpp AT delorie DOT com>.
If you are not sure if the failure is really a gettext
failure or a djgpp specific failure, report it here and
NOT to <bug-gettext AT gnu DOT org>.
Enjoy.
Guerrero, Juan Manuel <juan DOT guerrero AT gmx DOT de>
- Raw text -