Master Art of Translation | The OpenTelemetry Semantic Conventions and Observability Translation System — How Traces, Metrics, Logs, Units, Attributes and Incident Evidence Keep Their Meaning

How do you translate OpenTelemetry logs, traces, metrics, dashboards and incident reports into another language without corrupting the telemetry? OpenTelemetry translation is not simply replacing English phrases with target-language phrases. A trustworthy multilingual observability system translates human-facing explanations, runbooks and interface labels while preserving span and trace identifiers, attribute keys, metric units, timestamps, status meaning, aggregation rules and the technical contracts used by instrumentation and analysis tools. This comprehensive guide teaches operators, SREs, translators, software engineers, localisation teams and technical writers how to translate OpenTelemetry semantic conventions responsibly, validate a target-language observability interface and explain a distributed incident without changing what the underlying evidence says.

The hidden problem is that observability data contains several kinds of language at once. A dashboard heading such as ‘Request duration’ is natural language that may be localised, but a metric name, a case-sensitive attribute key, a trace ID, a routing value or a unit expressed with a recognised code may be machine-readable vocabulary whose spelling is part of its meaning. Even the word ‘error’ has several contracts: an HTTP response code, an exception event, a span status and an alert condition do not always tell the same story. Changing one layer can silently break searches, alert thresholds, cross-service joins or interpretations of operational risk. A fluent translation can therefore be worse than an awkward one if it rewrites the evidence.

Quick working summary: identify the telemetry producer and version; inventory traces, metrics, logs, resources, schema URLs and dashboards; classify every field as an immutable identifier, a typed measured value, an enumerated code, a localisable description or a sensitive message; record translation decisions in a termbase; keep machine keys and correlation values stable; translate explanations in context; distinguish events from observations and counts from rates; test language fallbacks and units; compare source and target dashboards against the same frozen data; review privacy and accessibility; run bilingual incident exercises; and release with a reversible change log. The method is translate the reader’s understanding, not the telemetry’s identity. It is a complete specialist system rather than a replacement for the site’s general translation guide.

1. Definition lock: exactly what OpenTelemetry translation means

In this article, OpenTelemetry translation means the controlled creation and testing of multilingual representations of information carried by or about OpenTelemetry signals. The work includes interface strings, explanations of spans and metrics, dashboard headings, alert descriptions, incident communications, searchable human notes and explanatory metadata. It does not mean translating every OpenTelemetry wire-format field or altering identifiers as though they were normal prose. Observability localisation is the product and interface design discipline; technical translation is the language discipline; telemetry compatibility is the engineering constraint joining them. Each has different evidence and approval owners.

A trace models a sequence of operations; a span represents an operation with context, timing, attributes, events, links and status; a metric is a measurement stream with instrument semantics, attributes, units and aggregation; a log record preserves an event with time, severity and optional trace correlation; a resource describes the entity emitting telemetry; and baggage is propagated contextual data, not a safe place to put arbitrary translated descriptions or personal details. These distinctions are essential: the same phrase can refer to a different kind of object depending on where it appears.

A semantic convention is a shared contract for names, attributes, types and meanings. It helps a server, instrumentation library, collector, dashboard and human analyst agree on what an observation represents. For instance, a metric whose unit is seconds remains a seconds measurement even if the target language describes the dimension differently. Localisation must not silently convert values, swap attribute names or introduce a new status category. A custom application can have its own vocabulary, but once dashboards or alerts depend on that vocabulary it also becomes an interface contract.

2. What the authoritative standards actually cover

OpenTelemetry maintains a specification and a separately versioned semantic-conventions specification. The official documentation viewed for this guide on 1 November 2026 presented the specification as version 1.62.0 and semantic conventions as version 1.44.0. Individual signals and convention groups may carry different stability statuses, and projects should check the current status of each field before committing to a migration. The labels used here are not a promise that every experimental field is permanent.

The OpenTelemetry common specification explains attribute key/value typing and case sensitivity. Its trace API defines span context, trace and span identifiers, kind, links, events, timestamps and status. Its metrics model distinguishes, among other things, gauge, sum and histogram observations and delta versus cumulative temporality. Its logs model separates event time from observed time and distinguishes severity text from numerical severity. The semantic-conventions documentation supplies names, types and protocol-specific recommendations, including the use of UCUM-compatible units for many instruments. The article paraphrases these public specifications but does not reproduce them.

The translation QA method also reflects ISO 5060:2024’s analytic approach to evaluating translation output, including error categories and calibrated severity. That standard is guidance on human evaluation of translation output; it is not an OpenTelemetry validation schema. A robust release therefore needs two gates: a linguistic/evidential review and an independent technical compatibility review. Passing either gate alone is insufficient.

3. Search intent: what people are really trying to solve

A user searching ‘translate OpenTelemetry logs’ might want to make error messages readable for a multilingual operations team, but their hidden requirement is often preserving trace IDs and exception context. A user searching ‘localize Grafana dashboard metrics’ may want new labels without breaking PromQL queries, unit formatting or threshold colours. Someone searching ‘OpenTelemetry semantic conventions localization’ usually needs to know which identifiers are stable API vocabulary, which descriptive strings can be rendered differently, and which schema changes require migration. Another reader needs to explain a production incident across language boundaries without reclassifying timeouts as failures, requests as errors or inferred causes as observed events.

These search intents should not be collapsed into a generic machine translation tutorial. The source audience includes instrumentation authors, translators, incident commanders, vendor-support writers, security analysts, service owners, data-platform teams and accessibility specialists. Their questions overlap but their obligations do not. A translator can confirm linguistic clarity; a telemetry engineer verifies joins and metrics; an incident owner verifies causality; a privacy reviewer verifies disclosure. Successful multilingual observability is the result of those independent checks.

4. The invariant map: five layers that must not be confused

Layer 1 — identity

Trace IDs, span IDs, resource identifiers, service names used by queries, namespace tokens, schema URLs and opaque correlation values are evidence-bearing or routing-bearing strings. Preserve their exact bytes unless an explicit migration plan authorises a contract change. For an acceptance test, compare the unchanged machine representation with the approved human rendering and record the reviewer responsible for each layer. A useful translation unit is not always one string: it may be an evidence set consisting of an attribute name, typed value, label, help text, query usage and action taken by an operator.

Layer 2 — type and unit

Numbers, timestamps, booleans, enumerations, metric instrument types, UCUM unit expressions, temporality and bucket boundaries carry measurable meaning. A display layer can present them accessibly, but a translation is not allowed to redefine or silently rescale them. For an acceptance test, compare the unchanged machine representation with the approved human rendering and record the reviewer responsible for each layer. A useful translation unit is not always one string: it may be an evidence set consisting of an attribute name, typed value, label, help text, query usage and action taken by an operator.

Layer 3 — event interpretation

A span status, HTTP code, exception record, log severity and alert state express different propositions. Translate each proposition according to its own model. Never make a single ‘error’ or ‘success’ label stand for all of them. For an acceptance test, compare the unchanged machine representation with the approved human rendering and record the reviewer responsible for each layer. A useful translation unit is not always one string: it may be an evidence set consisting of an attribute name, typed value, label, help text, query usage and action taken by an operator.

Layer 4 — human language

Dashboard titles, help messages, runbook steps, descriptions, teaching examples, incidents summaries and accessibility text can be translated when supported by the evidence. They need context, approved terms and audience-aware syntax. For an acceptance test, compare the unchanged machine representation with the approved human rendering and record the reviewer responsible for each layer. A useful translation unit is not always one string: it may be an evidence set consisting of an attribute name, typed value, label, help text, query usage and action taken by an operator.

Layer 5 — distribution and governance

Exporters, collectors, backends, release manifests, language fallback, privacy controls and human approvals determine whether a localised view reaches the right reader safely. A technically correct translation is still unsafe if it is published into the wrong environment or reveals secrets. For an acceptance test, compare the unchanged machine representation with the approved human rendering and record the reviewer responsible for each layer. A useful translation unit is not always one string: it may be an evidence set consisting of an attribute name, typed value, label, help text, query usage and action taken by an operator.

5. The repeatable 20-gate production method

1. Freeze an evidence snapshot

Export representative traces, log records, metric streams, dashboard queries and alerts into a read-only test fixture. Note timestamps, instrumentation builds and schema versions before translation begins. Pass condition: an independent reviewer can reproduce the decision from a frozen source record, see precisely what was localised, and explain what was deliberately left unchanged. A gate is not completed merely because someone checked a box; keep a small evidence artifact such as a fixture, an annotated screenshot, a terminology entry or a test result.

2. Define user decisions

Ask what each translated phrase enables a reader to decide: identify a service, detect a threshold breach, communicate an outage, search an event or start an escalation. Pass condition: an independent reviewer can reproduce the decision from a frozen source record, see precisely what was localised, and explain what was deliberately left unchanged. A gate is not completed merely because someone checked a box; keep a small evidence artifact such as a fixture, an annotated screenshot, a terminology entry or a test result.

3. Separate contracts and display

Mark each unit as machine token, localisable phrase, technical number, controlled enumeration, free-text diagnostic, narrative or secret. Do not guess from typography. Pass condition: an independent reviewer can reproduce the decision from a frozen source record, see precisely what was localised, and explain what was deliberately left unchanged. A gate is not completed merely because someone checked a box; keep a small evidence artifact such as a fixture, an annotated screenshot, a terminology entry or a test result.

4. Check producer ownership

Find whether a field is defined by OpenTelemetry semantic conventions, instrumentation code, a collector transformation, a dashboard vendor or a human runbook. Pass condition: an independent reviewer can reproduce the decision from a frozen source record, see precisely what was localised, and explain what was deliberately left unchanged. A gate is not completed merely because someone checked a box; keep a small evidence artifact such as a fixture, an annotated screenshot, a terminology entry or a test result.

5. Record spec status

For the exact convention and signal, identify stable versus developing or mixed status. Treat a documentation example as context rather than as an unconditional guarantee. Pass condition: an independent reviewer can reproduce the decision from a frozen source record, see precisely what was localised, and explain what was deliberately left unchanged. A gate is not completed merely because someone checked a box; keep a small evidence artifact such as a fixture, an annotated screenshot, a terminology entry or a test result.

6. Identify semantic dependencies

Map queries, joins, alerts, instrumentation, dashboards and downstream exports using every token being considered for a change. Pass condition: an independent reviewer can reproduce the decision from a frozen source record, see precisely what was localised, and explain what was deliberately left unchanged. A gate is not completed merely because someone checked a box; keep a small evidence artifact such as a fixture, an annotated screenshot, a terminology entry or a test result.

7. Approve language scope

Set target languages, reading level, local formatting rules, accessibility requirements and whether user-facing technical terms should remain bilingual. Pass condition: an independent reviewer can reproduce the decision from a frozen source record, see precisely what was localised, and explain what was deliberately left unchanged. A gate is not completed merely because someone checked a box; keep a small evidence artifact such as a fixture, an annotated screenshot, a terminology entry or a test result.

8. Build a bilingual termbase

Enter preferred translations, forbidden confusions, definitions, short and long labels, abbreviations and examples. Give each term an owner and revision history. Pass condition: an independent reviewer can reproduce the decision from a frozen source record, see precisely what was localised, and explain what was deliberately left unchanged. A gate is not completed merely because someone checked a box; keep a small evidence artifact such as a fixture, an annotated screenshot, a terminology entry or a test result.

9. Protect immutable values

