(gettext.info)Temp WSI

---

Next: Temp Notes Prev: Temp catgets Up: Temp Programmers

---

Enter node , (file) or (file)node

11.6.3 Temporary - Why a single implementation
----------------------------------------------

   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 ‘libintl’ 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 ‘libintl’ + non-‘catgets’ routines.  When they port their
software to other platforms, they’re now going to have to include the
front-end (‘libintl’) code plus the back-end code (the non-‘catgets’
access routines) with their software instead of just including the
‘libintl’ 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 ‘libintl’ 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.