Translate Like a Pro | 8360 — Python argcomplete Localization, argparse Completers, Bash and Zsh Registration, Unicode and QA

Python argcomplete localization is about making an argparse-powered command-line application understandable to international users without translating the argument values that software must parse. Developers searching for Python argcomplete custom completers, Bash and Zsh tab completion, translated argparse help, mapped completion descriptions, PYTHON_ARGCOMPLETE_OK or registration failures need a practical model for the boundary between displayed explanations and machine inputs. This guide supplies that model, with tests rather than unverified promises.

Imagine a nonprofit research team cataloguing fictional weather-station data. Scientists in Brazil, Japan and Morocco share a Python command named climate-review. It accepts station IDs such as STN-104 and a stage code such as raw, checked or approved. People need intelligible help and completion descriptions in their own languages, but the project must not change stable station identifiers, silently certify data or mistake a suggested station for an analyzed dataset. The translation challenge is part language, part command design.

The quick answer is to translate the argument descriptions and candidate explanations, retain parser option names and canonical values, test callable completers and the exact shell registration mechanism, and verify both what the menu displays and what argparse receives. Work through the example, a progressive architecture, real failure scenarios, accessibility and Unicode checks, reproducible investigations, a four-week rollout and an FAQ. All examples use synthetic stations and never contact a live weather service.

What you can safely translate in Python argcomplete

Translate human-facing argparse help, error guidance and candidate descriptions after defining their meaning.
Keep values such as STN-104, raw and checked stable wherever a downstream parser or data interface expects them.
Understand that dictionary completions can provide descriptions in Zsh; do not assume Bash renders them in the same way.
Register completion for the actual executable name, and test its invoked path rather than merely the Python module.
Never let a completion callback write files, approve records or perform irreversible work.
Keep ordinary command execution authoritative: validate values, permissions and state again after selection.

Worked example: a multilingual station chooser

Argcomplete integrates with argparse. Build a parser, attach a completer to an argument action, call argcomplete.autocomplete(parser) and then use parse_args as usual. A callable completer can receive a prefix, the relevant action, a parser and the partially parsed Namespace. Returning a mapping from canonical values to descriptions provides a useful separation for Zsh. With Bash, do not rely on equivalent description rendering; test what that shell actually shows.

Our model limits the candidate data to a fixed, non-sensitive dictionary. In a real application, translations may come from catalog files or a tested localization library. A completer should read localized descriptions, not mutate source data or trigger analyses. The document intentionally does not show network retrieval or hidden side effects, because pressing Tab is not a request to transmit station records.

#!/usr/bin/env python3
# PYTHON_ARGCOMPLETE_OK
import argparse
import argcomplete

STATIONS = {
    "STN-104": "Coastal demonstration station",
    "STN-205": "Mountain demonstration station",
    "STN-306": "Urban demonstration station",
}

def station_completer(prefix, **kwargs):
    return {code: label for code, label in STATIONS.items()
            if code.startswith(prefix)}

parser = argparse.ArgumentParser(
    prog="climate-review",
    description="Inspect a synthetic station record without publishing it",
)
action = parser.add_argument("--station", help="Stable station identifier")
action.completer = station_completer
parser.add_argument("--stage", choices=["raw", "checked", "approved"],
                    help="Data review stage")
argcomplete.autocomplete(parser)
args = parser.parse_args()
print("Local preview only:", args.station, args.stage)

The comment marker in the script participates in some registration workflows, so its position and packaging matter. The sample prints a local preview, which is intentionally not a scientific quality certificate. A robust product will check whether the station exists and whether the selected stage is permitted at execution time, and it will explicitly tell the user when a result has not been published or independently verified.

The logic works best when everyone can trace four observations: the characters typed before Tab, the completion candidates returned by the Python callback, the final command-line argument and the application result. These observations are related but not interchangeable. A translator may be responsible for only the descriptions, yet should understand the other three because a fluent phrase can still direct a user toward the wrong operational choice.

Part I — understand argparse and argcomplete’s responsibilities

Argparse owns the command grammar

argparse defines options, positional arguments, subcommands, validation rules and generated help. Argcomplete works with this grammar to offer suggestions before the command is executed. The translation belongs to identifiable user-facing strings, not to the grammar by accident.

A localization file replaces –station with a translated flag while the command still expects –station. The help page then teaches a command that fails whenever a reader follows it.