Lock opaque IDs, URLs, resource names in use, key paths, semantic enumerations, time precision and numeric data at the authoring or pipeline level. Pass condition: an independent reviewer can reproduce the decision from a frozen source record, see precisely what was localised, and explain what was deliberately left unchanged. A gate is not completed merely because someone checked a box; keep a small evidence artifact such as a fixture, an annotated screenshot, a terminology entry or a test result.

10. Translate a context packet

Provide each translator with the field’s screenshot, parent component, sample record, expected operator decision and maximum available display space. Pass condition: an independent reviewer can reproduce the decision from a frozen source record, see precisely what was localised, and explain what was deliberately left unchanged. A gate is not completed merely because someone checked a box; keep a small evidence artifact such as a fixture, an annotated screenshot, a terminology entry or a test result.

11. Classify uncertainty

Separate facts in telemetry from operator hypotheses, absent evidence, suppressed samples, stale dashboards and independently confirmed incidents. Pass condition: an independent reviewer can reproduce the decision from a frozen source record, see precisely what was localised, and explain what was deliberately left unchanged. A gate is not completed merely because someone checked a box; keep a small evidence artifact such as a fixture, an annotated screenshot, a terminology entry or a test result.

12. Review language

Have a qualified reviewer examine correctness, register, grammar, ambiguity, terminology, directionality and the safety of instructions. Pass condition: an independent reviewer can reproduce the decision from a frozen source record, see precisely what was localised, and explain what was deliberately left unchanged. A gate is not completed merely because someone checked a box; keep a small evidence artifact such as a fixture, an annotated screenshot, a terminology entry or a test result.

13. Review technical semantics

Test that the target words do not change measurements, thresholds, metric aggregations, trace joins, query expressions, boolean meanings or exception handling. Pass condition: an independent reviewer can reproduce the decision from a frozen source record, see precisely what was localised, and explain what was deliberately left unchanged. A gate is not completed merely because someone checked a box; keep a small evidence artifact such as a fixture, an annotated screenshot, a terminology entry or a test result.

14. Validate data contracts

Run parser or schema checks where applicable. Ensure translation files do not overwrite OTLP payloads or semantic-convention key names. Pass condition: an independent reviewer can reproduce the decision from a frozen source record, see precisely what was localised, and explain what was deliberately left unchanged. A gate is not completed merely because someone checked a box; keep a small evidence artifact such as a fixture, an annotated screenshot, a terminology entry or a test result.

15. Compare with a golden fixture

Display identical synthetic telemetry in source and target UI; confirm that numbers, colours, navigation targets, incident priorities and correlations match. Pass condition: an independent reviewer can reproduce the decision from a frozen source record, see precisely what was localised, and explain what was deliberately left unchanged. A gate is not completed merely because someone checked a box; keep a small evidence artifact such as a fixture, an annotated screenshot, a terminology entry or a test result.

16. Exercise fallback and plural rules

Test missing target entries, multiple language preferences, long labels, plural units and text expansion. A missing translation must not display invented operational certainty. Pass condition: an independent reviewer can reproduce the decision from a frozen source record, see precisely what was localised, and explain what was deliberately left unchanged. A gate is not completed merely because someone checked a box; keep a small evidence artifact such as a fixture, an annotated screenshot, a terminology entry or a test result.

17. Test accessibility

Check keyboard reading order, screen-reader labels, high-contrast statuses, directionality and whether colour-only dashboards also explain states in text. Pass condition: an independent reviewer can reproduce the decision from a frozen source record, see precisely what was localised, and explain what was deliberately left unchanged. A gate is not completed merely because someone checked a box; keep a small evidence artifact such as a fixture, an annotated screenshot, a terminology entry or a test result.

18. Review sensitive disclosures

Remove credentials, tokens, personal details, private IPs when inappropriate, secret-bearing URLs and unapproved payload excerpts from examples and shared screenshots. Pass condition: an independent reviewer can reproduce the decision from a frozen source record, see precisely what was localised, and explain what was deliberately left unchanged. A gate is not completed merely because someone checked a box; keep a small evidence artifact such as a fixture, an annotated screenshot, a terminology entry or a test result.

19. Conduct a bilingual incident rehearsal

Have two teams diagnose the same frozen incident independently. Compare their event ordering, root-cause confidence and recommended actions. Pass condition: an independent reviewer can reproduce the decision from a frozen source record, see precisely what was localised, and explain what was deliberately left unchanged. A gate is not completed merely because someone checked a box; keep a small evidence artifact such as a fixture, an annotated screenshot, a terminology entry or a test result.

20. Release, monitor and roll back

Version the termbase, translated assets, fixtures and approval notes. Monitor confusion and broken queries after release, and preserve a rapid rollback to the last verified language pack. Pass condition: an independent reviewer can reproduce the decision from a frozen source record, see precisely what was localised, and explain what was deliberately left unchanged. A gate is not completed merely because someone checked a box; keep a small evidence artifact such as a fixture, an annotated screenshot, a terminology entry or a test result.

6. The mechanism: why language and telemetry separate

1. Semantic keys versus descriptions

A key such as service.name identifies a field; its description explains it. The translator should modify a user-facing label or help string, not the key used by instrumentation and queries. A dashboard can display ‘Service’ in another language while the collector continues emitting service.name. If a key migration is genuinely necessary, it is an engineering change with compatibility tests, not a translation decision.

Consider the reverse test: a second-language operator receives the translated display and copies the visible identifiers back into the system of record. If the copy no longer finds the observation, the translation has crossed from interpretation into a contract change. Consider also the forward test: when a new telemetry event arrives using the same schema, the translated explanation still applies without inventing a new rule. Both tests turn an abstract principle into a repeatable quality check.

2. Case sensitivity and value typing

OpenTelemetry attribute keys are case sensitive and attribute values have defined types. A value of integer 5 is not the string ‘five’; boolean false is not a free-text denial that can be softened; and changing the case of a key produces a different key. Validation should compare both type and value before considering whether a surrounding explanation is fluent.

3. Trace correlation

Trace and span IDs are not sentences. A trace ties operations together and spans can have parent relationships and links. A translated report needs to retain identifiers exactly so readers can resolve the same evidence. If a report shows a shortened form for convenience, it must provide access to the full original without claiming the shortened form is a valid operational key.

4. Span status and business outcome

A span status value is not interchangeable with an application’s business verdict. An operation can complete transport successfully while an application reports an unsuccessful business result, or vice versa. A translator should name the specific criterion instead of flattening every visible failure signal into one generic ‘failure’ statement.

5. Event names and attributes

Span event names can be defined by instrumentation conventions. They may be part of machine query logic rather than just visible narration. The display layer can explain what an event denotes, while the event name and timestamp remain preserved for correlation. Translating a graph legend should not cause an event to disappear from event filters.

6. Metric instruments

Counters, up-down counters, gauges and histograms answer different questions. Localised text must explain whether a number is cumulative, instantaneous, sampled or a distribution. The word ‘total’ can mislead if the instrument describes a current quantity, and ‘average’ can mislead if the dashboard is plotting a percentile.

7. Metric units and scales

Instrument units may be UCUM-style codes and duration instruments often use seconds. The natural-language word for seconds may be translated, but a conversion to milliseconds requires an explicit arithmetic change in the rendering layer and appropriate labels. Never merely replace ‘s’ with ‘ms’ while retaining unchanged numeric data.

8. Metric temporality

Delta and cumulative temporalities represent different accumulation windows. It is possible to transform data between forms under specific conditions, but a translator cannot do so by renaming a chart. Review the raw stream and the dashboard query before labeling something ‘per minute’ or ‘since startup’.

9. Log timestamps

Event time and observed time are distinct fields in the log model. A global operator may see one in a local time zone and another as an ingestion time. Translate the labels and format choices explicitly, but preserve the actual instant and source timestamps. A difference between them may itself be incident evidence.

10. Severity systems

SeverityText is a textual representation and SeverityNumber provides a numerical counterpart in the log model. An organisation may adopt display wording, but should avoid claiming that a particular severity automatically proves user impact. Cross-check the numerical field, instrumentation mapping and incident policy before displaying a translated priority.

11. Cardinality and labels

Translation choices that create new values per user or language can multiply time series or destroy aggregation compatibility. Some categories should remain controlled, low-cardinality technical values while prose can vary by locale in the UI. Review labels entering metric attributes, not just the dictionary of translated words.

12. Privacy across languages

A technically accurate incident sentence can still disclose more information than intended. The translator should see only the minimum necessary diagnostics and review whether names, contact details, tokens or payloads become recognisable after translation. Translation must not be used to evade ordinary retention, permission or redaction policy.

7. Worked diagnostic atlas: 120 original field-level translation cases

The next cases are fictional, deliberately small examples. They are not claims about real incidents or vendor defaults. Each illustrates a decision that can be tested against a frozen record. The source strings and bad renderings are illustrative; where exact field names are shown, consult the referenced specifications and the instrumentation version actually deployed. These cases form a field guide for training reviewers, examining translated dashboards and designing automated acceptance tests.

8. Casebook: Trace identity and causality

The traces chapter treats the shape of an operation as evidence. A language team must not redraw relationships so that an intuitive story replaces actual parentage, link context or event chronology. The examples ask whether a translated statement can be verified from trace context.

Diagnostic 001 — Trace ID copied into a report

Evidence packet. A span shares trace_id 9c7a… across the root and two child operations. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translation formats the identifier like a readable serial number and drops characters at the end. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: An opaque correlation identifier is not a word and truncation breaks exact lookup. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Translate the label ‘Trace identifier’, display the full original ID, and provide a copy action. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Paste the displayed ID into the trace search and confirm it resolves exactly the frozen record. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 002 — Span ID mistaken for trace ID

Evidence packet. A child has its own span_id while all siblings share a trace_id. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A bilingual incident note calls both numbers ‘request ID’ and conflates the scopes. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: The two identifiers answer different questions about operation identity and whole-trace correlation. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Give each a distinct term and describe the span-to-trace relationship plainly. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Resolve both fields separately and confirm the report identifies the intended operation. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 003 — Parent-child direction reversed

Evidence packet. A database span has a parent application span in the trace tree. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. An alternate-language tree label says the database request launched its parent service. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Parentage describes causal nesting and must not be inferred from screen indentation alone. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Translate ‘parent operation’ and ‘child operation’ with arrows checked against actual span context. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Reconstruct the tree from source IDs and compare it to the target-language diagram. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 004 — SpanKind CLIENT versus SERVER

Evidence packet. A distributed request includes a client-side and a server-side observation. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. Both are translated as ‘server action’ because they reference the same HTTP route. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Span kind distinguishes the role of instrumentation in the exchange. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Localise the explanatory phrase but retain CLIENT and SERVER as their technical values. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare the peer span pair and ensure each view identifies the observer correctly. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 005 — Span status Unset

Evidence packet. A span has status Unset rather than an explicit Ok or Error. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translated dashboard displays ‘successful’ because it sees no error field. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: An unset status is not an affirmative success assertion. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Use a rendering such as ‘status not explicitly set’ where appropriate and avoid inventing confirmation. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Check the raw status and an unrelated business outcome field separately. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 006 — Exception event timing

Evidence packet. An exception event occurs before a span ends and is attached to that span. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translated timeline describes the exception as occurring after the whole request finished. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Event timestamps and span start/end times provide ordering evidence. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Localise event headings but leave the event clock values and ordering unchanged. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Sort original event timestamps and compare the target timeline step by step. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 007 — Linked spans in an asynchronous path

