Dear all,

In the argparse module, the ArgumentParser.add_subparsers() method may call the _() translation function on user-provided strings. See e.g. 3.9/Lib/argparse.py:1776 and 3.9/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 3.9/Lib/argparse.py:1704 then 3.9/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.