Translate Like a Pro | 10730 — Linkerd CLI Localization: Check, Inject, Viz, Traffic Metrics, Identity and Unicode QA

Linkerd CLI localization is the work of translating service-mesh instructions without changing how Kubernetes operators install, check, inspect or troubleshoot their applications. Readers searching for a Linkerd CLI translation guide need more than an English-to-another-language command glossary. They need to distinguish `linkerd check`, `linkerd inject`, `linkerd viz stat`, `linkerd viz tap`, identity inspection and deployment changes, and they need to know which strings must remain executable.

The important problem is a boundary between a human explanation and a machine action. A translator can improve a description of why a service proxy is injected, but must not translate `linkerd`, a subcommand, a Kubernetes resource name or a flag into an attractive sentence that somebody then copies into a shell. A message saying that health checks passed is not a promise that traffic is secure or that an application can serve every request.

This world-facing tutorial explains how to write multilingual Linkerd runbooks, training materials and operations handovers that remain technically useful. It follows the official Linkerd CLI and Viz concepts, uses fictional examples rather than claims about a live cluster, and separates inspection from changes. The goal is understandable language with reliable evidence: operators should be able to identify a target, run a documented action with authorization, interpret its result and know when to stop.

Choose the exact cluster or workspace, release and permissions before interpreting an instruction.
Keep command names, flags, resource identifiers, paths, API fields and structured-output keys literal.
Translate purpose, prerequisites, safety boundaries, status interpretation and next steps naturally.
Separate observation and simulation from operations that apply, upgrade, remove or expose resources.
Use synthetic examples and redacted evidence, then verify the real release against official documentation.
Review Unicode, right-to-left display, keyboard copy and screen-reader clarity before distribution.

What this guide covers — and what it does not

The scope here is Linkerd’s own CLI and its Viz extension: health checks, proxy injection, workload traffic observations, mutual-TLS identity, authorization and maintenance. It is not a general treatment of Kubernetes, Istio, Cilium networking or translating application UI labels. The central learning goal is to make a reader capable of explaining an operation with its limitations. Someone encountering Linkerd for the first time should find a useful route into the topic, while an experienced engineer should find the terminology specific enough for an incident handover.

How to read a technical command when two languages are involved

Read each example at two levels. The code is a precise instruction to a machine and must remain exact. The adjacent explanation is a teaching aid to a person and should be idiomatic in the reader’s language. If a term such as status or config is also an actual subcommand, distinguish the literal token from a general description of state. Do not alter punctuation inside shell commands merely because the target language uses different quotation marks or spacing conventions.

Start with purpose, target, authority and expected evidence. Purpose explains why a person wants this information. Target identifies the environment, object and namespace or project. Authority clarifies whether the action is read-only or may change something. Evidence defines the difference between a hypothesis and an observed result. This four-part method keeps multilingual instructions accurate without demanding that every reader already know the vocabulary of Linkerd.

A practical command-by-command guide

1. Establish a trustworthy target

A command reference is useful only when the reader knows which CLI version and which cluster are involved. The executable and control plane can evolve independently, so record the context, namespace and version before translating instructions. A table headed simply ‘version’ without saying client or control plane can conceal a consequential compatibility issue.

linkerd version

Imagine a training handout translated for two regional operations teams. One team uses a different cluster context. The translated sentence should require confirming the target environment before interpreting a successful command as evidence about production.

An efficient way to review this instruction is to read the command from left to right, name the object to which it applies, and then state the expected observation in a separate sentence. For Linkerd CLI, that order matters: a correct token sequence can still lead a person toward the wrong conclusion if the surrounding language confuses a local preparation step with a remote change. Keep the source output alongside the translated explanation so colleagues who do not share a first language can verify the same fact.

Common translation error: Avoid the claim that installing a new local binary also upgrades the running control plane. A revised sentence should name the actual observation, not the conclusion the author wishes were true. If a source is ambiguous, keep that uncertainty visible until the team can check the relevant versioned documentation or system evidence.

2. Pre-installation checks

