Go to the first, previous, next, last section, table of contents.
Now it seems kind of wasteful to me to have two different systems
installed for accessing message catalogs. If we do want to remedy
catgets deficiencies why don't we try to expand catgets
(in a compatible manner) rather than implement an entirely new system.
Otherwise, we'll end up with two message catalog access systems installed
with an operating system - one set of routines for packages using GNU
gettext for their internationalization, and another set of routines
(catgets) for all other software. Bloated?
Supposing another catalog access system is implemented. Which do
we recommend? At least for Linux, we need to attract as many
software developers as possible. Hence we need to make it as easy
for them to port their software as possible. Which means supporting
catgets. We will be implementing the glocale code
within our libc, but does this mean we also have to incorporate
another message catalog access scheme within our libc as well?
And what about people who are going to be using the glocale
+ non-catgets routines. When they port their software to
other platforms, they're now going to have to include the front-end
(glocale) code plus the back-end code (the non-catgets
access routines) with their software instead of just including the
glocale code with their software.
Message catalog support is however only the tip of the iceberg.
What about the data for the other locale categories. They also have
a number of deficiencies. Are we going to abandon them as well and
develop another duplicate set of routines (should glocale
expand beyond message catalog support)?
Like many parts of Unix that can be improved upon, we're stuck with balancing compatibility with the past with useful improvements and innovations for the future.
Go to the first, previous, next, last section, table of contents.