Compare the generated help with the parser definition under two locales. Type each example exactly as documented, confirm parse_args accepts the same values, and retain traceable screenshots only as supplementary evidence.

Keep the parser contract versioned and write a separate glossary for visible names. If new aliases are desired, implement them intentionally in argparse and test compatibility with existing scripts.

Autocomplete occurs before regular execution

The call to argcomplete.autocomplete(parser) can handle a shell completion invocation before normal parsing. This means the program’s startup path may be exercised by ordinary Tab presses many times.

An application performs database migrations or uploads files before setting up completion. A user pressing Tab unexpectedly triggers work that belongs to an explicit command action.

Instrument startup with a harmless counter and a dry-run trace. Confirm that completion calls do not update, transmit or delete data, even when a partially parsed argument looks valid.

Design command startup so parsing and suggestion generation are cheap and side-effect free. Place mutations behind explicit parsed commands, authorization and confirmation.

Callable completer protocol

A callable completer may accept named parameters such as prefix, action, parser and parsed_args, returning strings or a mapping of strings to descriptive text. This flexibility is valuable but requires disciplined interfaces.

A copied example assumes the callback receives positional arguments in a fixed order and fails when the library supplies keyword arguments or an optional context is absent.

Write a tiny callback that accepts prefix and **kwargs. Test it directly with synthetic contexts, then in an interactive shell, checking both empty and partial prefixes.

Treat the documented keyword contract as the boundary. Avoid coupling the callback to incidental private fields that may change between installed versions.

Candidate dictionaries and descriptions

Argcomplete supports a mapping from completion strings to descriptions, which Zsh can present as contextual help. This is a natural place to distinguish a stable station code from translated explanatory prose.

The team reverses a mapping to make labels the keys. A selected localized sentence then becomes an argument, and the scientific dataset lookup fails or binds to the wrong row.

Unit-test mapping keys against a fixed set of canonical IDs and check values for readability. In Zsh, inspect both suggestion and description; in Bash, inspect the inserted token.

Build catalogs keyed by invariant station IDs. Never let a translator’s edited label become the uniqueness key for the business record.

Choices and argparse help

When an argument uses choices, argcomplete can use those values for completion without an additional callback. argparse normally displays choices in help, while metavar can change how the value slot is presented.

An editor tries to translate raw, checked and approved inside choices to improve the help display, unintentionally changing accepted values and breaking automation.

Test parse_args with canonical values and with translated words. The latter should fail unless the product deliberately supports them. Compare metavar, help prose and the choices behavior.

Use meaningful localized explanatory help and metavar rather than mutating accepted codes. If choices carry domain status, describe the definition of each state near the documentation.

Part II — reliable registration in Bash and Zsh

Executable marker and entry points

Global argcomplete workflows look for the PYTHON_ARGCOMPLETE_OK marker in an appropriate executable or destination script. Packaging through project.scripts can affect where that marker must appear.

A package runs correctly but completions never appear because the developer inserted the marker in an unrelated module rather than the installed entry point inspected by registration.

Inspect the generated executable wrapper, entry-point declaration and installed version. Test the exact installed command from a clean environment rather than only python -m locally.

Document the supported deployment route and add packaging tests that check marker placement. Do not claim a marker fixes shell registration independently of the other prerequisites.

Per-command registration

The documented register-python-argcomplete command can produce shell registration code for a specific executable name. This may be preferable to global registration when only one program needs completion.

A team adds registration for climate-review, then users call ./climate-review or a full path and find the declared name has not matched the actual invocation.

Open a new shell session, register the installed command exactly, and test plain names, relative paths and aliases separately. Distinguish a registration gap from a problem inside Python code.

Publish the exact command name supported and a verification step. Avoid blanket instructions to modify everyone’s profile until the installation path is known.

Global activation and scope

activate-global-python-argcomplete installs a shell-side activation mechanism for recognized executables. Global activation changes the completion environment more broadly than local registration and has shell-version constraints.

A guide recommends enabling global completion for every workstation without explaining installation location, the user’s scope or why completion does not start on an older Bash version.

Compare a fresh shell with the global helper enabled and disabled. Record the shell version, system path, privilege model and which executables become eligible for completion.

Choose the least surprising registration method for the audience. Document system-wide and user-local consequences and include a clean rollback procedure.

Bash version requirements

The documented global Bash integration relies on support for complete -D, which is available in Bash 4.2 and later. Some operating systems ship an older Bash by default.

