Bruno Haible wrote: > The idea is that > - bison provides a set of .po / .mo files for the use of the programs at > runtime, > - bison provides an autoconf macro and automake support that copies these > .mo files from an installed bison into the package that uses bison, and > during "make install" into the LOCALEDIR used by the program. > > (This also applies to some gnulib modules; expect to see some gnulib modules > to be accompanied with po/ directories in the future.)
Wouldn't it make more sense to use a bison-runtime domain instead of an application-bison one? It might need to be versioned (e.g. bison-runtime-2.0), but having a copy for each app that uses bison seems excessive. It's unfortunate that bison doesn't have any user-side installation at the moment; it's much easier for the dcgettext model to be used for libraries, as the .mo files can just be installed along with the .a/.so.
