Hi Gavin, > If possible, gnulib translations should be made without much adaptation > by the developers of the package using gnulib.
Yup. That's what was the main mistake in the approach (b) from 2008. > The main requirement > for developers is to add the bindtextdomain call with the directory > name of LOCALEDIR, which is usually $(datadir)/locale. Yes, in approach (a) this is all that you will need. > The Gnulib build system installs the translation files, so it should > be able to provide the location of the translation files to Gnulib > code automatically. Could gnulib infrastructure provide the value of > LOCALEDIR using the "datadir" configure value Yes, absolutely. > , calling "bindtextdomain" automatically as required? No, adding the actual bindtextdomain() call is something the programmer needs to do. (I don't want to play with gcc's __attribute__ ((__constructor__)) since it violates the principle of least surprise.) > I think the problem with requiring extra packages to be installed is > that it seems to against the gnulib philosophy that it is not a separate > library and does not have to be installed separately from packages that > use it. Yes, that was probably part of my thinking in 2008, and what led to the failure. > Another issue is that the translated strings may depend on the point of > time the package took its code from gnulib. Some packages may reference > strings that do not exist in newer versions of gnulib. So it makes > sense for the gnulib code import and the gnulib translations import to be > close in time together, assuming the gnulib translations are up-to-date. This too was certainly part of my thinking in 2008. I thought "100% translated" is better than "98% translated". Not realizing that the added complexity for the "100% translated" would lead to only 10% of the packages adopting the approach. Oh I hate the "worse is better" approach, because I am a perfectionist. But here at least, Linus' "keep it simple, stupid" principle is better. > If it was required for operating systems to install a separate package > containing translations for all of the gnulib translations, it is likely > that it would often not be installed. I disagree. Once GNU coreutils and GNU gettext have a dependency to this package (in a distro), it will likely be installed for most users. Thanks for your feedback. Bruno
