[PATCH v4 0/5] Support translated long option names in getopt and argp

[Vivien Kraus]

Dear glibc developers,

Thanks again for your feedback.

Le lundi 02 juin 2025 à 09:26 -0400, Carlos O'Donell a écrit :
> On 5/31/25 5:14 PM, Vivien Kraus wrote:
> > 6. I think I have to assign copyright.
> 
> Please have a look at the contribution checklist:
> https://sourceware.org/glibc/wiki/Contribution%20checklist
> 
> You can choose to assign copyright or use DCO.
> 
> If you use DCO you must post with Signed-off-by: and understand that
> you
> are attesting to the DCO.
> 
> Does that answer your questions?

Earlier in the discussion, Bruno Haible wrote that the DCO will not
apply here:

https://sourceware.org/pipermail/libc-alpha/2025-May/166992.html

That’s not really a problem, but if this is true, then I believe you
have to do something about it.

Le lundi 02 juin 2025 à 17:09 +0000, Joseph S. Myers a écrit :
> On Sat, 31 May 2025, Vivien Kraus wrote:> 
> > Le vendredi 30 mai 2025 à 16:05 +0000, Joseph Myers a écrit :
> > > I think if would be best if translated option names were only
> > > supported 
> > > when a context is specified, to avoid translations of a word also
> > > used 
> > > (and marked for translation) other than as an option name quietly
> > > changing 
> > > how a program behaves.
> > 
> > For getopt, I believe developers can enforce this rule by setting
> > opttextdomain.
> 
> I think it should be the default.  That is, if an application has 
> translated messages, but has not done anything specific to enable 
> translation of option names, it should *not* start accepting a
> translated 
> version of a single option name simply because that happens to be a
> word 
> that's also translated in a different context.

Oh, OK.  No problem.  Note that gettext cannot use a translation with
a context if it is not called with a context, but that does not change
your argument.

Thinking a bit more about the argp domain, I believe it is OK if we
don’t try and use the docstring domain for the long option names.  If
an argp parser aggregates options from different sources and different
domains, then the option name translations could clash.  If we
accepted translations from each option’s domain, then there would be
no way to solve the collisions.  If the translator is responsible to
provide a new domain with all the option names, then there is a
centralized place to solve it.

Best regards,

Vivien

Vivien Kraus (5):
  posix: allow getopt_long to match translated option names
  posix: Introduce a convenience function to translate the option name
  posix: let the getopt caller set the translation context
  argp: document translated names in --help and --usage
  posix: let the getopt caller choose the textdomain for translation

 argp/Makefile                  |  14 ++++
 argp/argp-help.c               |  63 ++++++++++++++---
 argp/argp-parse.c              |   1 +
 argp/tst-argphelp-localized.c  | 102 +++++++++++++++++++++++++++
 argp/tst-argphelp-localized.po |  18 +++++
 argp/tst-argpusage-localized.c |  82 ++++++++++++++++++++++
 manual/argp.texi               |  25 +++++--
 manual/getopt.texi             |  35 ++++++++--
 posix/Makefile                 |  13 ++++
 posix/Versions                 |   2 +-
 posix/bits/getopt_core.h       |  10 +++
 posix/getopt.c                 | 123 ++++++++++++++++++++++++++++++---
 posix/getopt_int.h             |   2 +
 posix/tstgetoptl.c             | 120 ++++++++++++++++++++++++++++++++
 posix/tstgetoptl.po            |  27 ++++++++
 15 files changed, 607 insertions(+), 30 deletions(-)
 create mode 100644 argp/tst-argphelp-localized.c
 create mode 100644 argp/tst-argphelp-localized.po
 create mode 100644 argp/tst-argpusage-localized.c
 create mode 100644 posix/tstgetoptl.c
 create mode 100644 posix/tstgetoptl.po


base-commit: af90dc572ad232d05b667c4ce218d499f066b7bc
-- 
2.49.0