Re: [help-gengetopt] Internationalisation

[Lorenzo Bettini]

On 05/01/2014 18:31, Tim Marston wrote:
> 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?
> 

Hi Tim

then probably I missed something when I proposed the command line
switch: if backward compatibility is broken anyway (from what I
understand), then it makes no sense to have the command line switch, we
just bump the major version number.

What is crucial though is that if no internationalization file is
available and if gettext is not part of the user's library everything is
transparent...

Would that be possible?

cheers
        Lorenzo

-- 
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book