Evidence packet. A processing span links to the producer context rather than being its direct child. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A translated caption says ‘child of’ because the lines look connected. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: A span link is not identical to a parent relationship. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Say ‘linked to the producer operation’ and preserve the association kind. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare link context with parent span fields to distinguish both relations. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 008 — Sampled trace visibility

Evidence packet. One trace is sampled while a parallel application request is not visible in the backend. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A translated summary says ‘no other requests occurred’ because none were found. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Absence from a sampled trace corpus is not proof of absence from the service. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Describe the search coverage and sampling limitation in the incident note. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Inspect sampling policy and compare available aggregate metrics before making a zero claim. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 009 — Span name cardinality

Evidence packet. A custom span name is an exact user email instead of a bounded operation class. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A translator treats every name as a sentence requiring a localised replacement. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Span names should identify useful operation classes; personal identifiers create cardinality and privacy problems. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Raise an instrumentation issue and use stable operation-class labels in human views. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Group spans by operation and verify cardinality stays bounded without changing identifiers post hoc. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 010 — Trace-state and trace-flags

Evidence packet. A distributed context includes trace flags and trace state values. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A localised explanatory note replaces the technical flag token with a natural-language adjective. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Propagation fields carry operational semantics and are not simple annotations. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Keep fields byte-accurate and translate their interpretation in separate documentation. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Use a frozen cross-service propagation test to prove identical context arrives at the next service. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

9. Casebook: Resources, service identity and provenance

The resources chapter asks who or what produced the observation. A resource attribute describes an emitting entity at a particular granularity. Service, process, instance, host, container and SDK fields should not be flattened into a single everyday word for ‘machine’.

Diagnostic 011 — Service name in a selector

Evidence packet. A filter uses service.name=checkout-api across several language views. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translation changes the underlying value to a local-language noun. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Service identity in this query must remain a stable comparison value. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Keep checkout-api as the filter value and translate only ‘Service’ in the UI. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Run the same query in both locales and compare the returned trace set. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 012 — Instance identity during restart

Evidence packet. Two process lifetimes report distinct service.instance.id values. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A summary translates both as ‘the same server’ because the friendly service name matches. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: An instance identifier and a service name describe different granularity. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Explain that the service has multiple instances and retain each instance ID. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare timestamps and instance identifiers across the restart boundary. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 013 — Deployment environment

Evidence packet. A resource identifies deployment.environment.name as staging. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The target-language display changes the value to ‘production test’ and an operator acts on the wrong system. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Environment identifiers may be used by selectors and access policies. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Retain the canonical value and place a translated descriptive tooltip beside it. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Test environment filters and confirm staging never returns production alerts. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 014 — Host name case and punctuation

Evidence packet. A host.name value contains dots, hyphens and digits. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A proofreader inserts spaces to improve the readability of the host label. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: A host identifier is not grammatical prose and punctuation can be significant. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Preserve the host token and translate its surrounding noun. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Copy the shown token into the authorised host inventory and check an exact match. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 015 — Process PID label

Evidence packet. A log resource includes process.pid=7421. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translation calls this the ‘process version’ and implies it identifies a software release. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: A process identifier is not a semantic version or a stable identity across restarts. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Translate it as process ID and describe its lifetime limitation. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare another process restart to show the PID is not sufficient for release attribution. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 016 — Container image digest

Evidence packet. An image reference includes a content digest with sha256 and a long hexadecimal value. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A shortened local-language note calls it the image tag. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: A tag can move whereas an immutable content digest identifies specific bytes. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Retain the digest and distinguish tag from digest in prose. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Check the deployment record and confirm the claimed build matches the digest. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 017 — Kubernetes namespace

Evidence packet. A resource attribute contains k8s.namespace.name=payments-ops. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A translator expands the namespace name into a translated phrase in a search filter. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: The actual namespace identifier is part of cluster state and filter semantics. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Translate ‘namespace’ as a noun without modifying payments-ops in selectors. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Find the original pods using the unchanged namespace and compare results. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 018 — Instrumentation scope

Evidence packet. Two libraries emit spans under separate instrumentation-scope names. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The report describes the scope name as the application owner rather than the instrumenting library. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Instrumentation scope and service ownership are separate concepts. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Write ’emitted by instrumentation scope’ and retain the precise source name. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Group by scope and by service independently before drawing conclusions. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 019 — SDK version and language

Evidence packet. A resource contains telemetry.sdk.name, telemetry.sdk.language and telemetry.sdk.version. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A translated sentence turns language=java into the operator’s spoken language. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: The field describes the software language of the SDK, not the user’s UI language. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Say ‘SDK programming language’ and preserve the canonical value. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Check the same event in a different UI locale and confirm resource values do not change. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 020 — Cloud region versus time zone

Evidence packet. A service reports a cloud.region token in its resource attributes. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The incident note interprets region as the user’s locale or time zone. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Compute region, display language and time zone are independent dimensions. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Keep cloud.region unchanged and specify the report time zone separately. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare service resource data with timestamps and language preferences. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

10. Casebook: HTTP, RPC and transport signals

The protocol chapter distinguishes a transport measurement from a user’s experience of it. Methods, routes, status codes, ports and protocol versions have their own definitions. The operator’s eventual diagnosis may use ordinary words, but those words must remain linked to the correct raw facts.

Diagnostic 021 — HTTP method token

Evidence packet. An HTTP span records http.request.method=POST. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A localiser replaces POST with a translated imperative verb. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: HTTP method is an interoperable protocol token, not ordinary vocabulary. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Display the explanatory phrase ‘request method’ while keeping POST intact. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Filter by the method in both languages and confirm identical results. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 022 — HTTP route pattern

Evidence packet. A span includes http.route=/orders/{orderId}. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A translator converts the placeholder identifier into a translated word inside the route. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: The route pattern is a technical attribute that may be queried and compared. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Keep the route expression exact and translate its business description elsewhere. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare route-based aggregation before and after deployment. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 023 — Status code versus error verdict

Evidence packet. An HTTP request returns 404 while a cached consumer deliberately expects absence. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A bilingual note always translates 404 as a service outage. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: The response code describes an HTTP result, not by itself incident severity or downstream impact. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Translate ‘not found’ in context and preserve the status code. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Read the calling workflow and confirm whether the status is expected before assigning incident priority. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 024 — Server port as a number

Evidence packet. A network span records server.port=443. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A translated label inserts punctuation and makes it appear as an address fragment. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: The port is a typed network number and should not be translated as an identifier string. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Render ‘server port 443’ with type and value preserved. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare parsed server.port in both UI views and test filters. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 025 — URL scheme and transport

Evidence packet. A record uses url.scheme=https. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A note translates the scheme into a phrase and pastes it as a broken URL. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Scheme tokens must remain exact in machine-use contexts. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Keep https unchanged and explain the transport in prose. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Click or parse the reconstructed URL and verify the scheme remains valid. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 026 — Network protocol version

Evidence packet. A transport field identifies HTTP/2 in a sample. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translation claims this is the software application version 2. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Protocol version and application release number are distinct dimensions. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Label the value as network protocol version and retain the protocol syntax. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare application release metadata to the protocol field. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 027 — Client address and NAT uncertainty

Evidence packet. A field shows a client.address that may be a proxy address. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A translated report identifies the address as the individual end user. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: An observed network endpoint does not always establish person or device identity. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Say ‘observed client address’ and document proxy assumptions. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare proxy headers, trusted boundaries and access logs before identifying a caller. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 028 — Body size unit

Evidence packet. A report records an HTTP request body size measured in bytes. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A translated chart heading changes bytes to kilobytes without converting the points. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Unit labels and measured values must agree arithmetically. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Render bytes faithfully or perform an explicit documented conversion in the display layer. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Check a known fixture of 2048 bytes against displayed numbers. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 029 — User-agent string

Evidence packet. A user_agent.original value contains an exact client software signature. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A translator reformats brand names and parentheses into prose. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: The original user-agent is evidence that may be used for diagnosis. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Preserve the original string and provide a translated explanation separately. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Search the raw value and verify it still correlates with client reports. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 030 — Error type cardinality

Evidence packet. An HTTP instrumentation emits error.type categories for failed requests. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A localiser inserts full translated customer messages into error.type values. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: An error-category attribute should be predictable; uncontrolled prose increases cardinality. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Keep stable classifications and translate a user-facing description map. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare unique values and query costs in a frozen sample. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

11. Casebook: Metrics, measurements and aggregation

The metrics chapter addresses the most expensive kind of translation mistake: a readable label that causes a numerical decision to be wrong. Unit conversion, temporality, aggregation, percentiles and cardinality must be inspected as computation, not edited as grammar.

Diagnostic 031 — Seconds to milliseconds

Evidence packet. A duration instrument uses unit s and values around 0.2. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A dashboard changes the label to milliseconds but leaves the number 0.2. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: A unit change without numeric conversion misstates latency by a factor of one thousand. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Either retain 0.2 seconds or explicitly render 200 milliseconds. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Test a fixture with one second and confirm displayed scale exactly. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 032 — Bytes versus bits

Evidence packet. A memory measurement reports unit By. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A translated graph labels the values as bits without multiplying by eight. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Bits and bytes are distinct dimensions, not stylistic synonyms. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Translate the descriptive noun but preserve unit or explicitly convert. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Validate against a fixed 1024-byte sample and expected displayed values. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 033 — Dimensionless utilization

Evidence packet. A CPU utilization reading is 0.75 on a scale where one denotes full utilisation. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A localizer adds a percent sign but leaves 0.75. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Proportion and percentage formats require a deliberate scaling rule. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Display 75 percent only when a times-one-hundred conversion is configured. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Test zero, one-quarter and unity values at boundaries. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 034 — Counter and UpDownCounter

Evidence packet. A metric describes a current count of active jobs. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translated heading says ‘jobs ever created’ because it sees a numeric count. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: An UpDownCounter can rise and fall whereas cumulative totals describe a different property. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Use ‘currently active jobs’ when instrument and computation support that statement. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Observe a decrement in a fixture and confirm the displayed description remains true. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 035 — Delta temporality

Evidence packet. Two sequential metric points each cover a different reporting interval. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A bilingual note calls their values ‘total since launch’. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Delta temporality describes an interval, not a lifetime accumulation. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Explain the specific window and keep any conversion to cumulative explicit. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare start and end timestamps of successive data points. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 036 — Cumulative temporality

Evidence packet. A monotonic sum accumulates from a start timestamp. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translated report calls every point ‘requests in this minute’. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: A cumulative value needs a rate or difference calculation for interval counts. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Describe the accumulated series honestly or use a verified rate calculation. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Check known increment points and ensure no extra count is invented. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 037 — Histogram percentile

Evidence packet. A graph plots a 95th percentile derived from a latency distribution. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translated caption calls the plotted value an average. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Percentile and mean describe different statistical questions. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Name the percentile and state the aggregation window. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Check a skewed synthetic distribution where p95 and mean differ greatly. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 038 — Bucket boundary inclusivity

Evidence packet. A histogram bucket has an upper boundary used for aggregation. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. An explanation says ‘strictly less than’ when the model uses upper-inclusive boundaries. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: The handling of exact boundary values affects reconciliation and interpretation. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Document the correct boundary convention in the translated tooltip. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Insert a fixture exactly at the boundary and compare bucket counts. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 039 — Gauge value across time

