gettext: Temp WSI

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