A translation treats ‘Bash’ as one uniform platform and labels a failed global install as a broken Python library, despite a missing shell feature.

Read the actual BASH_VERSION value and reproduce the behavior on tested versions. Compare local executable registration with global activation in a controlled fixture.

Use version-qualified instructions, not a generic promise. Recommend a supported shell or an alternative registration path when appropriate to the user’s environment.

Zsh descriptions versus Bash display

Zsh can show argparse help strings and dictionary-supplied completion descriptions as contextual guidance. Bash completion may insert the same candidate while exposing less description UI.

A QA report claims both shells display identical Japanese explanations because one screenshot was taken in Zsh and the same candidate values exist in Bash.

Test the two shells independently, including whether users can reach the meaning in ordinary –help when completion descriptions are not presented.

Define success as equivalent valid input and accessible meaning, not pixel-identical menus across different shell interfaces.

Part III — candidate search, values and context

Prefix filtering

By default argcomplete validates whether candidates start with the typed prefix. A candidate provider may also use prefix to avoid computing irrelevant values, but these are two separate decisions.

A custom completer returns a translated display label as the candidate to match a Japanese prefix, accidentally making a natural-language phrase the parser argument.

Test prefixes against canonical IDs and against intended localized search terms. Capture the actual values returned and the final parsed Namespace for both cases.

If localized search is a requirement, implement a lookup mapping typed display terms to stable IDs and adjust validation deliberately. Document the supported matching behavior.

Custom validator contracts

The validator argument to argcomplete.autocomplete can change candidate filtering, for example allowing substring matches. This affects which candidates appear, not what the command should accept.

A substring search allows many visually similar stations, and a reviewer assumes the first match has become the approved selection because it appears at the top.

Create fixtures with overlapping suffixes and multilingual diacritics. Compare candidate ordering and uniqueness under the chosen validator and verify that typing Enter alone does not run anything.

Prefer explicit matching rules and show distinguishing codes. Apply normal execution-time validation regardless of completion policy.

parsed_args and context-sensitive completion

A custom provider can inspect values already parsed, such as a region or dataset type, to suggest relevant station identifiers. That context may be partial or inconsistent while the user is editing a command.

The application uses parsed_args.region as authoritative proof of access and leaks names from restricted projects through suggestions, even though the final command would reject access.

Test blank, malformed and reordered options, then request completion under role-restricted synthetic accounts. Inspect visible descriptions as well as returned IDs.

Use context for convenience, never as a substitute for authorization. Enforce access checks inside the provider and again when the real command executes.

Subcommands and grammar evolution

Programs can use argparse subparsers for operations such as inspect, compare and export. Completion must remain aligned with the active parser so a reader is not offered an option from the wrong command.

A translated example uses –format before a subcommand that accepts it only afterward, making tab suggestions appear defective when the real issue is command grammar.

Build a fixture matrix for each subparser and parameter position. Test examples as typed, not reconstructed from screenshots, and record the exact parser error when an input is invalid.

Publish a concise syntax table beside localized prose. Update completion tests whenever a command or subcommand contract changes.

File, directory and special completers

Argcomplete provides helpers for files and directories as well as choice-based completions. Path suggestions represent real filesystem entries and therefore need different care from controlled station-code dictionaries.

A guide translates folder names in its examples and implies that filesystem paths should change with language, causing users to look for nonexistent directories.

Create temporary directories with English, accented, CJK and space-containing filenames. Confirm returned paths remain literal and arguments resolve to the intended fixture.

Translate path explanations and prompts, not the actual existing filesystem path. Where a product supports localized virtual names, make the mapping explicit rather than assuming the shell provides it.

Part IV — translation quality and evidence

Whole-message translation

Argparse help often includes sentences with variables, optional flags and examples. English word-by-word replacement produces awkward grammar and can change the location of negation or conditions.

A translator separately edits ‘not’, ‘verified’ and ‘yet’, then the combined message misleadingly declares a dataset verified in the target language.

Use whole-message resources with named placeholders and sample rendered values. Ask reviewers to read the message in the context of a real help screen.

Translate the meaning, not fragments. Keep the status distinctions raw, checked and approved visible to learners as concepts with precise definitions.

Differentiate suggestion from certification

A listed weather station may be an eligible input, but completion cannot establish measurement quality, availability of current observations or scientific publication status.

The menu description says ‘verified station’ because it came from an old list, though the command will only load metadata for local inspection.

Separate a station’s identity, dataset quality controls and analysis publication stages. Test tooltips against real workflow definitions rather than marketing language.