The pre-installation check asks whether prerequisites look suitable before the mesh control plane is installed. It is a readiness assessment, not an installation step and not a certification of application security. Translate ‘pre’ into a complete phrase such as ‘checks required before installing’ while keeping the literal flag.

Exact reference token: linkerd check --pre. Keep this spelling unchanged in any localized example.

In a classroom example, the learner sees a prerequisite failure about permissions. A faithful localized explanation points to the missing permission rather than recommending a broad administrative role as the automatic solution.

A multilingual team should be able to answer four questions without opening a second document: which environment is selected, what is the command trying to establish, what output would justify the conclusion, and what action would follow if the result were different? These questions make translation more useful than a bilingual word list. They also prevent a support agent from taking the most dramatic possible interpretation of a small observation. In Linkerd CLI documentation, the safest phrasing usually names the boundary of the evidence.

Common translation error: Do not change ‘pre-installation checks completed’ into ‘Linkerd is now installed’. A revised sentence should name the actual observation, not the conclusion the author wishes were true. If a source is ambiguous, keep that uncertainty visible until the team can check the relevant versioned documentation or system evidence.

3. Read the control-plane check

The regular check examines an installed Linkerd environment and reports categories of checks. Individual successes and failures must remain visible. A heading that turns a failure into a ‘warning’ may change a person’s willingness to deploy. Keep check names intact as source evidence and explain them separately.

linkerd check

Suppose a report shows Kubernetes API access working but another category failing. The localized summary should identify both, because a partially healthy installation is not equivalent to a fully healthy environment.

This topic rewards concrete language rather than stylish abbreviation. Write the subject of the sentence explicitly: a client, a control plane, a proxy, a resource, a file or a network path. Then write the predicate with the correct uncertainty: reported, requested, generated, applied, observed or confirmed. A reader should not have to infer whether a command reads existing state or starts a new operation. Avoid casual synonyms when their everyday meaning does not match the system’s behavior.

Common translation error: Never replace an exit-code failure with a friendly green icon simply because most checks succeeded. A revised sentence should name the actual observation, not the conclusion the author wishes were true. If a source is ambiguous, keep that uncertainty visible until the team can check the relevant versioned documentation or system evidence.

4. Separate generating manifests from applying them

Linkerd commands can output Kubernetes manifests that a separate tool applies. That is a different operation from silently changing the cluster. Explain any pipe between commands so the reader understands both halves of the workflow and who holds write access.

Exact reference token: linkerd install. Keep this spelling unchanged in any localized example.

A fictional operator reviews generated YAML in version control before a designated administrator applies it. The translation should preserve that approval boundary and not collapse generation, review and deployment into one verb.

For teaching, ask one reader to follow the instructions literally while a second reader watches for hidden assumptions. The observer should mark every point where a default, permission, input path or release version is needed to understand the result. Translate those assumptions into normal prose before the command is given. This is especially valuable for an international audience because what feels obvious to an experienced operator in one office may be completely unfamiliar to a new colleague elsewhere.

Common translation error: A statement that ‘the CLI installed everything’ may be misleading when the command only produced YAML. A revised sentence should name the actual observation, not the conclusion the author wishes were true. If a source is ambiguous, keep that uncertainty visible until the team can check the relevant versioned documentation or system evidence.

5. Explain sidecar injection

Injection prepares workload specifications to include the Linkerd data-plane proxy. It does not mean the application image itself has been translated, nor does it prove the application has restarted or accepted traffic. The localized instruction should identify the configuration being transformed and the later deployment action.

linkerd inject

A sample deployment called web-demo is introduced in plain English, with its literal YAML name left unchanged. The learner reads what proxy injection changes before applying a reviewed manifest.

The most reliable editorial habit is to distinguish the intention of a command from the outcome of running it. Saying an operator ‘attempts to inspect’ a resource is different from claiming that the inspection produced the expected evidence. If an example is invented for education, say so; if a diagnostic came from an actual system, keep its unmodified record in a controlled location. Readers should be able to reproduce the reasoning without believing that a fictional success message describes their own environment.

