Hi Martin, > sc_po_check: > ------------ > > This one complains about files like lib/getopt.c not being listed as > requiring translations. OK, it has a point there. Still, of the three > possible solutions which come to my mind, none feels exactly right: > > 1. Add files, and require every translator of every module using gnulib > to re-include the same old translations, or even worse, think of similar > but different translations every time. It would be nice if the list of > files to be added in this way could be maintained by gnulib. > > 2. Drop all localizing constructs from getopt.c and accept that messages > won't be localized unless the system has a properly localized > gnu-compatible getopt library installed. Same for other, similar > replacement files, e.g. regcomp.c. > > 3. Have gnulib use a different domain, have the proper message files > imported along with the rest of gnulib into the project source tree at > pre-configure time, and have those files compiled and installed at make > time if any of the replacement files requiring them is actually used.
Yes, the current state is suboptimal. Most packages that use gnulib include files like lib/getopt.c in their list of files for POTFILES, i.e. they use approach 1. Approach 2 is strongly discouraged. There is the possibility to use approach 3, by - using the gnulib-tool options --po-base and --po-domain, - defining the DEFAULT_TEXT_DOMAIN macro in lib/Makefile.am. The PO files for gnulib will be automatically downloaded from the Translation Project's website <http://translationproject.org/domain/gnulib.html>. This approach should certainly be better documented and more used. Bruno
