Dear all,

In the `argparse` module, the `ArgumentParser.add_subparsers()` method may call the `_()` translation function on user-provided strings. See e.g. Lib/argparse.py:1776 and Lib/argparse.py:L1777:

    def add_subparsers(self, **kwargs):
        # [...]
        if 'title' in kwargs or 'description' in kwargs:
            title = _(kwargs.pop('title', 'subcommands'))
            description = _(kwargs.pop('description', None))

When elements `'title'` and/or `'description'` are set in `kwargs`, they will be popped from the dictionary and then fed to `_()`. However, these are user-provided strings, and it seems to me that translating them should be the user's responsibility. This seems to be the expected behavior for all other user-provided strings in the `argparse` module: see e.g. the `ArgumentParser`'s `description` parameter (in Lib/argparse.py:1704 then Lib/argparse.py:1312), which never gets translated by the `argparse` module.

However, the default title string `'subcommands'` should still be localized. Therefore, I'd suggest restricting the call to `_()` to this string only, as in the following:

            title = kwargs.pop('title', _('subcommands'))
            description = kwargs.pop('description', None)

I'll submit a pull request with this change.

Kind regards,
Jérémie.

Jérémie, what does the doc say about translation?  This will likely determine whether the is a bug report or a future-version-only enhancement request.

The PR changes the two lines as indicated above and the CLA is signed.  A blurb will be needed if this is to me merged.  (Not my decision.)

Hi Terry,

Thanks for the feedback!

I've just added a blurb to the PR.

Regarding the issue type, even though this is indeed translation-related, I'd lean toward a bug report rather than an enhancement request: the fact that user-provided strings get fed to the localization function by the `argparse` module is contrary to the expected behavior, and thus should qualify as a bug.

However, since this is very minor, I'm totally fine with this being applied only to future versions!

Thanks again!

Kind regards,
Jérémie.

'bug', for the tracker, mean a divergence between implementation and doc. Hence my question about the current doc.  We could decide that either is wrong and should be changed.

A change to meet 'expectations' and fix a 'design bug' is an enhancement.

Hi,

Thank you for the clarification!

In fact, I'm afraid the localization feature of `argparse` is undocumented. (At least, I couldn't find anything about it in the documentation.) A hint that modules should only take care of their own strings can however be inferred from <https://docs.python.org/3/library/gettext.html#deferred-translations>: “In most coding situations, strings are translated where they are coded.”

But the fact remains that the `argparse` module deals with user-provided strings in a non-consistent way: all other user-provided strings (such as the `usage`, `description`, or `epilog` parameters to `ArgumentParser`'s constructor, for instance) are not translated by `argparse` (leaving this responsibility with the caller); only the `title` and `description` parameters to `ArgumentParser.add_subparsers()` will be translated if provided.

This behavior discrepancy is what prompted me to report this as a bug in the first place, but since this is an undocumented feature anyway, I'm perfectly fine with this being categorized as an enhancement instead.

Kind regards,
Jérémie.