Use ‘available as an input option’ for suggestions and reserve ‘checked’ or ‘approved’ for states supported by an authoritative record.

Terminology in global scientific teams

The same English word can carry distinct meanings across scientific protocols. Review, approved, validated and calibrated are not interchangeable simply because they sound positive.

A Japanese localization uses the word associated with instrument calibration for a label intended to mean metadata review, confusing analysts about what the step guarantees.

Maintain a glossary with domain definitions, non-examples and bilingual sample sentences. Have data stewards approve high-consequence stage descriptions.

Keep candidate codes short and invariant, but enrich help and documentation with the full operational distinction that users need to make decisions.

Plurality and locale formatting

Dynamic help may mention counts, dates, measurement units or ranges. Those require locale-aware formatting and grammatical agreement, which a simple substitution table cannot guarantee.

A message says ‘1 stations found’ or displays a decimal separator that conflicts with a number parser expecting a dot, prompting copy-and-paste errors.

Exercise zero, one and several candidate counts and test negative, fractional and large measurements. Distinguish display formatting from canonical CLI input formatting.

Use a tested localization layer for plurals and dates while documenting invariant command syntax. Never let a pretty number silently alter a required machine argument.

Accessible command help

Some readers use completion without detailed popups, while others rely on assistive technology or remote terminals. Good translation therefore cannot live exclusively in a Zsh description column.

A team accepts a command because descriptions look excellent in one terminal theme, even though ordinary help lacks them and Bash users see only cryptic codes.

Ask testers to complete tasks with –help only, without descriptions, and with keyboard navigation. Measure whether they can explain the status codes correctly.

Make localized examples and error messages independently discoverable. Treat completion descriptions as useful enhancement, not the only accessible explanation.

Part V — safe runtime and performance engineering

Side effects and Python imports

Argcomplete can run the Python process repeatedly while the user is editing one command line. Module-level imports or initializers that contact services or write files can therefore create hidden work.

Pressing Tab launches a data refresh, and the team mistakes repeated tasks for user demand. The localization work has inadvertently made an unsafe startup path more visible.

Run the executable with side-effect monitors and a disposable test directory. Assert that repeated completions leave source fixtures, locks and network state unchanged.

Keep imports inexpensive and defer all state-changing operations until after ordinary argument parsing and explicit action selection.

Network-backed candidate providers

A completer may fetch resource names from a network service, but every request increases latency and the opportunity to disclose account-specific data. A user can press Tab many times per minute.

A provider downloads an entire private dataset for one partial prefix and logs its identifiers to debug errors. The visible list may be correct while the underlying behavior is unacceptable.

Mock network responses for timeout, unauthorized, empty, stale and partial data. Record elapsed time, returned count and leakage checks without storing real customer information.

Bound requests, sanitize data, cache where appropriate and preserve separate messages for an empty search and an unavailable service.

Warnings and broken interaction

The library provides a warn helper because normal stdout and stderr can be suppressed during completion. Warnings may interrupt a user’s line-editing flow and should be reserved for actionable problems.

A translated callback prints progress output every time it searches, corrupting the interactive prompt or burying the meaningful warning in repetitive text.

Simulate a failed login and a recoverable timeout. Check that any warning is comprehensible, does not contain secrets and avoids claiming a result that could not be loaded.

Use the documented warning mechanism for genuine blockers, sparingly. Put longer troubleshooting guidance in normal help or documentation instead of every Tab event.

Secrets and sensitive parameters

Environment variables, authentication tokens and protected identifiers may appear in parsed context. Completers should not expose their content or include secrets in candidate labels.

A generic environment-variable completer offers sensitive configuration keys and values to an unauthorized terminal session, then a support screenshot preserves them.

Create fake secrets and verify that sensitive arguments either suppress completion or avoid revealing protected values. Review both output and diagnostic logs.

Use an appropriate suppression strategy for confidential inputs. Avoid describing token-shaped data as harmless just because the shell can display it.

Cache freshness and execution checks

Cached station IDs can make completion responsive, but a cached suggestion is not proof that a station is still available or that a dataset has passed today’s review.

An operator selects a formerly valid station from an offline cache. The command accepts it without checking the current scientific registry and produces a misleading success message.

Delete or revoke an item between completion and execution in a synthetic fixture. Assert that the command reports stale input accurately and does not publish data.

