help-gengetopt
[Top][All Lists]
Advanced

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

Re: [help-gengetopt] Internationalisation


From: Tim Marston
Subject: Re: [help-gengetopt] Internationalisation
Date: Mon, 19 Aug 2013 20:55:15 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7

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?

-- 
Tim Marston
ed.am



reply via email to

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