Hi, OK, the first thing I wanted to discuss was internationalisation. Reading back through the mail archives, I see it's been discussed previously. I'll try to summarise the situation, as I understand it (correct me if I miss anything or get anything wrong!).
The way I understand it, it breaks down in to three parts. 1. internationalisation of the getopt library, which is probably beyond the scope of this discussion. 2. internationalisation of gengetopt's own strings. The problem here is that, since getopt isn't currently localised, you'll end up with a mixture of english and localised errors, depending on whether they come from getopt or gengetopt. The question I have here is whether this is enough of an issue to defer internationalisation of gengetopt until something happens to getopt. 3. internationalisation of application strings. >From the point of view of gtypist this last part is really the one I'm interested in (although I'd be happy to work on the second part as well). Currently, gtypist has localisations of argument descriptions, so we'd lose them (for better of worse) by switching to gengtopt. If this is something that is seen as a good idea, it would also seem simple enough to implement. Basically it would involve: - detecting the use of gettext. This could be done via config.h or, perhaps, via a command-line argument. Then #defining _() appropriately. - wrapping application strings with _(). This would probably mean that the gengetopt_args_info_help[] array would have to be changed, which would break compatibility. I am unsure of the use-cases for this array, though. How much of a problem would this be? - doing line-wrapping at runtime. Which means that line-wrapping code would have to be added to the generated file. What are your thoughts? Is this something that you would want adding to gengetopt? -- Tim Marston ed.am _______________________________________________ Help-gengetopt mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-gengetopt
