[bug-gettext] [RFC] Yet another language for xgettext, an idea

[Andreas Stricker]

Hello,

  ls -1 gettext-tools/src/x-*.c | wc -l
  19

19 languages and still counting...

In the last month I though about the consequences of adding yet another
language to the xgettext utility. Not even languages with more than 1%
marked share [1] are fully covered.

The first consequence is that maintaining this many languages is
tiresome, and the maintenance for languages unknown to the maintainer is
not easy.

Then there is the gettext runtime and the gettext tools. The former must
be very stable and portable, as they run everywhere, while the tools
are primary used by translators and developers.

The round trip to get a new language upstream depends on release cycles
of the whole gettext library.

Thinking of a way to solve some of this problems I found following:

There is already a small, neat internal API for all xgettext language
parsers:

EXTENSION_{LANG}
SCANNERS_{LANG}
  extract_{lang}()
  flag_table_{lang}
  format_string_{lang}
x_{lang}_keyword()
x_{lang}_extract_all()
init_flag_table_{lang}()

Each language parser provides the translations strings, translation
comments and format strings to the xgettext core. There they are processed
independent of the source language.

The static linked tables could be transformed into a runtime registry
containing structs with references to the tables and methods.
It is then possible put each language parser into a dynamical loadable
library. xgettext may load them all upon start from a directory [2] like
$libdir/xgettext/{lang}.{soext}

If this framework is available, new languages can be added and tested
without bothering the gettext project at all. They may also be placed
into different packages. They may also be linked against a parser/lexer
library or use a parser facility of the language without introducing
new dependencies to gettext. Important languages like C are still placed
and maintained within the gettext project.

The drawbacks are possible portability issues with dynamic library loading,
more complexity, and bug reports due buggy third party parsers, the need
for a stable external API and things I've probably overlooked.

In the next free slot I'll give this a try for a proof of concept.

Regards, Andy

[1] According to the TIOBE index
    http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
[2] http://www.linuxbase.org/betaspecs/fhs/fhs/ch04s06.html

signature.asc
Description: OpenPGP digital signature