Re: [help-gengetopt] Internationalisation

[Tim Marston]

Hi,

On Tue, May 08, 2012 at 10:35:06AM +0200, Lorenzo Bettini wrote:
> On 02/22/2012 08:24 PM, Tim Marston wrote:
> >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.
> 
> well uniformity is quite important, isn't it?

Yes. I am happy to work on this too.

> >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.
> 
> can you make some examples?  I'm not sure I understand

OK, for example, in gtypist we have the following option:

  -s, --silent                 don't beep on errors

which gets translated based on locale. Here is the Czech version:

  -s, --silent                 při chybách nepípat

But there are other parts of the --help and --version outputs that
currently have localisation in gtypist as well. The gengetopt "purpose"
and "text" parameters would also need to provide internationalisation
support for us to not lose any localised strings. And there may be others
(I haven't checked thoroughly).

> >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.
> 
> and the corresponding Automake/Autoconf macros for detecting it
> during configure
> 
> >- 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?
> 
> how would this array be changed?

The gengetopt_args_info_help[] array contains multi-line strings that are
already formatted to wrap at 80 columns (or thereabouts). For example:

  "  -e, --max-error=FLOAT        default maximum error percentage; valid 
values \n                                 are between 0.0 and 100.0  
(default=`3.0')",

So one solution would be to wrap those string in _() and be done. The
down-side to this would be that translators would a) be able to change the
names of the short and long options, and b) be responsible for correctly
formatting their translated strings to match the way that gengetopt
formats strings.

perhaps a better solution would be to change the array, so that there are
two arrays. The first would hold the option names, e.g.:

  "-e, --max-error=FLOAT",

and the other would hold the unformatted descriptions, e.g.:

  "default maximum error percentage; valid values are between 0.0 and 100.0",

This latter string can be wrapped in _() ready for internationalisation.
But it would need to be formatted at the application's run time (not
gengetopt's). So this would also require the formatting routine to be put
in to the generated code.

> >- doing line-wrapping at runtime. Which means that line-wrapping code
> >would have to be added to the generated file.
> 
> this would require adding a wrapping function in the generated code, right?

As previously described, yes.

> >What are your thoughts? Is this something that you would want adding to
> >gengetopt?
> 
> For the moment, I cannot add any new feature to gengetopt myself:
> it's such a busy moment that I really can't work on it... especially
> if it requires to write C code (as opposite to C++ code), as in the
> case of the runtime wrapping...
> 
> Of course, if you can provide patches (and unit test cases) I'll be
> happy to collaborate :)

Great! Don't worry - I'm not expecting you to help me write any code. But
if I could bounce ideas off you occasionally, that would be great. You'd
have to confirm that the patches were up-to-standard and implemented in a
way that you're happy with as well, of course.

All the best,

-- 
Tim Marston
ed.am