[help-gengetopt] Internationalisation

[Tim Marston]

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