Common translation error: Do not equate ‘injected’ with ‘running correctly’ or ‘automatically secure in every respect’. A revised sentence should name the actual observation, not the conclusion the author wishes were true. If a source is ambiguous, keep that uncertainty visible until the team can check the relevant versioned documentation or system evidence.

6. Remove annotations and proxy configuration carefully

The inverse transformation helps produce workload specifications without Linkerd injection settings. This requires more thought than translating ‘undo’: deployed workloads may still be operating until a rollout occurs. The reader must distinguish a file transformation from a change already visible in a running cluster.

Exact reference token: linkerd uninject. Keep this spelling unchanged in any localized example.

In a migration walkthrough, the team prepares an un-injected manifest for comparison and uses a separate approval to make the workload change. Language that respects this sequence prevents premature conclusions.

Terminology consistency is important here, but consistency does not mean choosing the same everyday translation for every technical use of a word. Explain the concept on its first appearance and then use a concise equivalent alongside the exact token. When a status is inconclusive, say what additional observation would be needed. That approach gives beginners a route to understanding and gives experts enough precision to recognize where a conclusion might be too broad.

Common translation error: Do not tell readers that an uninject command immediately removes every live proxy. A revised sentence should name the actual observation, not the conclusion the author wishes were true. If a source is ambiguous, keep that uncertainty visible until the team can check the relevant versioned documentation or system evidence.

7. Identify data-plane and control-plane roles

The control plane coordinates mesh functions while data-plane proxies handle per-workload traffic. A proxy-focused check concerns those workloads, not an abstract health grade for the whole business service. Preserve labels naming particular pods and namespaces; translating them could prevent later matching with incident records.

linkerd check --proxy

A learner compares a control-plane check and a namespace-specific proxy check. The explanation should spell out why the two views can differ without implying that the CLI is contradictory.

There is also a human-factors question. An instruction may be correct yet unsafe if the translated document hides consequences below a screen of prose. Place scope, write permissions, sensitive-data handling and possible user impact before a potentially disruptive command. In a troubleshooting context, make the low-risk checks easy to find first. A good localized guide helps its reader choose the next responsible action; it does not merely make a dangerous action sound friendly.

Common translation error: A clean control plane report does not necessarily establish every application proxy is healthy. A revised sentence should name the actual observation, not the conclusion the author wishes were true. If a source is ambiguous, keep that uncertainty visible until the team can check the relevant versioned documentation or system evidence.

8. Check the Viz extension separately

Linkerd Viz supplies traffic measurement and observation capabilities. Its installation and permissions are not identical to the core mesh. Explain an unavailable Viz result as an observation capability issue unless there is separate evidence of application failure.

Exact reference token: linkerd viz check. Keep this spelling unchanged in any localized example.

Imagine a new cluster where Linkerd proxies are working but the Viz extension was intentionally omitted. A faithful translation states what the command cannot observe without assuming that all network traffic has stopped.

A robust review includes a reverse explanation: after reading the translated paragraph, another person should be able to describe the original command and its limits without guessing. If their explanation adds guarantees, omits a namespace or changes a status category, revise the text. Test code blocks by copying them as plain text and comparing them with the authoritative original. This simple practice catches a surprising range of errors caused by quotation marks, whitespace, rendering and localized punctuation.

Common translation error: Do not convert ‘Viz unavailable’ into ‘Linkerd unavailable’. A revised sentence should name the actual observation, not the conclusion the author wishes were true. If a source is ambiguous, keep that uncertainty visible until the team can check the relevant versioned documentation or system evidence.

9. Interpret traffic statistics

Traffic statistics can report request rates, latency and success measures for selected resources over specified windows. Such summaries depend on the target, collection period and measurement coverage. Localization must keep units, decimals and metric labels unambiguous across regions.

linkerd viz stat

A fictional dashboard compares a thirty-second window with a ten-minute window. A translated sentence must not imply that the different values reveal a new outage without considering the observation period.

When creating examples, use a deliberately fictional environment and explain what real-world evidence would be different. Synthetic names are safer for readers than internal hostnames, but they should still look structurally valid. Put a sentence near the sample that identifies it as instructional. Then separate one possible result from the whole space of outcomes. This protects learners from assuming that every installation produces the same terminal output or that one status line has universal significance.

