Re: Internationalisation

Hi Tim

yes, I think that it all should be backward compatible, even at the cost 
of adding new stuff...  I think that a user should not be required to 
change nothing in his own code if he is not interested in 
internationalization.  If one wants internationalization, then he should 
add additional initialization calls in his own code.

What do you think
	Lorenzo

On 19/08/2013 21:55, Tim Marston wrote:
> Hi Lorenzo,
>
> On 12/07/13 18:05, Lorenzo Bettini wrote:
>> I'll try to get back to you by the end of July.
>
> Just pinging you again.  :o)
>
>> In general it would be great if we don't break backward compatibility...
>
> Yes, I agree completely.  The problems are as follows:
>
> - gengetopt_args_info_usage
>    gengetopt_args_info_purpose
>    gengetopt_args_info_description
>
>    These strings are no longer statically initialised, but are
>    dynamically initialised during the required call to
>    init_args_info().  Also, they don't include the spaces and newlines
>    required for them to be displayed correctly, with wrapping, if they
>    are simply printed to stdout.
>
>    So, in summary, there are now the additional requirements that:
>     a) init_args_info() is called prior to use, and
>     b) that string wrapping be done manually on the strings, at runtime,
>        when they are being displayed.
>
> - gengetopt_args_info_help
>    gengetopt_args_detailed_help
>    gengetopt_args_full_help
>
>    All of the above that is true of the usage, purpose and description
>    string pointers is also true of these arrays.  But, additionally,
>    these arrays are now generated in groups of three (i.e., there are
>    three times as many entries as before).
>
>    So, in summary, and in addition to the two previous requirements, a)
>    and b), there is also the additional requirement that:
>     c) the strings are used in groups of three
>
> - args_info::<option>_help
>
>    This is now stored as two separate strings, <option>_help_param and
>    <option>_help_desc.  So we couldn't be backwards compatible with out
>    also generating a (now redundant and otherwise unused) <option>_help
>    string.
>
>    But even if we did this, the same requirements a) and b) would apply.
>
> Would you still prefer to make these strings silently compatible with
> existing software, given the changes?
>