Re: [help-gengetopt] Internationalisation

[Tim Marston]

Hi Lorenzo,

On Sun, Oct 20, 2013 at 05:25:35PM +0100, Tim Marston wrote:
> On 07/10/13 09:30, Lorenzo Bettini wrote:
> >> I had imagined that the API breakage that I was proposing might
> >> constitute a minor (or perhaps even major) version number increment.
> >> But do you feel that compatibility is more important than that?
> > 
> > Why don't we have a command line argument to enable
> > internationalization?  At that point the user knows that he needs to
> > change something...
> 
> That is a very good idea.

I'm going to try to make these further modifications soon.  But I just
wanted to run this past you, to make sure that you are fully aware of
what is being proposed here...

We're talking about adding a command-line switch that would basically
do two things.  Firstly, it would enable internationalisation support,
which is great.  And, as you say, explicitly enabling this via a
command-line option is a nice idea.  No problems there.

Secondly, though, it would change the format of the args_info structure
in an incompatible way.  Specifically, it would cause the following
changes to the API:

  - args_info::<option>_help would cease to exist (<option>_help_param
    and <option>_help_desc would appear in it's place)

  - gengetopt_args_info_help, gengetopt_args_detailed_help and
    gengetopt_args_full_help would suddently have *three times* as many
    entries in them (and they should be treated in groups of 3)

        (With regards to this point, I could rename the localised arrays so
        there wouldn't be a silent, but broken, compatibility.)

  - all of the strings and string arrays mentioned above, plus some
    other (gengetopt_args_info_usage, gengetopt_args_info_purpose and
    gengetopt_args_info_description) would now be invalid (NULL) at
    start-up and would now require init_args_info() to be called to be
    initialised.

It seems a bit odd to me that a simple command-line switch relating to
enabling internationalisation would change the API in such a way.  I'm
not sure this is a nice idea.  I also have reservations about the
additional code complexity and maintenance of the two separate modes of
generation (especially because they are functionally similar -- I can
imagine one being updated and not the other).

But I don't have a better solution, except for bumping the major
version number and announcing an API change.

So, I just wanted to make absolutely sure that you are OK with this
behaviour before I embark on making the changes!  Am I OK to proceed as
planned?

Kind regards,

-- 
Tim Marston
ed.am