Hi Miguel, > an external project would be useful anyway as > does not require a version update of neither Gettext nor Guile to start > using it
A separate project also means an independent release cycle. How are other Guile bindings organized? - guile-cairo separate project https://www.nongnu.org/guile-cairo/ - guile-gnome separate project https://www.gnu.org/software/guile-gnome/ - guile-git separate project https://gitlab.com/guile-git/guile-git - libgccjit separate project https://savannah.nongnu.org/projects/gccjit-guile/ - guile-gnutls at gnutls https://www.gnutls.org/manual/gnutls-guile.html - zeromq at zeromq http://zeromq.org/bindings:guile-binding - gmp part of guile https://gmplib.org/manual/Language-Bindings.html The majority seems to have chosen to be available as separate project. > I think the choice should have more to do with Gettext's desire as a > project to extend its code base in Guile in the future, as the Guile > library could be the foundation for new tools, or to keep C as the main > code base There are no plans to use a different implementation language for PO file manipulations. With the existing code base as a start, it is not much harder to code new functionality in C than it would be to code it in Python, guile, Java, or other languages. Gettext needs a different implementation language in other areas - such as extracting relevant information from HTML pages - and is using POSIX sh for this purpose. It's a balance between language features, portability, and ease of installation / minimization of dependencies. Bruno