Evidence packet. A gauge records the latest sampled queue depth. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translation calls its chart ‘total queues processed’. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: A point-in-time gauge is not an accumulating throughput count. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Translate as queue depth observed at sample time. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Simulate growth and decline while checking the dashboard label. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 040 — Timeseries cardinality by locale

Evidence packet. A metric adds the viewer’s locale as an attribute for each message string. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The result creates extra series for identical operational events. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Display language should normally be a presentation concern rather than a dynamic measurement dimension. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Keep metric labels stable and localize legend text outside the stream. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare series counts before and after enabling several UI languages. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

12. Casebook: Logs, severity and incident narrative

The logs chapter asks what happened, when it happened, when it was observed, and which component recorded it. Translating a log body is closer to translating a witness statement than translating a button: evidence can be incomplete, delayed, sensitive or produced by a particular software perspective.

Diagnostic 041 — Event time versus observed time

Evidence packet. A delayed log has Timestamp 09:01 and ObservedTimestamp 09:04. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A translated timeline claims the event happened at 09:04. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Occurrence and observation are not interchangeable times. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Label both fields and explain delayed collection without reassigning event time. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Sort by event timestamp and by arrival time to expose the difference. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 042 — Severity text and severity number

Evidence packet. A record carries SeverityText WARN with a corresponding numerical level. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translation upgrades WARN to ‘critical outage’ by tone alone. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: A language label must respect the actual severity mapping and incident policy. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Display a calibrated warning term with the original numeric signal available. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Review examples across all levels for monotonic meaning. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 043 — Log Body and structured attributes

Evidence packet. A Body says ‘retry scheduled’ while an attribute holds attempt=2. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translation says ‘retry completed’ and ignores the numeric context. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Scheduled action and completed outcome are different events. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Keep the verb tense and include attempt information when needed. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Check subsequent events for an actual completion record. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 044 — EventName stable identifier

Evidence packet. A log has EventName=payment.validation.failed. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. An operator translates the EventName token itself into a free-form sentence. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Event name can identify event classes used by queries and automation. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Keep the class token, translate a displayed description, and track the mapping. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Run searches for the exact EventName in all locales. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 045 — Exception type versus message

Evidence packet. An exception carries exception.type and exception.message. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translated report turns a message about one failed attempt into a new exception type. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Exception class identifies technical classification; message supplies variable context. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Keep classification intact and translate safe explanatory text with uncertainty preserved. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Group incidents by exception.type and compare against the bilingual report. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 046 — Stack trace paths

Evidence packet. A stack trace includes file names, module names and line positions. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. An eager translator translates source file names and path separators. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Stack traces are debugging evidence, not paragraphs to normalise. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Preserve code tokens and explain the stack frame meaning in adjacent language. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Open the referenced source position or match the build artifact. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 047 — Log correlation IDs

Evidence packet. An application log contains TraceId but no SpanId. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translated text invents a span ID to make the display look complete. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Missing correlation fields are not permission to invent an association. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Label the missing field as unavailable and keep the known trace link. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare the raw log record and assert no synthetic ID was introduced. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 048 — Multiline error messages

Evidence packet. A log Body contains several lines including a command and failure summary. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translator merges lines and accidentally changes command boundaries. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Machine snippets and human narration require different handling. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Preserve the command in a code block and translate the explanatory lines. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Copy the original command from the target view and compare exact bytes. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 049 — Redacted message content

Evidence packet. A token is already redacted in the original incident excerpt. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The target-language report reconstructs the likely secret from surrounding context. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Redaction is part of the publication contract and cannot be undone by interpretation. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Preserve redaction marks and explain that material was withheld. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare disclosures in both languages under a privacy review. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 050 — No logs found

Evidence packet. A search for an incident identifier returns an empty log result. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A localised dashboard says ‘nothing happened’. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Data absence may reflect permissions, retention, query filters or collection loss. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Use ‘no matching records in this search’ with scope and time window. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Repeat with authorised filters and evaluate signal health. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

13. Casebook: Messaging, queues and asynchronous work

Messaging records can show intention, submission, delivery, processing, acknowledgment and commitment as separate events. A translation that makes each stage sound final invents success or failure. This chapter keeps asynchronous stages distinguishable.

Diagnostic 051 — Publish versus consume

Evidence packet. A producer span reports sending a message and a consumer span reports later work. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translated runbook labels publish as ‘processing finished’. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Submission and downstream execution are distinct stages. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Use separate verbs for sent, received, acknowledged and completed. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Trace one message through producer and consumer evidence. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 052 — Acknowledgment semantics

Evidence packet. A consumer acknowledges a message to the broker. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translated status says ‘business transaction approved’. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Transport acknowledgment is not the same as business acceptance. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Describe broker acknowledgment narrowly and separately from business outcome. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare acknowledgment event with application decision record. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 053 — Dead-letter queue

Evidence packet. A message is routed to a dead-letter queue after retry policy is exhausted. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translation calls the message deleted forever. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Dead-letter routing may retain a message for diagnosis or reprocessing. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Explain routing to a special failure queue without inventing deletion. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Check the broker’s recorded destination and retention policy. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 054 — Redelivery and duplicates

Evidence packet. One job appears twice after a consumer restart. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translated report says there were two independent customer orders. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Repeated delivery is not proof of distinct business requests. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Keep message identity and distinguish delivery attempts from logical jobs. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Correlate message IDs and idempotency records. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 055 — Queue length gauge

Evidence packet. A metric shows current queued messages. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A translated panel calls this ‘messages processed per second’. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Queue depth and processing throughput answer different questions. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Use a queue-depth label and a separately calculated throughput panel. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare a stalled consumer fixture to both graphs. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 056 — Delivery delay versus handler duration

Evidence packet. A message waits before processing and then runs quickly. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The target text calls waiting time ‘execution time’. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Delay and processing duration have different start and end boundaries. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Name each interval explicitly in the legend. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare enqueue, dequeue, handler start and handler end times. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 057 — Consumer group identity

Evidence packet. A message attribute identifies an exact consumer group. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translation changes the group token to a friendlier phrase in filters. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Consumer-group names can participate in operational configuration and aggregation. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Retain the exact group value, localise only its descriptive caption. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Query events using the unchanged group identifier. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 058 — Partition and ordering

Evidence packet. A record contains partition index 4 and offset 720. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A translated narrative promises global order across all partitions. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Per-partition ordering does not automatically prove total ordering across a distributed stream. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Explain the scope of the sequence and keep offsets numeric. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare another partition’s offsets before claiming global sequence. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 059 — Retry exhausted versus retry pending

Evidence packet. An event reports that a retry is scheduled later. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The localisation calls the attempt final failure. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Future work and exhausted policy have different operator consequences. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Use language that preserves schedule and remaining attempts. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Inspect retry state and confirm the next execution window. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 060 — Async span link

Evidence packet. A consumer span links to the producer trace context. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The multilingual incident chart draws it as a synchronous child. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Links can express causal relationships without direct parentage. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Show an asynchronous relationship and preserve source and target contexts. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Follow correlation and ensure no fictional synchronous call is added. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

14. Casebook: Databases, queries and storage

Database terminology often hides a distinction between executing a statement, returning a result and committing durable state. The examples preserve schema references and avoid attributing every application delay to the database server without independent evidence.

Diagnostic 061 — Database system token

Evidence packet. A span has a db.system.name value for a database technology. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A translator replaces the technology key with a generic word in queries. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Database system identity may govern instrumentation semantics and dashboards. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Keep the canonical token and translate the descriptive display field. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Run the same database facet filter in both languages. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 062 — Database operation

Evidence packet. A field describes SELECT as the operation. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A translation renders it as ‘update’ because the resulting page changed. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Read operations and write operations have different risk and performance implications. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Retain SELECT as the operation and explain UI effects separately. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare executed statements with the displayed operation. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 063 — Database namespace

Evidence packet. A span identifies a database namespace called inventory_main. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translated filter uses a spaced human-friendly title. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Namespace tokens identify stored resources and are not user-facing page titles. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Keep the namespace exact and display a separate friendly description. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Query the real namespace and check it resolves. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 064 — SQL query text privacy

Evidence packet. A diagnostic contains a parameterized SQL statement and user-specific values. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translation publishes an expanded statement containing sensitive arguments. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Query text can disclose private data even when the surrounding prose is innocuous. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Apply approved redaction and preserve statement structure where sharing is allowed. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Check export permissions and search target document for secrets. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 065 — Rows affected versus rows returned

Evidence packet. A database event reports rows affected by a statement. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translated incident says rows returned to the client. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: These counts measure different consequences and may vary greatly. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Use precise nouns tied to actual instrumentation and statement type. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Test an UPDATE followed by SELECT with intentionally different row counts. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 066 — Transaction rollback

Evidence packet. A transaction begins, attempts a write and rolls back. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The target summary says the write was committed because it executed first. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Attempted execution does not prove durable transaction commit. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Preserve rollback status and distinguish tentative from committed state. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Check transaction outcome and resulting database state. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 067 — Connection timeout

Evidence packet. A connection attempt times out before authentication completes. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translation describes a rejected password. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Timeout and authentication rejection demand different troubleshooting. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Name the timeout condition without inventing server intent. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare network reachability and server auth logs. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 068 — Pool saturation

Evidence packet. An application waits for a free database connection in its pool. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A dashboard translation calls this ‘database CPU overload’. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Client-side pool waiting is not proof of database host saturation. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Label pool wait and separate it from CPU and server load metrics. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Cross-reference pool occupancy and host utilisation. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 069 — Cache hit versus database read

Evidence packet. A request completes from cache without querying storage. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The localised report claims every request was read from the database. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Caching changes which component served the response. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Translate cache hit and miss accurately and avoid unwarranted backend attribution. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare cache event counters and query spans. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 070 — Schema change and field mapping

Evidence packet. A database column is renamed during an application migration. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A translator treats the rename as a synonym-only language update. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Column changes affect queries, serialization and interpretation of historical data. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Keep language editing separate from schema migration with explicit crosswalks. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Test historical queries across migration boundaries. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

15. Casebook: Infrastructure, runtime and platform events

Runtime observations have scope. A pod can fail readiness while the process runs; a collector can buffer records while the application serves requests. A bilingual incident narrative should say which layer exhibited the condition before claiming an outage.

Diagnostic 071 — Pod restart count

Evidence packet. A Kubernetes metric reports container restarts. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A translated incident says the cluster restarted completely. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Container restart and cluster restart have different scopes. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Use the exact component scope in the target-language statement. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare container ID, pod ID and control plane evidence. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 072 — Readiness versus liveness

Evidence packet. A pod fails readiness checks but remains running. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The target dashboard says the process has crashed. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Readiness governs ability to serve traffic and need not imply process death. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Describe not-ready status without asserting termination. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare process activity, liveness probe and endpoint readiness. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 073 — Deployment rollout state

Evidence packet. A rollout pauses after creating new replicas. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translated note announces successful completion. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Partial deployment and completed rollout are distinct states. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. State what fraction or step has actually completed. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Inspect rollout conditions and desired versus available replicas. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 074 — Autoscaling target

Evidence packet. An autoscaler requests more instances based on a target. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translation says the requested instances already exist. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Desired capacity is a control decision, not proof of actual supply. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Use ‘desired replicas’ and ‘available replicas’ separately. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare scheduler and node allocation results. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 075 — CPU utilization versus usage time

