Although argparse contains translatable strings, translations for those strings do not ship with Python. This means that any program that uses argparse must separately translate argparse, which is a lot of duplicated work.

Moreover, if argparse is translated downstream, it is only translated against a single version of Python. If a user uses a different version of Python, there is no guarantee that the strings (and thus the translations) will be the same.

Shipping translations for argparse together with Python would solve this issue.

As a caveat, the translations cannot be in `/usr/share/locale` or equivalent. Users may have multiple versions of Python installed, so there would be a namespace conflict.

I have created a prototype for the proposed fix here:

https://github.com/carmenbianca/argparse

I'm not a regular Python contributor, so I simply copied argparse.py out of Lib and started working on my own copy.

The changes are, all things considered, not very big. But it would add a `locale` directory in Lib, which I'm not sure is okay or not.

There would also need to be a mechanism in the build process that puts the compiled MO files in Lib/locale/*language*/LC_MESSAGES/argparse.mo.

Many modules contain translatable strings.  CPython does not ship with translations of any of them and I believe it is against policy to do so.

1. Core developers, though an international group, are not competent to create or approve translations.
2. Core developers feel that professional Python users must gain basic English proficiency.

If you want to discuss this further, please discuss on python-ideas list, possibly after trying to find previous discussions, not here. We only allowed 'official' translations of the docs about a year ago and those are done by a group separate from the core developers.