[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [help-gengetopt] Internationalisation

From: Lorenzo Bettini
Subject: Re: [help-gengetopt] Internationalisation
Date: Sun, 25 Aug 2013 13:06:41 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8

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

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

   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

   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

   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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]