Evidence packet. A chart shows processor utilization as a fraction. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The target label interprets it as cumulative CPU seconds. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Fraction and accumulated processor time have distinct units. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Translate according to the measured instrument and calculation. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Check raw metric name, unit and aggregation. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 076 — Memory resident versus allocated

Evidence packet. A process reports resident memory bytes. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translation describes total memory ever allocated. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Current resident memory is not historical cumulative allocation. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Use a current-resident-memory description with bytes. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare values before and after garbage collection. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 077 — Network receive and transmit

Evidence packet. A service records inbound and outbound network bytes separately. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translated legend swaps received and sent labels. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Direction changes who is believed to be sending data. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Preserve directional definitions from the observed component perspective. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Use asymmetric synthetic traffic to detect reversal. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 078 — Container image version

Evidence packet. A resource has both a human version tag and a content digest. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A translated status treats the tag as a cryptographic identifier. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Tags and immutable digests answer different provenance questions. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Preserve both and label each with its correct role. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Resolve tag and digest against the release manifest. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 079 — Clock skew across nodes

Evidence packet. Two hosts report timestamps that appear inverted. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translated incident infers backward causality immediately. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Clock uncertainty can affect observed order and must be qualified. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. State the clock-sync limitation and cite cross-system correlation evidence. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare NTP health and causal trace relationships. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 080 — Collector backlog

Evidence packet. A collector buffers telemetry because export is temporarily unavailable. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The target view says the application stopped processing requests. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Delayed telemetry export is not identical to application downtime. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Describe exporter backlog and distinguish observed service state. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Use an independent health signal and queue depth to test the claim. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

16. Casebook: Dashboards, query language and reader decisions

Dashboard translation is an interface design decision layered on analytics. A translated title should be treated as a claim about the query and chart transformation, not as decoration. The correct question is whether a second-language operator makes the same safe decision from the same data.

Diagnostic 081 — Translated chart title

Evidence packet. A chart computes a request rate from a counter. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The target heading calls the chart ‘total requests’. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Rate and cumulative total differ even when both reference the same metric. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Name the derived rate and its interval in the user-facing caption. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare graph query and input data before approving title. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 082 — Legend with service name

Evidence packet. A legend contains the exact value of service.name. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translation replaces a service label used as a query dimension. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: The legend may combine a localisable heading and a nonlocalisable data value. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Localise the heading while keeping the series key stable. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Click the series filter and compare source and target queries. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 083 — Alert firing versus pending

Evidence packet. An alert rule is in its pending stage. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translated badge says the alert has fired. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Pending and firing states imply different escalation actions. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Adopt calibrated status words mapped to actual alert states. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Feed synthetic state transitions and verify wording for every step. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 084 — Alert resolved versus silenced

Evidence packet. An alert is silenced for maintenance but its condition persists. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translation says the underlying fault has been fixed. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: A silenced notification is not a resolved signal. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Describe suppression or silence separately from recovery. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare rule evaluation with silence metadata. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 085 — Threshold operator

Evidence packet. A rule triggers when latency is greater than 0.5 seconds. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A translated tooltip says greater than or equal to 0.5. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: The inequality operator determines boundary behaviour. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Keep the exact mathematical comparison and unit in the explanation. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Test values immediately below, exactly at and above the threshold. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 086 — Percentile explanation

Evidence packet. A latency graph shows the 99th percentile of observations. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translation tells readers that 99 percent of requests always have that exact latency. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: A percentile is a distribution cutoff, not an individual constant. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Explain that the observed fraction falls at or below the cutoff within the stated window. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Check a small sorted fixture and derive the value independently. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 087 — Time-zone display

Evidence packet. A chart formats timestamps for each viewer’s preference. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A translated incident uses the local time without naming its zone. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Different display zones can make the same instant appear contradictory. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Include an explicit zone and preserve UTC instants in evidence logs. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Convert a fixture across two zones and confirm equal timestamps. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 088 — Decimal punctuation

Evidence packet. A value of 1.25 seconds is displayed with locale-specific punctuation. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. An export feeds the formatted text back into a numeric parser as 125. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Human display formatting must not replace typed numeric storage. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Keep machine numeric values locale-neutral and format only in the UI. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Round-trip parse numeric fixtures in each supported locale. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 089 — No-data visual

Evidence packet. A dashboard shows no data for a selected period. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The target-language message says the service had zero requests. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: No visible data can also reflect failed ingestion, permissions or filtering. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Use a qualified ‘no data returned’ description with query scope. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare collection health and an independent request counter. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 090 — Runbook action link

Evidence packet. A help string links to a specific verified remediation procedure. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translator points the button to an unrelated language landing page. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Translating the label does not justify changing the action destination arbitrarily. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Preserve the route or select an approved equivalent procedure with owner review. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Follow each language-specific action link in a staging environment. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

17. Casebook: Privacy, access control and threat interpretation

Privacy decisions travel with exported messages and screenshots. A language project needs the minimum data required to explain an incident, not the maximum raw records available. Cases distinguish direct observation, access scope, classification and safe publication.

Diagnostic 091 — Personal data in baggage

Evidence packet. A propagated baggage field contains a customer email for tracing convenience. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translation republishes the email inside a shareable dashboard screenshot. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Propagation can spread sensitive content across service boundaries. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Remove or minimise the unsafe baggage at its source and redact public explanations. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Inspect downstream propagation and screenshot outputs for identifiers. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 092 — Authentication result

Evidence packet. A log records an authentication attempt denied by policy. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translated summary says the user entered an incorrect password. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Authorization policy and password validity are distinct possible explanations. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Describe the observed denial without inventing credential failure. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Inspect the actual failure code and permission rules. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 093 — Token-like query string

Evidence packet. An HTTP attribute contains a URL with a credential-bearing query parameter. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The localisation adds the full URL to an illustrative troubleshooting example. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Translating explanatory material must not leak secrets stored in source telemetry. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Redact or exclude sensitive query fields under security rules. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Scan the target assets and compare sanctioned redaction coverage. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 094 — Permission denied versus not found

Evidence packet. A restricted dashboard query returns no visible records to one role. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translated message says the trace never existed. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Access scope affects visibility; absence under one role does not prove absence. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Explain the query’s visibility limitations without revealing protected resources. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare authorised and restricted fixture roles. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 095 — Audit log actor

Evidence packet. An audit record identifies a service principal that performed a deployment. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translated note describes it as a named human employee. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Service identities and people are not interchangeable provenance subjects. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Retain the actor type and exact principal ID. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare role bindings and audit events without assigning fictional human agency. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 096 — Redaction markers

Evidence packet. An incident excerpt uses [REDACTED] for a personal detail. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The target language replaces it with a plausible invented name to make prose read smoothly. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Invented identities are false claims and may expose protected patterns. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Keep the redaction clearly visible and translate only its explanatory label. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Run a bilingual redaction parity comparison. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 097 — Security finding versus alert hypothesis

Evidence packet. A heuristic detector raises an alert about unusual network traffic. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translated summary states a confirmed breach occurred. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: A detection signal is not an adjudicated finding of compromise. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Preserve confidence and investigation status in the grammar. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare corroborating evidence before changing incident classification. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 098 — Health-data payload

Evidence packet. An application log accidentally captures a health-data value. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translation team stores it in an unrestricted translation memory. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Sensitive records require restricted processing independent of language. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Use sanitized fixtures and controlled access, not raw private payloads. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Verify translation-memory retention and access policy. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 099 — Private endpoint names

Evidence packet. A diagnostic includes internal service hostnames. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translated public article reproduces those hostnames as if harmless vocabulary. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Infrastructure names may reveal topology even without passwords. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Use fictional or approved redacted identifiers in public materials. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Check public export against a sensitive-pattern inventory. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 100 — Bilingual escalation details

Evidence packet. A runbook has urgent contact instructions in several languages. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. One translation changes the emergency escalation order and discloses a private phone number. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Procedural instructions and contact data require owner-approved governance. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Keep action priority consistent and expose only authorised contact channels. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Perform role-specific drill and verify the same escalation path. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

18. Casebook: Versioning, migration and release safety

Versioning joins language governance with engineering governance. A glossary update cannot magically migrate a producer, and a new attribute emitted in a dual period must not be counted twice. These examples use change windows and schema snapshots as proof.

Diagnostic 101 — Semantic convention revision

Evidence packet. An instrumentation upgrade changes a field under a documented convention migration. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translated glossary keeps the old meaning but presents the new token as a synonym. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Schema evolution requires matching producers and consumers, not just a dictionary edit. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Maintain versioned mappings and state supported instruments explicitly. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare snapshots produced before and after the upgrade. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 102 — Schema URL

Evidence packet. Telemetry carries a schema URL identifying an applicable schema. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A language editor rewrites the URL path into translated words. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Schema URLs identify technical contracts and must remain valid references. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Translate explanatory text but retain the original URL. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Dereference or validate the identifier in the approved environment. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 103 — Dual-emission transition

Evidence packet. Instrumentation emits both old and new attributes during a migration. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translated dashboard adds the values together and doubles apparent events. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Duplicate representations may describe one observation rather than separate activity. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Document deduplication and migration windows clearly. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare event counts across old-only, dual and new-only fixtures. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 104 — Collector attribute transform

Evidence packet. A collector is configured to rename a custom attribute key. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A translator assumes the changed key is merely another regional spelling. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Collector transformations change data contracts consumed downstream. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Put the key change in a technical migration specification. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Test filters, alerts and exports for both historical and new streams. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 105 — Versioned runbooks

Evidence packet. A translated runbook is updated before the corresponding software deployment. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. Operators follow instructions for behaviour not yet released. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Documentation version, instrumentation version and deployment version need alignment. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Publish compatibility information and safe rollback routes. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Rehearse with pre-upgrade and post-upgrade data fixtures. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 106 — Missing locale fallback

Evidence packet. A target-language string has no approved translation yet. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The system displays an automatic machine guess of an error classification. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Unverified fallback can sound authoritative about operational evidence. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Use a known, reviewed default label with clear language fallback. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Check every missing-key path with a synthetic fixture. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 107 — Right-to-left layout

Evidence packet. A target interface uses a right-to-left writing system. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The dashboard reorders numbers, signs and opaque trace IDs visually. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Directionality and bidirectional text can change readability without changing bytes. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Use appropriate isolation for machine tokens and test screen-reader order. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Copy IDs and compare exact bytes from both writing directions. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 108 — Pluralization of requests

Evidence packet. A tooltip describes one request and a chart describes many. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translation uses the singular everywhere, making rates and totals confusing. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Grammar should follow the measured quantity without changing its type. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Apply locale-appropriate plural rules only in text rendering. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Test zero, one, two and fractional quantities. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 109 — Release note claims

Evidence packet. A translation release note announces support for a new semantic convention. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The text implies the instrumentation actually emits it although only labels were added. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Language assets do not create new telemetry measurements. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. State precisely whether support is display-only, ingestion-only or end-to-end. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Check emitted fixtures against the claim before publication. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 110 — Rollback of language assets

Evidence packet. An alert label is found misleading after release. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The team rolls back the entire instrumentation pipeline rather than the string pack. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Presentation rollback and telemetry schema rollback have different blast radii. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Keep a separate versioned localisation artifact and a reversible deployment plan. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Prove the old language assets can be restored without data loss. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

19. Casebook: Cross-team diagnostics and transfer exercises

The final chapter is about transfer: can someone who did not write the original dashboard diagnose a system in another language without receiving distorted evidence? It tests translated summaries, handovers, accessible interfaces, exports and incident decisions.