Common translation error: A high success percentage is not a universal reliability guarantee; explain the sample and its scope. A revised sentence should name the actual observation, not the conclusion the author wishes were true. If a source is ambiguous, keep that uncertainty visible until the team can check the relevant versioned documentation or system evidence.

10. Recognize request routes

Route-level reporting groups HTTP traffic by route definitions and observable requests. ‘Route’ here is not necessarily a physical network path or a GPS direction. A literal translation using the everyday word for a road may confuse readers who are new to service meshes.

Exact reference token: linkerd viz routes. Keep this spelling unchanged in any localized example.

In a hypothetical API, the reader compares /orders and /health. Both tokens should remain intact while surrounding prose explains why endpoint behavior and request volumes differ.

Finally, treat this section as a decision point rather than an isolated definition. The reader should know when the information is sufficient, when another source must be consulted, and when an authorized operator rather than a translator must decide what to do. Translation can preserve the chain of responsibility by specifying who reviews a configuration, who approves a change, who checks the resulting status and who records the evidence. It cannot replace any of those roles.

Common translation error: Avoid turning route statistics into a claim about user journeys unless that interpretation is supported. A revised sentence should name the actual observation, not the conclusion the author wishes were true. If a source is ambiguous, keep that uncertainty visible until the team can check the relevant versioned documentation or system evidence.

11. Treat traffic tapping as observation

A tap shows selected traffic metadata from proxied requests. It may reveal operationally sensitive details depending on access and configuration. Translate it as observation or sampling, not interception for modification; explain permissions, retention expectations and masking policies before providing a demonstration.

linkerd viz tap

A support team wants to inspect traffic during an incident. A localized runbook limits the target to an authorized namespace and does not paste real customer identifiers into a tutorial.

Common translation error: Never describe tap as a permission-free or privacy-neutral command. A revised sentence should name the actual observation, not the conclusion the author wishes were true. If a source is ambiguous, keep that uncertainty visible until the team can check the relevant versioned documentation or system evidence.

12. Explain sorted live traffic views

Live traffic summaries are time dependent and often aggregate observations differently from historical dashboards. The reader should understand what is sorted, what the time window means and whether the view is only of traffic observable by the extension.

Exact reference token: linkerd viz top. Keep this spelling unchanged in any localized example.

A trainer shows an imaginary top list during a synthetic load test and labels it illustrative. In another language, the label ‘top’ should be rendered as an operational ranking, not a recommendation.

Common translation error: An absent workload in a snapshot is not proof it never received traffic. A revised sentence should name the actual observation, not the conclusion the author wishes were true. If a source is ambiguous, keep that uncertainty visible until the team can check the relevant versioned documentation or system evidence.

13. Keep service identity precise

The identity of a workload proxy and its certificates matters for mutual-TLS and policy interpretation. Human descriptions may use simpler vocabulary, but the identities themselves are technical evidence. Explain certificate observations without implying that certificates guarantee the business logic is trustworthy.

linkerd identity

A translated troubleshooting note distinguishes ‘certificate was issued’ from ‘this user is authorized to view all records.’ The difference is essential for correct threat models.

Common translation error: Do not replace cryptographic identities with user-facing nicknames in copied evidence. A revised sentence should name the actual observation, not the conclusion the author wishes were true. If a source is ambiguous, keep that uncertainty visible until the team can check the relevant versioned documentation or system evidence.

14. Describe authorization

Authorization concerns what traffic or principals are permitted under applicable policies. A resource name, policy name and effective scope must stay traceable. Translate permission words carefully: ‘authenticated’, ‘authorized’ and ‘allowed by network policy’ express different checks.

Exact reference token: linkerd authz. Keep this spelling unchanged in any localized example.

A hypothetical service accepts connections from a particular service account but not a different one. The localized guide should state which identity is evaluated and where the denial arises.

Common translation error: Do not say that mutual TLS alone authorizes every caller. A revised sentence should name the actual observation, not the conclusion the author wishes were true. If a source is ambiguous, keep that uncertainty visible until the team can check the relevant versioned documentation or system evidence.

