As a result of last week's discussions, it's becoming clear to me that

  - gettext's glocale is a good starting point for this project. The
    LGPL license is apparently OK. There's a large overlap of functionality.
    And the architecture (runtime + a cooker) fits as well.

  - The project - with the support for CLDR and the setter APIs - is
    larger than what I had initially thought. As a result, I'm reconsidering
    the infrastructure.

* Who volunteers to contribute code or documentation to the project?

* Can it be a GNU project or part of a GNU gettext?

  I would very much like it to be a GNU project, so that GNU gettext can
  use it. (msggrep for example is hardly usable, because we don't have
  a gl_regex function yet. glocale will fix this.)

  When it is part of GNU gettext, all contributors need to sign papers
  giving the FSF the copyright over their contribution. If it's a separate
  project, the contributors can keep their copyrights, but it's harder for
  the project to play a central role in GNU.

* Should it be part of GNU gettext or separate?

  Should it have a distribution directory, a web site etc. of its own?

  The link between glocale and gettext is quite weak: just the 4 functions
  from glocale/libintl.h. But:

  If it's part of GNU gettext, it will find its way into Linux distributions
  rather easily. Otherwise, it will be GNOME which "drags" it into the distros.

  If it's part of GNU gettext, the sharing of some libintl files and
  other infrastructure is easier.

  It it's part of GNU gettext, it will be easier to install on non-glibc
  systems. If it's separate, people will need to build and install
  1. gettext (for the tools), 2. glocale (for libglocale), 3. gettext again
  (so that msggrep works better).

  What's your opinion?

* What shall be the name of the library? Is "glocale" OK with everyone?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]