Diagnostic 111 — Translator asks about ‘failed’

Evidence packet. A source incident uses ‘failed’ in the title but raw spans show Unset status. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translation silently strengthens it into a system-wide failure. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Editorial wording needs a claim-evidence check against status and user impact. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Ask the incident owner whether failure is observed, inferred or confirmed. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Audit every causal adjective against a source observation. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 112 — Incident timeline across languages

Evidence packet. Two analysts create timelines from the same frozen telemetry. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The second-language timeline reverses an event because a timestamp was formatted ambiguously. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: A trustworthy narrative must preserve exact temporal order and zone. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Write each event with explicit time basis and cite the source record. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Recreate both timelines from event timestamps. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 113 — Support ticket paraphrase

Evidence packet. A user reports ‘the page is slow’ while telemetry shows elevated p95 duration. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translation says all requests failed and the database was unavailable. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Complaint, measurement and causal explanation are different evidence levels. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Keep the user’s observation separate from metric interpretation and hypothesis. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Cross-check the claim against request counts and error signals. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 114 — Customer-facing status notice

Evidence packet. An incident is under investigation with no confirmed cause. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translated notice presents an unverified dependency as the cause. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: A definitive cause claim may misinform customers and create accountability problems. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Use appropriately qualified language and include the verified impact window. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare the notice to current incident commander approval. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 115 — SRE handover note

Evidence packet. A shift handover lists three open hypotheses and one confirmed finding. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translation removes hedges and merges all four into a conclusion. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Evidence status must travel with each statement. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Label confirmed, probable and untested points separately. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Have the receiving team classify every statement before reading the original. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 116 — Accessibility and screen reader

Evidence packet. A dashboard represents an alert only by red colour. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The target language supplies a translated colour word but no alert state. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Accessible interpretation needs state conveyed independently of colour. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Provide an explicit text state and descriptive label. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Test with high contrast and screen reader enabled. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 117 — Training glossary boundary

Evidence packet. A junior analyst asks whether ‘span’ means ‘duration’ in the interface. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The glossary translates span as ‘time window’ everywhere. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: A span is an operation record with more than duration. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Define the technical object first and explain timing as one component. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Ask trainees to distinguish span, event and duration in a sample. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 118 — Incident export to PDF

Evidence packet. The UI displays a fully localized dashboard but the exported PDF contains raw names without explanatory legend. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The exported report loses the semantic bridge used by dashboard readers. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Export is a separate publication surface requiring its own QA. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Carry approved captions and preserve machine values in the export. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Read the PDF independently from the UI and reproduce the same diagnosis. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 119 — Cross-vendor dashboard view

Evidence packet. Two monitoring products render the same OTLP stream with different visual defaults. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. The translation calls a vendor-derived chart an authoritative property of OTel. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Visualization defaults are product choices, not core telemetry semantics. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Name the dashboard calculation and verify it from raw inputs. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Compare both products against a common fixture. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

Diagnostic 120 — Final incident acceptance test

Evidence packet. A bilingual team must decide whether to page on a specific alert. This is a fictional record for quality testing, not a production incident. The translator should first name the actual observable and the person who depends on it: an operator may need to filter a query, an analyst may need to defend a timeline, or a support writer may need to explain an outcome. In each case, the original record is the reference; a target-language sentence is an interpretation that must remain traceable to that reference. A good review starts by asking what exact fact would have to be true for the translated sentence to be justified.

Attractive but wrong rendering. A mistranslated runbook could page for a pending condition or suppress a firing condition. That change may appear linguistically harmless because the target sentence reads fluently without the source record. In an observability workflow, however, fluency alone is weak evidence. It can replace an identifier, erase a qualification, alter the boundary of a measurement or convert an assumption into a verified fact. Here the relevant constraint is specific: Operational actions are the strongest test of meaning transfer. The problem is therefore not an arbitrary preference for English terms; it is a conflict between language and an operational contract.

Corrected translation decision. Use frozen pending, firing, silenced and resolved fixtures with expected decisions. Write the approved target-language explanation as a separate, reviewable field or documentation component where possible. Preserve the machine value and its type, capture the source schema or instrumentation version, and attach a one-sentence rationale to the termbase. If a change is actually needed to an instrument, attribute or backend query, open a distinct engineering migration request; never hide that change inside a translation ticket. Keep the distinction between observed fact, possible interpretation and prescribed operator action explicit.

Acceptance diagnostic. Require both language teams to select the same approved action. Then repeat the check through the entire chain: producer, collector where applicable, backend, language-specific interface and exported incident report. The reviewer should be able to point to the same event or value in every language and recover exactly the same operational result. Mark the example as passed only when the target reader can state what is known, what is not established and what action is justified. If either the measurement or the decision changes, return the unit for technical and linguistic revision.

20. Twenty-four failure modes and their repair logic

Failure mode 1: Blindly translating every string

Classify each field before editing. Opaque identifiers, keys, type names and URLs may be meaningful as exact strings rather than natural language. To diagnose the failure, compare one source fixture, one target rendering and the resulting operator action. Document whether the issue is linguistic, conceptual, technical, accessibility-related, privacy-related or a mixed defect. A correction is complete only if the same misunderstanding cannot recur through adjacent labels, examples or exports. The audit trail should name the affected string, dataset version, corrected wording, technical test and approving owner.

Failure mode 2: Treating every ‘error’ as one event

Identify whether the text refers to an HTTP response, exception, span status, log severity, alert rule or business outcome. To diagnose the failure, compare one source fixture, one target rendering and the resulting operator action. Document whether the issue is linguistic, conceptual, technical, accessibility-related, privacy-related or a mixed defect. A correction is complete only if the same misunderstanding cannot recur through adjacent labels, examples or exports. The audit trail should name the affected string, dataset version, corrected wording, technical test and approving owner.

Failure mode 3: Changing units without numbers

Tie the translated label to an explicit display conversion and test known fixtures, including zero and boundary values. To diagnose the failure, compare one source fixture, one target rendering and the resulting operator action. Document whether the issue is linguistic, conceptual, technical, accessibility-related, privacy-related or a mixed defect. A correction is complete only if the same misunderstanding cannot recur through adjacent labels, examples or exports. The audit trail should name the affected string, dataset version, corrected wording, technical test and approving owner.

Failure mode 4: Conflating delta and cumulative measurements

Write the accumulation window and transformation into the chart description; verify metric data-model semantics. To diagnose the failure, compare one source fixture, one target rendering and the resulting operator action. Document whether the issue is linguistic, conceptual, technical, accessibility-related, privacy-related or a mixed defect. A correction is complete only if the same misunderstanding cannot recur through adjacent labels, examples or exports. The audit trail should name the affected string, dataset version, corrected wording, technical test and approving owner.

Failure mode 5: Flattening time zones

Preserve source instants and explicitly mark presentation zones, event versus observed time, and possible clock skew. To diagnose the failure, compare one source fixture, one target rendering and the resulting operator action. Document whether the issue is linguistic, conceptual, technical, accessibility-related, privacy-related or a mixed defect. A correction is complete only if the same misunderstanding cannot recur through adjacent labels, examples or exports. The audit trail should name the affected string, dataset version, corrected wording, technical test and approving owner.

Failure mode 6: Turning absent data into zero

Qualify search coverage, permissions, retention, sampling and ingestion health before making a zero-event claim. To diagnose the failure, compare one source fixture, one target rendering and the resulting operator action. Document whether the issue is linguistic, conceptual, technical, accessibility-related, privacy-related or a mixed defect. A correction is complete only if the same misunderstanding cannot recur through adjacent labels, examples or exports. The audit trail should name the affected string, dataset version, corrected wording, technical test and approving owner.

Failure mode 7: Merging identity scopes

Preserve distinctions among service, service instance, process, host, container, pod and deployment. To diagnose the failure, compare one source fixture, one target rendering and the resulting operator action. Document whether the issue is linguistic, conceptual, technical, accessibility-related, privacy-related or a mixed defect. A correction is complete only if the same misunderstanding cannot recur through adjacent labels, examples or exports. The audit trail should name the affected string, dataset version, corrected wording, technical test and approving owner.

Failure mode 8: Normalising case-sensitive keys

Do not title-case, translate or re-punctuate semantic attribute keys because a displayed heading looks better. To diagnose the failure, compare one source fixture, one target rendering and the resulting operator action. Document whether the issue is linguistic, conceptual, technical, accessibility-related, privacy-related or a mixed defect. A correction is complete only if the same misunderstanding cannot recur through adjacent labels, examples or exports. The audit trail should name the affected string, dataset version, corrected wording, technical test and approving owner.

Failure mode 9: Translating route parameters

Protect braces, route tokens and path conventions that may be consumed by grouping and query tools. To diagnose the failure, compare one source fixture, one target rendering and the resulting operator action. Document whether the issue is linguistic, conceptual, technical, accessibility-related, privacy-related or a mixed defect. A correction is complete only if the same misunderstanding cannot recur through adjacent labels, examples or exports. The audit trail should name the affected string, dataset version, corrected wording, technical test and approving owner.

Failure mode 10: Making sampling invisible

State what is sampled and which aggregate metrics can support statements about requests not captured in traces. To diagnose the failure, compare one source fixture, one target rendering and the resulting operator action. Document whether the issue is linguistic, conceptual, technical, accessibility-related, privacy-related or a mixed defect. A correction is complete only if the same misunderstanding cannot recur through adjacent labels, examples or exports. The audit trail should name the affected string, dataset version, corrected wording, technical test and approving owner.

Failure mode 11: Erasing hedges

Keep probability and uncertainty markers when a source says ‘may’, ‘suspected’ or ‘under investigation’. To diagnose the failure, compare one source fixture, one target rendering and the resulting operator action. Document whether the issue is linguistic, conceptual, technical, accessibility-related, privacy-related or a mixed defect. A correction is complete only if the same misunderstanding cannot recur through adjacent labels, examples or exports. The audit trail should name the affected string, dataset version, corrected wording, technical test and approving owner.

Failure mode 12: Inventing causes

Separate performance symptoms from verified technical causes; approval must come from the accountable incident owner. To diagnose the failure, compare one source fixture, one target rendering and the resulting operator action. Document whether the issue is linguistic, conceptual, technical, accessibility-related, privacy-related or a mixed defect. A correction is complete only if the same misunderstanding cannot recur through adjacent labels, examples or exports. The audit trail should name the affected string, dataset version, corrected wording, technical test and approving owner.

Failure mode 13: Confusing operational and business success

Distinguish a successful HTTP call from a rejected order, or an acknowledged message from a completed transaction. To diagnose the failure, compare one source fixture, one target rendering and the resulting operator action. Document whether the issue is linguistic, conceptual, technical, accessibility-related, privacy-related or a mixed defect. A correction is complete only if the same misunderstanding cannot recur through adjacent labels, examples or exports. The audit trail should name the affected string, dataset version, corrected wording, technical test and approving owner.

Failure mode 14: Copying secrets into translation memory

Sanitise data and apply access controls before sending text to language providers or automated systems. To diagnose the failure, compare one source fixture, one target rendering and the resulting operator action. Document whether the issue is linguistic, conceptual, technical, accessibility-related, privacy-related or a mixed defect. A correction is complete only if the same misunderstanding cannot recur through adjacent labels, examples or exports. The audit trail should name the affected string, dataset version, corrected wording, technical test and approving owner.

Failure mode 15: Adding locale as a metric dimension