15. Understand profiles and routes

A service profile describes service behavior and route classifications that can inform observability and policy. It is not a translation profile or a user account. When a term has an established CLI meaning, define it early and reuse one equivalent consistently.

linkerd profile

In an educational example, a route for GET /catalog appears in the technical profile. The translation keeps the HTTP method and path literal while explaining their use for reporting.

Common translation error: Avoid translating the path segment or modifying the HTTP method to match normal prose. A revised sentence should name the actual observation, not the conclusion the author wishes were true. If a source is ambiguous, keep that uncertainty visible until the team can check the relevant versioned documentation or system evidence.

16. Handle resource selectors and namespaces

Resource selection determines which workloads an instruction affects. Namespace, deployment and pod names can look like natural-language words, yet these are exact Kubernetes identifiers. A guide should identify whether an option has a default and whether a command scopes to one resource or many.

Exact reference token: --namespace. Keep this spelling unchanged in any localized example.

A lab contains teams called staging and production. Both are hypothetical namespace labels. The paragraph explains how a mistaken namespace can change the meaning of otherwise correct instructions.

Common translation error: Never silently insert a namespace into a copied command because it seems obvious from the prose. A revised sentence should name the actual observation, not the conclusion the author wishes were true. If a source is ambiguous, keep that uncertainty visible until the team can check the relevant versioned documentation or system evidence.

17. Upgrade without making promises

An upgrade involves generated manifests, version compatibility, rollout checks and potentially downtime considerations. Translating the workflow well requires communicating the change window, rollback plan and post-upgrade evidence. Each organization should follow its supported release procedure.

linkerd upgrade

A team uses an approved change ticket, compares the proposed manifests and checks the environment after rollout. The translated runbook separates these stages into observable actions.

Common translation error: Do not translate ‘upgrade available’ as ‘upgrade completed successfully’. A revised sentence should name the actual observation, not the conclusion the author wishes were true. If a source is ambiguous, keep that uncertainty visible until the team can check the relevant versioned documentation or system evidence.

18. Prune old resources cautiously

Pruning can produce resources for removal and therefore belongs in a change-controlled context. Translators must make deletion implications plain even when a command is embedded in an otherwise familiar maintenance tutorial. Preserve filters, selection parameters and evidence of what will be removed.

Exact reference token: linkerd prune. Keep this spelling unchanged in any localized example.

An example maintenance report lists obsolete resources for review before any deletion. The reader learns that a proposal to delete is not the same event as an approved deletion.

Common translation error: Never call a prune result harmless without knowing what resources it selects. A revised sentence should name the actual observation, not the conclusion the author wishes were true. If a source is ambiguous, keep that uncertainty visible until the team can check the relevant versioned documentation or system evidence.

19. Decommission the mesh carefully

Uninstallation is a significant change to networking and observability. A localized guide should explain dependency checking, alternative traffic handling and an explicit approval path; it should not present an uninstall command as a casual troubleshooting step.

linkerd uninstall

A teaching scenario describes withdrawing a test installation after confirming workloads no longer rely on it. The cleanup scope is written in ordinary language before the exact command appears.

Common translation error: Do not assume uninstalling a component also cleans every workload annotation or dependent extension. A revised sentence should name the actual observation, not the conclusion the author wishes were true. If a source is ambiguous, keep that uncertainty visible until the team can check the relevant versioned documentation or system evidence.

20. Write a usable incident summary

An incident summary needs the affected workload, cluster context, observed symptom, check output, timing and actions already taken. Translation should preserve machine evidence but write a clear explanation for people who were not in the incident call.

Exact reference token: linkerd diagnostics. Keep this spelling unchanged in any localized example.

A handover between teams in different languages includes an exact error excerpt and a translated interpretation with uncertainty noted. Another engineer can then verify the same evidence independently.

Common translation error: Never convert ‘likely cause’ into a final root cause just to make the narrative sound decisive. A revised sentence should name the actual observation, not the conclusion the author wishes were true. If a source is ambiguous, keep that uncertainty visible until the team can check the relevant versioned documentation or system evidence.