Validate identifiers, access rights and domain state on execution. Describe local preparation separately from remote acceptance, review and publication.

Part VI — Unicode, release and long-term trust

Unicode normalization

Unicode strings may be visually identical but represented by different code points, as with precomposed and combining accents. Candidate matching and shell quoting need deliberate tests.

Two scientific station aliases look identical to reviewers but compare differently, and an implementation ‘fix’ changes stable IDs behind the scenes.

Build fixtures with normalized and decomposed accents, compare actual code points and preserve canonical IDs. Watch what the parser finally receives.

Normalize human search terms only under an explicit policy; do not silently rewrite externally defined identifiers.

Japanese and Arabic contexts

CJK display widths and bidirectional text can change how labels appear in Bash or Zsh menus. ASCII station codes mixed with Arabic descriptions may visually shift their associations.

A translated screenshot makes STN-205 appear attached to the explanation for STN-306, so a researcher selects the wrong dataset.

Ask fluent users to match codes to descriptions in narrow terminal windows. Test both actual shell rendering and the mapping returned by the callback.

Keep distinctive codes and short descriptors clear. Treat terminal layout as a usability issue requiring real-user verification, not a translator-only problem.

Quoting paths and spaces

Argcomplete may help produce filesystem paths and user-supplied values containing spaces or punctuation. A correct visible suggestion must survive shell quoting as exactly one argument where intended.

An example displays a folder named ‘coastal samples’, yet the shell passes two arguments and the script accidentally reads a different file.

Capture argv for filenames containing spaces, quotes, brackets and Unicode. Test in the exact supported Bash and Zsh releases.

Use safe path handling and executable tests rather than hand-waving about quoting. Teach readers that visible text and argument boundaries are separate concerns.

Version pinning and maintenance

Argcomplete, Python and the shell each have versions that matter. A tutorial based on a successful local test may go stale when packaged differently or deployed on an older workstation.

A release note promises universal support for every shell after a single Zsh test, contradicting the maintainers’ stated support scope.

Record Python version, argcomplete version, shell version, installation route and test date. Run tests again when dependencies or entry points change.

Keep public statements version-qualified and link primary documentation. Avoid representing community-contributed shell adaptations as identical to maintained Bash/Zsh support.

Evidence and reproducibility

A trustworthy multilingual CLI release needs more than a screenshot. It needs the expected candidate, displayed description, selected text, parsed Namespace and application outcome for every tested locale.

The team discovers an error only after publication because no one kept the actual arguments returned by the shell. Translation review passed, yet scientific output labels are wrong.

Create sanitized golden fixtures and acceptance logs using fake station IDs. Require technical and language reviewers to validate them independently.

Preserve the proof that the product tells the same truthful story across help, completion, parsing and execution.

Practical investigations: reproduce failures before releasing translations

1. A description becomes a parser value

Reverse the value-to-description mapping deliberately for one station. Compare the Zsh menu with the parsed Namespace after selection. Restore the mapping, then assert that every proposed station code matches the synthetic registry even when the displayed explanation changes language.

For an acceptance record, write down the input prefix, actual candidates, visible explanations, selected text, parsed Namespace and execution outcome. Include shell and Python versions, the locale and the installation method. The exercise passes only when the application receives the intended canonical values and the human wording makes no promise unsupported by the result.

2. A package script lacks its marker

Install an editable package with a project.scripts entry point and inspect the wrapper used by completion. Move PYTHON_ARGCOMPLETE_OK to the appropriate destination script and compare per-command and global activation. Record which exact invocation names are recognized.

3. Two different invocations

Register climate-review by name and attempt ./climate-review and an absolute path from a new shell. Check what is and is not completed. This is an installation contract question, not evidence of a broken translation resource.

4. A hidden Bash prerequisite

In a disposable environment, compare global activation on compatible Bash with a version lacking complete -D. Preserve a version-qualified note and offer a tested alternative rather than copying a command whose shell prerequisite is absent.

5. A Zsh description is missing in Bash

Provide the same mapping of three station IDs to Japanese descriptions. Test in both shells and distinguish candidate insertion from contextual help display. Ensure –help remains understandable when descriptions are not shown.

6. Untrusted completion prefix

Use prefix strings containing brackets, spaces, accents and shell metacharacters. Assert that the Python provider returns the expected values and that no unescaped input becomes an unintended shell command.

7. A stale station disappears

Offer STN-205 from a mock cache, revoke it before Enter, then run the normal command. It should reject or revalidate the station and clearly distinguish obsolete input from a transport error.

