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