A complete multilingual review workflow

1. Establish a source of truth

Before translating a Linkerd runbook, identify the original text, official documentation release, installed CLI version and intended operator audience. Keep the source material in version control or another reviewable system. If a paragraph quotes output, record whether it came from a real authorized test, a vendor example or a fictional teaching case. A reviewer cannot judge fidelity without knowing that provenance. Version uncertainty should be written as a limitation instead of being concealed by general phrases such as ‘on every cluster’.

Build a small glossary of technical concepts and record the exact English tokens that cannot be translated. Include the reason for each decision. For example, an API field is literal because a parser requires it; an operational noun might be translated consistently but must be defined; a vendor product name normally remains unchanged. Share this glossary with engineers and native-language reviewers. An accurate glossary is valuable because it prevents small inconsistencies from multiplying across warnings, screenshots, lessons and FAQs.

2. Classify every command by consequences

Review each example and mark whether it observes information, analyzes a file, generates a proposed configuration, opens a temporary connection, changes a cluster object, transfers data or deletes something. The labels are editorial aids rather than CLI modes, but they tell the writer what warning belongs before an action. Read-only does not mean consequence-free: even an inspection can expose sensitive metadata or consume permissions. Likewise, a generated manifest is not an applied change, yet a later command in the same pipeline might apply it.

Ask what could go wrong when the reader has the wrong context, an outdated command, too much privilege or a misleading success message. Then write the smallest effective safeguard directly beside that step. A warning that says only ‘be careful’ is weak. A useful warning identifies the target to double-check, the effect to anticipate and the record to retain. Keep operational approvals local to the organization rather than pretending a generic article can grant permission.

3. Produce two layers of text

Keep command lines, YAML and JSON inside code formatting and do not force a natural-language translation into them. Translate headings, explanations, decision criteria, captions and safe comments in natural prose. When a word is a command token and an ordinary word, use phrasing such as ‘run linkerd with the documented option’ rather than pretending that the translated verb is executable. Expand acronyms on first use when the expansion is stable and useful. Avoid inventing certainty for unfamiliar project-specific terms.

For a global audience, avoid unnecessary assumptions about keyboards, default shells, operating systems, localized dates, base language or administrator access. State the shell or tool requirement when it matters. Treat environment variables, path separators, placeholder delimiters and quote characters as technical syntax. Instructions that depend on a specific platform should name it. A learner working on a different operating system should recognize the difference without having to discover it through failure.

4. Review evidence and claims

Separate the unmodified source record from an interpretive summary. A log entry may establish that a program reported an event, not necessarily that the event explains an outage. Use language such as ‘the output shows’, ‘this suggests’ and ‘to verify this, inspect’ with care. Never convert a proposed root cause into a confirmed root cause merely to improve readability. If an incident report has multiple time zones, specify offsets and preserve original timestamps in the evidence.

When a screenshot contains sensitive addresses, tokens, identity claims or customer information, do not translate it by editing the pixels and then presenting it as an original record. Create a separately labeled, redacted educational illustration instead. For authoritative evidence, store the original in a controlled location with suitable access. The local-language narrative can reference the record and its limitations without exposing confidential material to the public.

5. Test copy and paste under Unicode

Check the code examples in the actual publishing environment, not only in an editor preview. Smart quotation marks, nonbreaking spaces, zero-width marks, localized digits, bidirectional controls and automatic punctuation can make a command appear normal while changing its bytes. Test the difference between a displayed example and the text copied to a terminal. Where right-to-left prose surrounds left-to-right commands, isolate the command visually and confirm its order. Do not edit literal hostnames or resource IDs to improve line breaking.

A proper Unicode QA checklist includes accented Latin letters, CJK text, Arabic-script explanations, mixed-direction sentences, narrow mobile layouts and keyboard navigation. The target text should remain readable without corrupting identifiers. Screen readers must distinguish headings, code blocks and warnings. Make table headings meaningful and do not communicate severity with color alone. If automatic translation changes technical tokens, correct the source markup or glossary before publishing rather than patching isolated screenshots.