8. A callback causes hidden work

Create an instrumented fake upload function that increments a counter. Press Tab repeatedly and prove the counter remains zero. Move mutation behind explicit action logic if any initialization path triggers it.

9. A multilingual zero-result state

Compare a genuine empty search with timeout and permission failure. Read their Spanish and Japanese messages aloud to domain reviewers. None should assert that the record does not exist when it simply could not be fetched.

10. An assistive workflow

Test without color, without Zsh description columns and with narrow terminal widths. Ask a new user to distinguish raw from checked and approved using help and safe error messages, not a rich tooltip alone.

A multilingual test matrix

Condition	Evidence to retain
Bash with local registration	Registered name, inserted token, accepted argument
Zsh with descriptions	Displayed explanation and canonical candidate mapping
Global activation	Marker placement, shell version and activation state
Python packaging	Entry-point destination and import-time side effects
CJK and RTL	Readability of codes beside localized descriptions
Unavailable provider	Distinct timeout, empty and permission states
Stale or revoked ID	Execution-time rejection and accurate message
Non-interactive invocation	Normal argparse behavior without shell completion

A four-week implementation sequence

Week 1 — document the grammar

Read the official argcomplete and argparse references. List the supported executable names, options, choices and subparsers. Build a harmless Python station registry and define canonical value versus description. Decide whether Bash and Zsh require the same input behavior even when they show different help details.

Week 2 — build controlled completers

Implement one static mapping and one context-sensitive callback. Add unit tests for prefixes, mapping keys, Namespace values, a genuine zero-match search and a simulated failing provider. Confirm that tab-completion requests cause no mutations or outgoing requests unless a read-only lookup is explicitly intended.

Week 3 — international and shell QA

Run the installed entry point in supported Bash and Zsh versions. Test Japanese and Arabic descriptions, combining marks, long labels, spaces, session profiles and shell registration. Ask new users what each status means and compare their understanding to the scientific workflow.

Week 4 — sign-off and release

Fix defects in the candidate contract, help text or error distinctions. Record a sanitized acceptance matrix, have a domain expert check research-stage claims and a developer verify parser equivalence, and ship only supported compatibility promises. Preserve a rollback route for completion registration if the deployment fails.

Frequently asked questions

What is Python argcomplete?

It is a library that adds extensible shell tab completion to applications using argparse. It suggests possible command inputs before ordinary execution; it does not replace input validation or scientific review.

Can I return translated text from a completer?

Yes as descriptive metadata in an appropriate mapping, while keeping mapping keys as accepted candidate values. In Zsh, descriptions can be displayed next to suggestions. Test the actual behavior of Bash separately.

Why does the installed command complete differently from python -m?

Shell registration, entry-point scripts, marker placement and invocation names can differ. Inspect the installed executable and the documented activation mode rather than assuming every command path shares the same registration.

Is global completion always better?

No. It broadens integration and depends on shell support, packaging and the user’s environment. Per-command registration can be easier to understand and scope for a single tool.

Can a callback use parsed_args?

Yes, to guide suggestions based on previously provided options. That context is partial and should not be treated as authorization or a final source of truth.

Can the library complete Japanese filenames?

It can offer Unicode path values through suitable completers, but correct behavior depends on shell, filesystem and quoting. Test realistic filenames and preserve literal paths instead of translating them.

Why did a warning disappear?

Completion can suppress ordinary output streams. Use documented warning facilities for meaningful failures and inspect the supported shell integration if messages are invisible.

Does selecting approved certify a dataset?

No. It only inserts a candidate value. The application must check permissions, data quality and current state when it executes and may still reject the request.

What shells are officially supported?

The documentation identifies Bash and Zsh as maintained targets and points to community or contributed approaches for other shells. State support based on the version and integration actually tested.

When is the localization ready to ship?

When help and descriptions are comprehensible, canonical candidate values are unchanged, registration works in supported deployments, dangerous side effects are absent and execution-time validation remains authoritative.

Primary references and connected translation study

Conclusion — meaningful suggestions without changing scientific meaning

A professional argcomplete localization keeps a Python CLI’s grammar and data values stable while helping international users understand those values. The strongest practice is not to translate everything visible indiscriminately; it is to trace each string to its owner, test the shell adapter, protect execution-time checks and describe outcomes precisely. When candidates, help text, parsed arguments and recorded results agree, the international tool becomes easier to trust.