Translate presentation labels outside raw measurement streams unless instrument owners have assessed series cardinality. To diagnose the failure, compare one source fixture, one target rendering and the resulting operator action. Document whether the issue is linguistic, conceptual, technical, accessibility-related, privacy-related or a mixed defect. A correction is complete only if the same misunderstanding cannot recur through adjacent labels, examples or exports. The audit trail should name the affected string, dataset version, corrected wording, technical test and approving owner.

Failure mode 16: Dropping identifiers in summaries

Retain a stable citation, full correlation ID or validated deep link so the translated claim remains auditable. To diagnose the failure, compare one source fixture, one target rendering and the resulting operator action. Document whether the issue is linguistic, conceptual, technical, accessibility-related, privacy-related or a mixed defect. A correction is complete only if the same misunderstanding cannot recur through adjacent labels, examples or exports. The audit trail should name the affected string, dataset version, corrected wording, technical test and approving owner.

Failure mode 17: Hiding query expressions

Review the actual query or aggregation behind each localized title instead of relying on a chart screenshot alone. To diagnose the failure, compare one source fixture, one target rendering and the resulting operator action. Document whether the issue is linguistic, conceptual, technical, accessibility-related, privacy-related or a mixed defect. A correction is complete only if the same misunderstanding cannot recur through adjacent labels, examples or exports. The audit trail should name the affected string, dataset version, corrected wording, technical test and approving owner.

Failure mode 18: Treating vendor display choices as standards

Separate OpenTelemetry’s data model from product-specific chart defaults, help labels and alert policies. To diagnose the failure, compare one source fixture, one target rendering and the resulting operator action. Document whether the issue is linguistic, conceptual, technical, accessibility-related, privacy-related or a mixed defect. A correction is complete only if the same misunderstanding cannot recur through adjacent labels, examples or exports. The audit trail should name the affected string, dataset version, corrected wording, technical test and approving owner.

Failure mode 19: Overpromising fallback translation

When an approved string is missing, use a reviewed fallback rather than an unverified operational paraphrase. To diagnose the failure, compare one source fixture, one target rendering and the resulting operator action. Document whether the issue is linguistic, conceptual, technical, accessibility-related, privacy-related or a mixed defect. A correction is complete only if the same misunderstanding cannot recur through adjacent labels, examples or exports. The audit trail should name the affected string, dataset version, corrected wording, technical test and approving owner.

Failure mode 20: Ignoring text direction

Test bidirectional isolation for IDs, ranges, comparison operators and code tokens in right-to-left interfaces. To diagnose the failure, compare one source fixture, one target rendering and the resulting operator action. Document whether the issue is linguistic, conceptual, technical, accessibility-related, privacy-related or a mixed defect. A correction is complete only if the same misunderstanding cannot recur through adjacent labels, examples or exports. The audit trail should name the affected string, dataset version, corrected wording, technical test and approving owner.

Failure mode 21: Converting severity to incident priority

Map severity, impact and escalation independently under the organisation’s policy. To diagnose the failure, compare one source fixture, one target rendering and the resulting operator action. Document whether the issue is linguistic, conceptual, technical, accessibility-related, privacy-related or a mixed defect. A correction is complete only if the same misunderstanding cannot recur through adjacent labels, examples or exports. The audit trail should name the affected string, dataset version, corrected wording, technical test and approving owner.

Failure mode 22: Reusing outdated glossary entries

Version the termbase with the semantic-conventions and instrumentation changes actually in production. To diagnose the failure, compare one source fixture, one target rendering and the resulting operator action. Document whether the issue is linguistic, conceptual, technical, accessibility-related, privacy-related or a mixed defect. A correction is complete only if the same misunderstanding cannot recur through adjacent labels, examples or exports. The audit trail should name the affected string, dataset version, corrected wording, technical test and approving owner.

Failure mode 23: Skipping exported artifacts

Test emails, PDFs, incident records, status notices and logs copied out of the product, not just the live dashboard. To diagnose the failure, compare one source fixture, one target rendering and the resulting operator action. Document whether the issue is linguistic, conceptual, technical, accessibility-related, privacy-related or a mixed defect. A correction is complete only if the same misunderstanding cannot recur through adjacent labels, examples or exports. The audit trail should name the affected string, dataset version, corrected wording, technical test and approving owner.

Failure mode 24: Skipping rollback rehearsal

Keep localization artifacts deployable independently and test how the previous approved language view is restored. To diagnose the failure, compare one source fixture, one target rendering and the resulting operator action. Document whether the issue is linguistic, conceptual, technical, accessibility-related, privacy-related or a mixed defect. A correction is complete only if the same misunderstanding cannot recur through adjacent labels, examples or exports. The audit trail should name the affected string, dataset version, corrected wording, technical test and approving owner.

21. Transfer workshops: practice beyond memorised cases

Workshop 1: A trace crosses three services

Create a frozen tree with a root, two children, one link and a recorded exception. Ask trainees to draft a one-paragraph timeline in two languages, retaining exact IDs and identifying a hypothesis separately. Expected evidence: a short bilingual result, the raw records used, a list of preserved identifiers, a table of any calculations and one clearly documented uncertainty. Pass standard: a reviewer who sees only the translated result can independently perform the correct next action. Record false positives and missed hazards separately so the next training session addresses actual decision errors rather than only grammar.

Workshop 2: Build a latency dashboard

Give a counter, a histogram and a gauge with declared units. Ask readers to name each chart, describe p95 honestly, and identify any requested display conversions. Expected evidence: a short bilingual result, the raw records used, a list of preserved identifiers, a table of any calculations and one clearly documented uncertainty. Pass standard: a reviewer who sees only the translated result can independently perform the correct next action. Record false positives and missed hazards separately so the next training session addresses actual decision errors rather than only grammar.

Workshop 3: Write an incident notice

Provide pending and firing alert states plus sampled tracing. Make teams write a customer-facing update that does not invent a cause or confuse lack of traces with zero requests. Expected evidence: a short bilingual result, the raw records used, a list of preserved identifiers, a table of any calculations and one clearly documented uncertainty. Pass standard: a reviewer who sees only the translated result can independently perform the correct next action. Record false positives and missed hazards separately so the next training session addresses actual decision errors rather than only grammar.

Workshop 4: Review an asynchronous message

Provide producer, broker acknowledgment, consumer retries and a dead-letter event. Require separate verbs for each stage and prove where final outcome is still unknown. Expected evidence: a short bilingual result, the raw records used, a list of preserved identifiers, a table of any calculations and one clearly documented uncertainty. Pass standard: a reviewer who sees only the translated result can independently perform the correct next action. Record false positives and missed hazards separately so the next training session addresses actual decision errors rather than only grammar.

Workshop 5: Differentiate a database rollback

Provide SQL attempt events, rollback confirmation and a later read. Ask trainees to correct a report that implies the attempted write was committed. Expected evidence: a short bilingual result, the raw records used, a list of preserved identifiers, a table of any calculations and one clearly documented uncertainty. Pass standard: a reviewer who sees only the translated result can independently perform the correct next action. Record false positives and missed hazards separately so the next training session addresses actual decision errors rather than only grammar.

Workshop 6: Audit a translated runbook

Supply a source procedure and a target-language draft with one swapped threshold operator, one hidden time zone and one unsafe contact link. Require detection of all three. Expected evidence: a short bilingual result, the raw records used, a list of preserved identifiers, a table of any calculations and one clearly documented uncertainty. Pass standard: a reviewer who sees only the translated result can independently perform the correct next action. Record false positives and missed hazards separately so the next training session addresses actual decision errors rather than only grammar.

Workshop 7: Test a metric unit conversion

Use values of 0, 0.25, 1 and 1024 with units seconds, proportion and bytes. Require exact target display numbers and documented units. Expected evidence: a short bilingual result, the raw records used, a list of preserved identifiers, a table of any calculations and one clearly documented uncertainty. Pass standard: a reviewer who sees only the translated result can independently perform the correct next action. Record false positives and missed hazards separately so the next training session addresses actual decision errors rather than only grammar.

Workshop 8: Investigate resource identity

Supply the same service name across two instances and a rollout. Ask whether a crash affected one process, one pod, one service or the whole platform. Expected evidence: a short bilingual result, the raw records used, a list of preserved identifiers, a table of any calculations and one clearly documented uncertainty. Pass standard: a reviewer who sees only the translated result can independently perform the correct next action. Record false positives and missed hazards separately so the next training session addresses actual decision errors rather than only grammar.

Workshop 9: Reconcile delayed logs

Give both Timestamp and ObservedTimestamp plus simulated exporter backlog. Ask for a chronology that names the collection delay. Expected evidence: a short bilingual result, the raw records used, a list of preserved identifiers, a table of any calculations and one clearly documented uncertainty. Pass standard: a reviewer who sees only the translated result can independently perform the correct next action. Record false positives and missed hazards separately so the next training session addresses actual decision errors rather than only grammar.

Workshop 10: Review secret handling

Include fake tokens, names and internal hostnames in an invented example. Require a sanitized screenshot, safe multilingual synopsis and retained correlation IDs where authorised. Expected evidence: a short bilingual result, the raw records used, a list of preserved identifiers, a table of any calculations and one clearly documented uncertainty. Pass standard: a reviewer who sees only the translated result can independently perform the correct next action. Record false positives and missed hazards separately so the next training session addresses actual decision errors rather than only grammar.

Workshop 11: Exercise right-to-left rendering

Provide a long hexadecimal ID, route pattern, numeric range and a line of right-to-left text. Verify both visual reading order and exact copy-paste bytes. Expected evidence: a short bilingual result, the raw records used, a list of preserved identifiers, a table of any calculations and one clearly documented uncertainty. Pass standard: a reviewer who sees only the translated result can independently perform the correct next action. Record false positives and missed hazards separately so the next training session addresses actual decision errors rather than only grammar.

Workshop 12: Compare two monitoring vendors

Give the same metric stream shown as rate in one interface and cumulative total in another. Ask teams to explain why the translated legends differ and which calculations are authoritative. Expected evidence: a short bilingual result, the raw records used, a list of preserved identifiers, a table of any calculations and one clearly documented uncertainty. Pass standard: a reviewer who sees only the translated result can independently perform the correct next action. Record false positives and missed hazards separately so the next training session addresses actual decision errors rather than only grammar.

Workshop 13: Conduct a release migration

Provide old and new attribute names with a dual-emission window. Require a glossary mapping that avoids double counting and a reversible dashboard change. Expected evidence: a short bilingual result, the raw records used, a list of preserved identifiers, a table of any calculations and one clearly documented uncertainty. Pass standard: a reviewer who sees only the translated result can independently perform the correct next action. Record false positives and missed hazards separately so the next training session addresses actual decision errors rather than only grammar.

Workshop 14: Mark evidence confidence

Present five claims: observed, derived, reported, suspected and unverified. Translate them so a second reader assigns the same confidence level. Expected evidence: a short bilingual result, the raw records used, a list of preserved identifiers, a table of any calculations and one clearly documented uncertainty. Pass standard: a reviewer who sees only the translated result can independently perform the correct next action. Record false positives and missed hazards separately so the next training session addresses actual decision errors rather than only grammar.

Workshop 15: Approve a production runbook

Give a firing alert, a silenced notification and a resolved alert. Require distinct action paths and verified escalation language in each locale. Expected evidence: a short bilingual result, the raw records used, a list of preserved identifiers, a table of any calculations and one clearly documented uncertainty. Pass standard: a reviewer who sees only the translated result can independently perform the correct next action. Record false positives and missed hazards separately so the next training session addresses actual decision errors rather than only grammar.