6. Confirm comprehension with a small exercise

Give a learner a short example from Linkerd documentation and ask five questions: what is the goal, what exact command or resource is named, which environment does the operation target, what evidence will appear, and what remains unknown afterwards? Then ask the learner to explain the same operation in their own language without changing the technical tokens. This checks both the language and the understanding of cause and effect. A fluent translation that makes the wrong operational claim should fail the review.

A second participant can deliberately introduce one error: a changed flag, a reversed severity, an omitted namespace, a fake assertion of complete safety or an unapproved cleanup step. The task is to identify why the altered text is misleading, not simply to correct spelling. This is a valuable training pattern because it teaches readers to question certainty and trace claims to evidence. Document corrections in the glossary so the same defect does not reappear.

A realistic teaching case: the three-layer report

Imagine a fictional platform team maintaining a test environment called training-lab. The team has an exact terminal excerpt, a draft translation and a short operational summary. The first layer is an untouched, clearly labeled source excerpt with timestamps and command context. The second layer explains each relevant field in a target language. The third layer states what decision the evidence supports and what cannot yet be concluded. Readers can move between these layers to test accuracy without treating the translation as a substitute for the original record.

For Linkerd, this separation prevents two common failures: rewriting evidence to look more polished and turning a limited observation into a sweeping claim. If the summary states an issue was fixed, it must name the confirmation step. If it merely proposes a fix, that condition stays explicit. Use a synthetic resource and nonfunctional addresses in public examples. Never ask students to execute a disruptive real-world action just to prove that they can understand a translated sentence.

Common questions about translating Linkerd CLI

Should I translate a CLI subcommand?

No. The executable token belongs to the tool. Translate the surrounding explanation and define the meaning the first time it appears. If an interface is itself officially localized, follow its documented localization mechanism, but do not invent translated subcommands.

Can I translate resource names or JSON keys?

Normally not inside working code or evidence. Names, selectors, paths, enum values, keys and identifiers may be exact-match data. If a teaching example deliberately renames a fictional object, update every reference consistently and label it as a new example rather than a translation of a real record.

What should I do with an unclear warning?

Keep its source wording and code available, give a cautious explanation and consult the official documentation for the installed version. An unclear warning should not be converted into either a harmless status or an emergency without supporting evidence.

Is successful command output proof the service is healthy?

Only within the command’s own documented scope. Local validation, configuration generation, status inspection, deployment and application acceptance are distinct. State which stage was confirmed and which further observations are required.

How should examples handle passwords and access tokens?

Use visibly fake placeholders or masked values. Never paste real credentials, private keys or unreviewed diagnostic bundles into public examples. Translation must preserve security boundaries as well as words.

What about regional number and date formats?

Human prose can follow the reader’s conventions, but machine-readable syntax and original timestamps must remain exact. Label units, precision and time zones; do not silently change parser-sensitive fields.

How should we review right-to-left translations?

Render mixed-direction prose and code in a real browser, copy the commands and verify token order. Use accessible code formatting, avoid invisible characters in copied examples and ask a native-language reviewer to test a mobile display.

Where should readers check command changes?

Use the official Linkerd command references linked at the end and the installed tool’s help output. A tutorial explains concepts; the release-specific CLI reference determines precise flags and supported workflows.

Next reading and authoritative references

These primary documentation pages provide the command-specific reference and troubleshooting details used for this tutorial. Confirm the release in your own environment rather than treating examples as a universal prescription:

https://linkerd.io/docs/reference/cli/

https://linkerd.io/docs/tasks/troubleshooting/

https://linkerd.io/2-edge/reference/cli/viz/

Conclusion: translate meaning without changing evidence

A professional translation of Linkerd lets a person understand what a command means, where it applies and which observation would support a conclusion. It does not change executable syntax, promise reliability without tests or erase uncertainty for the sake of fluent prose. Clear definitions, disciplined scope, safe examples and a reproducible review process make technical writing useful to readers across regions and languages. When the record is exact and the human explanation is careful, the same guide can support learning, review and responsible collaboration.