Workshop 16: Audit the entire incident packet

Combine all previous fixtures into a 12-minute simulated incident. Compare decisions across languages before reviewing individual term choices. Expected evidence: a short bilingual result, the raw records used, a list of preserved identifiers, a table of any calculations and one clearly documented uncertainty. Pass standard: a reviewer who sees only the translated result can independently perform the correct next action. Record false positives and missed hazards separately so the next training session addresses actual decision errors rather than only grammar.

22. Evaluating translation output and technical safety

A useful quality rubric distinguishes critical, major, minor and stylistic errors. A critical error changes an action, security decision, identity, numerical quantity or confirmed causal claim. A major error creates serious ambiguity about a metric, incident timeline, subsystem or alert. A minor error affects readability but does not alter the operator’s decision. A stylistic issue is a presentation preference that may still matter for consistency. This is a proposed internal rubric, not a quotation of any particular ISO scoring table. Set severity by foreseeable operational consequence, not by how awkward a phrase looks.

Use a bilingual reference set of frozen data with known expected outcomes. Each fixture needs a source record, exact technical fields, approved target wording, a query or display test, an expected action, and privacy classification. Reviewers should be blind to each other’s decisions for at least part of the test; otherwise consensus can conceal shared misunderstanding. Measure false escalations, missed incidents, incorrect service attribution, wrong unit interpretation, secret disclosures and broken query joins. A language release should fail when any critical contract regression appears, regardless of its average linguistic score.

The release report should say what the system has actually verified. ‘The translated label was reviewed’ is weaker than ‘the translated label, corresponding query, unit display and incident action were all tested against fixture A17’. Do not promise coverage of all real incidents based on a finite fixture set. Describe limitations, language-specific exceptions, known untranslated assets and the procedure for reporting a misleading technical label.

23. Thirty questions readers ask

1. Can I translate OpenTelemetry attribute keys?

Usually translate the explanation or UI label instead. Changing a key read by instrumentation, queries or downstream tools is a technical schema change that needs engineering review and migration. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

2. What is the difference between a trace and a span?

A trace represents related execution across operations; spans represent individual operations with context and timing. A translation should not call every span the entire trace. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

3. Should service.name values be translated?

Preserve service identifiers where they function as values in queries or resource metadata; show a localised friendly description separately. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

4. Can dashboard chart titles be translated?

Yes, when they accurately describe the actual query, units, aggregation and window; test titles against a frozen dataset. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

5. Is a log error the same as an HTTP 500?

Not necessarily. A log event, response status, exception and span status are different evidence types and may disagree in scope. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

6. Are trace IDs personal information?

They are correlation identifiers; privacy risk depends on how they are used and linked. Treat shared diagnostics with appropriate access controls and avoid exposing secrets. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

7. Can I translate a stack trace?

Translate explanatory prose around the stack trace, not paths, source names, function names or exact line information required for debugging. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

8. Why does case sensitivity matter?

Distinct attribute key spelling can denote distinct fields. Changing case in a source or filter can cause queries to stop matching. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

9. What do delta and cumulative mean?

They describe how a metric aggregates values over time. Labeling one as the other can mislead totals, rates and alert thresholds. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

10. How should seconds be displayed?

Use a locale-appropriate word or abbreviation while preserving the measured unit; if converting to milliseconds, convert the numbers explicitly. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

11. Do I localise metric instrument names?

Human descriptions can be localised. Instrument identifiers used by collectors, dashboards or queries should remain stable unless migrated deliberately. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

12. What does a missing trace prove?

It proves only that the stated query did not return a trace under those conditions. Sampling, permissions, retention or loss may explain absence. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

13. Can I translate event names?

Not as a casual prose edit when event names are machine-identifying values. Provide a translated description while keeping the event token. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

14. How are log time fields different?

The event timestamp records when an event occurred; an observed timestamp can record when a system observed it. Both may be operationally significant. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

15. What is SeverityText?

It is a textual severity field in the OpenTelemetry log model, distinct from the numerical severity and from an organisation’s separate incident priority. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

16. Should alert labels be stronger in another language?

No. Their urgency and action should match the actual state and approved policy, without exaggerating or weakening evidence. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

17. What is a semantic convention?

A shared naming and meaning contract for telemetry. It helps producers and readers interpret the same signals consistently. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

18. Why mention OpenTelemetry version changes?

Convention status and names may evolve. The target description should be tested against the version and instrumentation actually producing the record. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

19. Can the interface use a friendly service name?

Yes, if the friendly name is clearly separate from the canonical identity and links or filters still resolve the correct service. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

20. What about right-to-left languages?

Test isolation of opaque IDs, technical expressions, comparison operators and numeric units so that display order does not corrupt copyable values. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

21. Do translation memories pose risk?

They can if raw incidents contain sensitive fields. Use minimised or synthetic fixtures, retention controls and appropriate permissions. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

22. Are all logs complete evidence?

No. Collection, sampling, filters, retention, clocks and access rights limit what a particular view shows. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

23. Can a translator assign the root cause?

Not from language alone. A verified technical owner must establish causation from evidence; translation should preserve the confidence level. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

24. How do I test a translated chart?

Use exactly the same frozen data in source and target views, then compare query, numeric results, units, thresholds and decisions. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

25. How do I evaluate translation quality?

Review meaning, terminology, evidence fidelity, safety, accessibility and action correctness, not only grammar and fluency. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

26. What is the role of a termbase?

It stores preferred words, definitions, forbidden confusions, examples, reviewer ownership and version history for consistent decisions. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

27. Can machine translation help?

It may draft prose for controlled review, but it must not receive unapproved sensitive records or directly alter telemetry contracts. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

28. Do translated labels need release notes?

Yes when readers depend on them for incident response. Version labels, document tested coverage and retain rollback capability. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

29. How can I prevent wrong actions?

Rehearse realistic frozen incidents in each target language and compare the operational decisions before release. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

30. What should I read next?

Use the translation root for general meaning transfer, the vocabulary hub for learning terminology and How English Works for English-specific grammar and interpretation. When doubt remains, return to the exact field and the question the reader must answer; a correct target sentence is one that preserves the same defensible decision, not merely the same surface words.

24. Specialist glossary: terms to keep distinct

Trace: A correlated set of operations, normally represented through span relationships.
Span: A timed operation with context, attributes, events, links and status.
Trace ID: Opaque identity for a trace; preserve for exact correlation.
Span ID: Opaque identity for a span; not interchangeable with a trace ID.
Parent span: The operation context to which a child span is related by parentage.
Span link: A relationship to another span context that is distinct from parentage.
Span kind: A role such as client or server in a traced operation.
Attribute: A typed key-value fact attached to telemetry.
Semantic convention: A standard naming and meaning contract for telemetry.
Resource: Description of the entity emitting telemetry.
Instrumentation scope: Identity of the instrumentation component emitting data.
Metric: A series of measurements under a specified instrument and model.
Counter: A measurement instrument associated with nondecreasing accumulation in its intended semantics.
UpDownCounter: A quantity that may increase and decrease.
Gauge: A representation of a sampled value at a point in time.
Histogram: A distribution of measurements represented by counts, boundaries or other aggregates.
Delta temporality: A stream describing values accumulated in successive intervals.
Cumulative temporality: A stream describing accumulation from a start time.
Unit: A representation of the measurement dimension and scale.
UCUM: A system for coding units of measure consistently.
Cardinality: The number of distinct series or values generated by labels and dimensions.
Timestamp: A record of when an event occurred.
ObservedTimestamp: A time at which a system observed a log event.
SeverityText: The textual severity description in a log record.
SeverityNumber: The numerical severity in a log record.
EventName: The name used to identify a class of event.
Log Body: The message or payload of a log record.
Baggage: Context propagated across process boundaries; requires privacy care.
Status: An explicit signal about a span’s execution result within its model.
Sampling: A selection process determining which observations are retained or exported.
Schema URL: An identifier for a telemetry schema associated with data.
Collector: A component used to receive, process and export telemetry.
Exporter: A component that sends telemetry to another receiver.
Translation memory: Stored bilingual segments for reuse and consistency.
Termbase: Approved technical terminology with context and governance.
Golden fixture: A fixed evidence dataset with known expected interpretation.
Backward compatibility: Continued function of consumers after supported changes.
Runbook: Operational instructions to diagnose or remediate a condition.
Alert pending: A pre-firing rule evaluation state in systems that define one.
Alert firing: An alert state indicating a rule’s firing conditions are satisfied.
False escalation: A mistaken urgent response caused by bad evidence or language.

25. A four-week implementation programme

Week 1 — inventory and invariants

Select the top ten incident-producing services and five most-used dashboards. Extract representative sanitised telemetry and identify all displayed tokens that are really schema or query values. Record stable identifiers, units, locale strings, test owners, access boundaries and the first bilingual terminology decisions. Deliver a frozen evidence set and a coverage register rather than a polished translation.

The week ends with a written decision: proceed, proceed with stated limitations, or return to a specific blocked gate. Every approved record should identify the source fixture, affected language, responsible owner and reproducible test. This creates a small but durable evidence system that survives staff turnover and future software upgrades.

Week 2 — translation and semantic review

Translate only the approved human-facing surfaces. Review with a domain engineer, translator and incident owner. Test trace links, log time semantics, aggregate dashboards, severity labels, no-data messages, plural forms and threshold operators. Reject fluent but misleading drafts. Deliver a reviewed language pack together with deviations and known gaps.

Week 3 — simulations and accessibility

Run source and target dashboards over the same fixtures. Conduct two incident handovers, one release-migration drill, one privacy review and a screen-reader/right-to-left test where relevant. Compare actions and errors rather than relying on subjective preference. Deliver an issue log, repaired terms and verified outcomes.

Week 4 — controlled release

Deploy language assets independently of instrumentation changes. Track broken filters, user misunderstanding, incorrect escalation and unresolved fallback. Provide release notes specifying coverage, spec versions, examples, contact points and rollback. Schedule review after semantic-convention or product changes; do not treat localisation as finished forever.

26. Authoritative sources and date-sensitive reference points

The references below were checked as current public sources on 1 November 2026. Version and stability labels can change. Treat the current version of each official document and your deployed instrumentation as the controlling engineering sources, and treat this guide as a translation and review methodology rather than a replacement specification.

27. Next routes: the translation root and protected learning systems

For general principles of moving meaning across languages, continue to Master Art of Translation | The Complete System for Moving Meaning Between Languages. This page is the specialised OpenTelemetry and multilingual observability child identified as EDKSG-TRANS-MASTER-WORLD-1030. The root owns general translation theory; this chapter owns the instrument-and-incident evidence interface. It does not replace or rewrite any existing translation article.

When building a personal bilingual terminology learning plan, consult the protected Vocabulary Learning Hub, which retains ownership of vocabulary acquisition and memory. For the grammar, English phrasing and interpretative distinction between what a statement says and what it implies, consult the protected How English Works | Translation and Meaning Across Languages. Both are supporting routes, not content to duplicate or edit.

Final operational rule: readers may speak different languages and still deserve the same evidence. A translation succeeds when the copied ID still resolves, the quantity still measures the same thing, the timestamp still points to the same event, the uncertainty remains visible and two teams make the same justified decision. Make the human explanation clearer; keep the telemetry truthful.