OpenMetrics HELP translation QA is the practical process of rewriting the human explanation attached to a metric family while keeping the metric name, type, unit, labels and sample values stable. The immediate answer is to translate documentation for operators in a separate presentation layer whenever possible, and to change a HELP line in an exposition only when the exporting system and all readers explicitly expect that language. A translated tooltip is not permission to rename a telemetry series.
A monitoring team may want a French-language dashboard, a Tamil-language incident runbook or a bilingual classroom experiment. In each case, the difficult part is not finding a translation for a word such as “requests.” It is distinguishing the sentence that tells a human what a measurement means from the identifier that tells computers which measurement they are reading. Those objects travel together on screen, but they have different duties inside the system.
The safest fast workflow is therefore inspect, freeze, translate, parse, compare and observe. Capture the unmodified exposition and the dashboard configuration, write a small inventory of human-facing prose and structural identifiers, translate only eligible text, parse both variants, compare the frozen measurements, and have an operator explain the translated result without looking at the original. This article shows the precise boundary and an auditable path through mistakes that otherwise look harmless.
The reader’s job: a translated explanation, the same time series
Imagine a school laboratory exposing the number of successful worksheet submissions, a queue’s pending jobs and the time needed to grade an exercise. An English technician reads a dashboard label saying “Number of submissions accepted by the marking service.” A Chinese-speaking tutor wants a Chinese explanation while a backend aggregation rule still selects the same time series. The translation is successful only when both readers can interpret the same measurement, alerts keep working and a raw metric inspection shows no changed identity or arithmetic.
A measurement has several layers. The exposed name establishes what a family is called. The type tells a reader whether a number is a gauge, counter, summary or other declared metric kind. A unit expresses whether the quantity is measured in seconds, bytes or something else; the name and UNIT metadata must remain consistent under the OpenMetrics conventions. Label keys divide an observation into identifiable dimensions. Label values may themselves be identifiers, including tenant names or service routes. HELP is the separate human description. Conflating those layers can destroy historical comparability even when the chart still renders.
The phrase “quickly” must describe a reliable procedure rather than a shortcut around tests. A fast translator who changes submissions_total to soumissions_total may feel that the user experience has become coherent, yet a PromQL query written against the first name will now return a different or absent series. The error is operational: dashboards may silently display empty panels, recording rules may stop matching and alerts may lose coverage. Speed is valuable only if the measurement contract survives.
Understand the OpenMetrics text boundary before editing
OpenMetrics 1.0 specifies a UTF-8 text exposition with metric-family metadata and sample lines. The meaningful metadata markers include # TYPE, # HELP and # UNIT, and a valid text exposition ends with # EOF. These are protocol tokens, not prose in the ordinary sense. The text’s line endings, escaping and family grouping matter to parsers. An editor should never translate the marker words, convert the file to UTF-16 or introduce a decorative paragraph into the middle of a protocol record.
HELP is human-oriented, but it is still embedded inside a machine-readable record. A literal newline inside a HELP description must be encoded using the permitted escaping rather than inserted as another physical line of output. A backslash needs the applicable escape handling; a double quote has its own rule. The exporter owns those bytes. Translating a sentence in a dashboard localization file is usually less risky than changing the exporter, because exporters often feed many independent monitoring consumers which do not share a language preference.
The OpenMetrics unit convention is especially easy to misunderstand. A family named lesson_review_duration_seconds can declare the unit seconds; a translator must not replace the machine-readable unit token with a local word for seconds, or rewrite the family as a localized sentence. The unit is a standardized description of the measurement’s dimension. A localized display may show “s,” a full word, or a language-sensitive explanation, but the numerical meaning and source value remain unchanged. In a translated screen, preserve the distinction between a unit string in telemetry and how that unit is described to a person.
An additional subtlety concerns a counter’s text representation. A counter family can have a base name and produce samples with suffixes such as _total or _created. Histograms and summaries have their own suffix conventions for buckets, counts and sums. Those suffixes are not translatable vocabulary; they are parts of the agreed series encoding. When a localization script blindly substitutes a phrase across a file, it may alter request_duration_seconds_count and mislead a metrics parser long before a translator realizes that two meanings of “count” were present.
Decide which text belongs in the translation queue
Build a translatability inventory at three levels: the exporter, the monitoring presentation and the accompanying training material. In the exporter, HELP metadata can be human text, but its selection should be deliberate, coordinated with downstream consumers and limited to prose. In the presentation layer, panel titles, legends, annotations, dashboard instructions and alert runbook explanations are commonly intended for human readers. In training documents, examples and commentary can be rewritten freely as long as sample identifiers are shown faithfully and quotations are clearly differentiated from invented examples.
Not every label value should be translated. Consider environment="production", region="ap-southeast-1" and queue="submission-v2". These are keys into operational systems, not words chosen for display. The fact that a value spells an English word does not make it natural language content. Replace a label value only if the whole system treats that dimension as a deliberately localized value and the change has been designed as a schema migration, not as a translation. Most translation tasks should leave these untouched and attach a human description elsewhere.
There can also be free-text labels, but they require caution for a second reason: label-cardinality. If a label is populated from unrestricted translated messages, every translated wording may create a new label value, increasing the number of time series and memory demands. A HELP string is a different category of information precisely because it does not create a separate series for each human sentence. When an exporter exposes dynamic error messages as labels, the engineering defect is not repaired by translating more carefully; the metric design should use stable categories and place detailed diagnostics in logs or traces.
A compact translation inventory can have columns for source path, field role, frozen value, eligible display text, target locale, reviewer and fixture. This is an offline working record, not a proposal to alter production immediately. The reviewer must be able to answer why a text field was included and why nearby identifiers were excluded. That explanation matters especially when language services are supplied with a raw monitoring response and may assume everything visible is translatable.
A small valid exposition to inspect and compare
The following deliberately small OpenMetrics 1.0 text example is a teaching fixture. Its metric family is a gauge representing pending worksheet marking jobs, with one dimension naming a queue. The French translation changes only the HELP description; it does not change family metadata types, series labels, numeric values or the EOF terminator. Because the displayed language might be chosen per dashboard rather than per scrape target, this example demonstrates a controlled exporter-side edit, not a universal recommendation to serve different languages from the same scraping endpoint.
# TYPE lesson_marking_pending_jobs gauge
# HELP lesson_marking_pending_jobs Number of worksheet jobs waiting for marking.
lesson_marking_pending_jobs{queue="primary-6"} 7
# EOFA candidate translated variant retains the same operational identity. The word “jobs” is translated inside the HELP value only. The line still begins with the literal protocol marker, its metric name is byte-identical and the sample remains seven pending jobs for the same queue. A verification script can parse both into a structural representation, discard only the HELP value, and compare everything else; a second check must confirm the translated sentence expresses the same quantity, queue state and scope.
# TYPE lesson_marking_pending_jobs gauge
# HELP lesson_marking_pending_jobs Nombre de travaux en attente de correction.
lesson_marking_pending_jobs{queue="primary-6"} 7
# EOFDo not pretend that this example proves compatibility with every scraper, metric type or dashboard. It proves a narrow set of invariants which can be checked by inspection and a parser. The candidate’s French text could still be improved by a subject expert if “worksheet jobs” must be distinguished from learner assignments. A useful QA report records both facts: the protocol structure passed, and the terminology still needs a human decision.
Preserve measurement semantics, not merely the vocabulary
The phrase “pending jobs” describes a queue snapshot. It is not the same as jobs received since startup, jobs completed during the last minute, or jobs currently running. Those differences correspond to gauge and counter behavior, sampling and operational state. A translator should ask whether a number can rise and fall, whether a counter is cumulative, whether a rate is calculated at query time and what an end user is expected to do after reading the panel. Without those answers, two polished translations may convey opposite operational conclusions.
Suppose a monitoring panel shows “Total retries” but the query actually computes a rate over five minutes. A direct translation of the English label would faithfully preserve a mistake. The repair is to reconcile the original label with the query and then produce a new human description, such as “Retry events per second, averaged over five minutes.” The machine-readable metric should not be altered as a side effect of correcting dashboard language. The quality check must include the formula or query that gives the display its meaning.
Histograms are another frequent source of false fluency. A histogram bucket count with a bound labeled le="0.5" does not mean half a job or fifty percent of the population. It is a cumulative count of observations at or below a bound, according to the instrumented unit. The translated help must preserve that statistical structure. A phrase such as “jobs taking half a second” may wrongly imply that every observation lasted exactly that long; “jobs with duration at most half a second” is closer to the intended distinction.
A summary quantile needs its own explanation and should not be confused with a histogram bucket or an average. The words “95th percentile” describe a threshold in an empirical distribution, not a guarantee that a service will meet that time for all requests. The translator must retain units, windowing assumptions and the distinction between measured observations and service commitments. This is why the reviewer should see a graph and a query, not only a solitary string extracted for translation.
Design an operator-facing localization architecture
If several language groups share one monitoring deployment, use stable telemetry upstream and locale-specific explanations downstream. A dashboard can map each metric family to an explanation key such as monitoring.lesson_marking_pending_jobs.help, and the language bundle can supply translated text. The key is for the localization system; it is not a replacement for the metric name. In this arrangement, the scraper receives one invariant telemetry stream while the browser displays whichever explanation a reader selects.
The mapping needs ownership. If a metric is renamed by developers, the localization key may become stale even though its translated sentence remains grammatical. Generate an inventory from exported metric metadata or from a reviewed metrics catalogue, then compare its keys with the localization dictionary during a build. Flag obsolete entries and unexpected new metrics. A stale translation should not be silently assigned to a new metric that happens to reuse a similar word. Where uncertainty persists, prefer a fallback to the canonical English HELP with a visible language limitation over a confidently wrong localized definition.
Separate server, client and stored alert behavior. A dashboard tooltip may be localized at page rendering time, but an alert title sent through a webhook may be generated by a different system. Alert routing identifiers, severities and labels should remain structural. Localize the message or runbook description in the notification layer with explicit locale selection and with a default when an individual responder’s preferences are unavailable. A notification created for one language should not cause the stored alert rule itself to be duplicated into one series per language.
The architecture also needs a source-of-truth decision. If metric help text is corrected in the exporter while dashboard translations are maintained separately, a drift may emerge. Decide whether the telemetry description or a documentation catalogue is the authoritative semantic definition, assign a revision or owner, and require translation updates when it changes materially. A translator should not have to infer whether “active sessions” now excludes anonymous visitors from a panel title that has remained unchanged for years.
Failure mode: translated names create new time series
A global find-and-replace can transform lesson_marking_pending_jobs into travaux_correction_en_attente, which appears attractive to a French-speaking reviewer. The damage is not cosmetic. Scrape ingestion stores a distinct name; dashboards select the older one and may show no result. Historical queries now traverse a discontinuity and recording rules may need explicit migrations. The first diagnostic is to diff the exposed family and label names, then inspect query results before and after the change using the same time range.
The repair is to restore the original metric identity, migrate only intentional schema changes through engineering review, and keep translations in human-facing HELP or UI text. If a production rename has already happened, document the time boundary and consult the team responsible for alerting and long-term storage. A translation worker should not invent recording rules or assume that rewriting a label instantly reconciles historic data. Treat the incident as a telemetry contract regression requiring operational ownership.
Failure mode: escape characters split one HELP into many records
A translator may insert a literal line break to make a tooltip easier to scan. In ordinary prose that is reasonable; inside a protocol line it changes the shape of the file. A parser can treat the second physical line as an invalid sample or terminate processing. A backslash in a translated technical term can also be mishandled. The diagnostic is a byte-level diff and a parse test of the entire exposition rather than a visual review in a rich-text editor.
The repair is to serialize the description using the allowed escaped representation and to use a normal text renderer for multiline layout after parsing. Avoid hand-editing raw exposition with word processors because they may introduce smart punctuation, nonstandard line endings or byte order marks. Keep a golden fixture whose exact bytes are known, including the required # EOF, and test it under the actual exporter and collector versions that will use the format.
Failure mode: a translated unit changes the number’s meaning
A label such as “Latency in seconds” may be made more readable with a locale-specific word, but the numeric series still measures seconds. An operator could misread a translated abbreviation as milliseconds or minutes if the display uses a locally familiar convention. A display conversion is a separate numerical transformation. If a chart intentionally shows milliseconds, multiply the underlying seconds in the query or presentation layer, set the axis unit accordingly and ensure the human caption says milliseconds. Merely changing a suffix is not a conversion.
Test values that expose the difference. A value of 0.250 seconds should display as a quarter of a second, or as 250 milliseconds after an explicit conversion. A translation review should include the original quantity, formula, displayed unit and resulting number. If these four disagree, the problem is not linguistics alone. Correct the chart logic and then translate the fixed description, preserving the metric family’s canonical measurement unit.
Failure mode: histogram thresholds are mistaken for outcomes
A bucket keyed by a bound can be deceptively easy to paraphrase. If a histogram reports a bucket for durations of at most one second, a translator who writes “exactly one-second requests” has moved from a cumulative bound to a point measurement. The sentence may pass grammar review but mislead a service operator about tail latency. Compare the description with two consecutive bucket values and explain why the larger bound usually includes observations counted by the smaller bound.
The repair is to specify “at or below,” include the measurement unit and distinguish histogram samples from derived percentiles. In a learner exercise, show a small set of durations and ask students to count how many fit each bound. If a label cannot survive that arithmetic test, it does not accurately describe the series. This technique turns a translation dispute into an observable test rather than an argument about which sentence sounds more natural.
Failure mode: language-specific labels explode cardinality
A development team might decide that a status_message label should carry localized sentences. For the same operational event, labels now contain English, Japanese and French phrases. Each distinct label value defines another possible time series; new deployments, punctuation changes and message parameters produce even more combinations. Memory and query costs can rise, while aggregations by the original stable status category become difficult. Translating this field more consistently is not the long-term cure.
Use a stable machine status such as state="waiting", and provide a mapping to translated display text outside the metric label set. If a panel needs detail about a particular failure, link to structured logs or traces rather than insert an unpredictable sentence into a time-series dimension. Verify the repair by sampling label cardinalities before and after, checking query selectors and ensuring that the UI can still explain the states in every supported language.
Failure mode: a fallback lies about the supported locale
A bilingual dashboard may load an English tooltip when a preferred translation is unavailable. Falling back is acceptable when explicitly controlled; it becomes misleading if the interface silently claims every label is translated or assigns the wrong explanation to a metric. Some technical terms have intentionally borrowed spellings, so a word looking English does not prove that fallback occurred. The reviewer needs source keys, locale identifiers, coverage records and examples of deliberate untranslated terms.
The repair is a deterministic fallback chain and a missing-translation report. When a locale variant is absent, display a verified canonical explanation and keep the metric identity constant. Do not substitute a nearby translated metric description because it shares a word such as “jobs” or “errors.” Audit the fallback at least once with artificial gaps inserted into the catalog, and verify that no language-specific string selection can influence alert thresholds or series queries.
Failure mode: a fluent sentence disguises an incorrect query
Some panels are already mislabeled before localization. A heading says “Failed uploads” but the query counts retries; an operator interprets rising values as new failures rather than attempts. The translator should not silently accept the display label as the complete specification. Inspect the query, underlying metric HELP, dashboard annotations and at least one real data slice. These independent views can reveal a pre-existing mismatch that would otherwise be duplicated into every language.
When a mismatch is found, record the discrepancy as a source-content defect. Have the metric or dashboard owner decide whether the query or the label is wrong. Only after that decision should the target-language explanation be finalized. The translation audit must distinguish errors introduced by localization from earlier semantic defects. Otherwise an error report may unfairly attribute a source-system problem to the translator while leaving the monitoring dashboard technically unsafe.
Failure mode: exporter-level translation makes scrapes nondeterministic
A tempting shortcut is to vary the raw metrics endpoint according to the browser’s Accept-Language header. Monitoring scrapers and tools do not necessarily send the same headers as browsers, and cache layers may handle the variants differently. A background collector may receive a translated HELP string one day and another language the next. Even where sample names remain invariant, the endpoint has acquired unnecessary presentation behavior and a harder testing surface.
Prefer one stable exposition and localize at the consumer’s user interface. If a system genuinely needs localized HELP in the exporter, define its behavior explicitly and test every consumer, including command-line scrapes and federation. The acceptance criterion is not just that the HTTP request returns data. It is that data selection, type, unit, sample values and parse behavior remain consistent across request contexts, with clear ownership of any text differences.
Build a mechanical comparison that a reviewer can repeat
Start with a snapshot of the exposed text from a test environment and a list of the specific HELP entries approved for translation. Parse the exposition according to its declared OpenMetrics text version. Represent each family as its name, declared type, unit, parsed help and samples. For each sample, retain its name, label keys and values, numeric value, timestamp if present, and exemplar data if present. Those fields define the frozen contract for this translation exercise.
Next, create a candidate exposition and parse it independently. Compare the original and translated representations after removing exactly the approved HELP text fields from the comparison. Any other difference is a block. This includes missing samples, reordered or modified labels if an ordering requirement exists in a consuming system, or malformed escapes. Some parsers normalize record order; a team should decide whether byte-for-byte comparisons are needed in addition to semantic comparisons. Both have useful roles but answer different questions.
The semantic language check cannot be replaced by parsing. Have the reviewer answer four questions in the target language: What quantity is measured? What event or population is counted? What units and aggregation are applied? What operational action, if any, follows from a change in the number? Compare those answers with the measurement owner’s explanation. If the four answers agree, the translation has a much stronger basis than a simple bilingual word list.
A small set of adversarial fixtures makes the workflow reusable. Include an escaped newline, a help line containing quotation marks, a Unicode phrase, a counter with suffixes, a histogram bound, a label whose value looks like natural language, and a translation that is longer than the available tooltip space. A separate malformed fixture can ensure the parser actually rejects defects rather than accepting all text as success. Record which fixture was rejected and why; a test suite that only sees green results gives little assurance that it can detect failure.
Separate grammatical review from incident-response review
A linguist may prefer a polished sentence while an operator needs a phrase matching a familiar incident procedure. These perspectives are complementary, not interchangeable. Ask the linguist to check clarity, ambiguity, register and locale-specific grammar. Ask the operator to check whether the sentence describes the true service state and invites the correct next step. Both should inspect a screenshot or rendered notification, because “pending” may be understood differently in a queue, payment transaction or school assignment workflow.
Create a glossary of measurement concepts, not just translated words. A useful entry for “backlog” defines whether it represents waiting work, delayed work or total unprocessed work; another for “throughput” defines events per unit time and the denominator used. When a word appears in three panels with slightly different meanings, forcing one translation everywhere is worse than documenting the distinction. The glossary should contain disambiguating examples and link to the measurement owner rather than impose a blanket substitution rule.
A third reviewer can perform a recovery drill: show the target-language dashboard without the source-language tooltip, ask what would trigger investigation and then compare that interpretation with the alert’s actual condition. This drill measures the consequence of the translation, not just the quality of its prose. It is especially important where a monitoring system supports safety, privacy, financial processing or school assessment workflows. The reviewer may correctly ask for a clearer original English description, too.
A changed-context transfer exercise
A transport-monitoring service exposes bus_stop_arrivals_delay_seconds as a gauge with HELP “Delay between scheduled and observed arrival time, in seconds.” A school dashboard shows the value in a Chinese-language panel. A junior editor proposes renaming the metric to Chinese characters and changing seconds to a translated unit. At the same time, the dashboard query converts seconds into minutes and the displayed title simply says “Delay.” Decide which fields may be translated, what numerical conversion is required and how to test a negative value.
The question deliberately changes the original classroom marking context to transport operations. The stable engineering answer still begins with an invariant metric name and unit in the exposition. A translated title and HELP explanation in the presentation layer can say the value is a signed difference between observed and scheduled arrival, while the display conversion divides the source seconds by sixty to show minutes. A negative value must be tested as an early arrival if that is how the source instrument defines subtraction; the team should confirm the sign convention with the service owner instead of guessing.
A useful acceptance fixture contains a positive delay, a zero difference and a negative difference. A value of 120 seconds can become two minutes after conversion, while -60 seconds can become negative one minute, and zero stays zero. The translation must explain the sign convention before declaring late or early status. A reviewer should compare query arithmetic, chart axis formatting and the source metric definition. Nothing in the localization effort should silently change service routing or alert criteria.
Review checklist for a handoff
- Confirm the canonical metric family names, type tokens, units and label schema are frozen.
- Inventory exactly which HELP strings or UI explanations may be translated.
- Preserve counter, histogram and summary suffix behavior.
- Parse the original and translated OpenMetrics exposition using the target version.
- Compare all non-HELP machine fields and sample identities.
- Check permitted UTF-8, escaping, line endings and final
# EOF. - Ask a technical reviewer to explain units, rates, bounds and state from the translated text.
- Exercise locale fallback, empty strings and long tooltip rendering.
- Inspect alert rules and dashboards for unintended query changes.
- Record the source definition, target locale, reviewer, fixture and approval evidence.
Limits of this method
This workflow does not prove that a monitoring system’s instrumentation is correct. A well-translated HELP line can faithfully describe a faulty gauge or a counter that resets unexpectedly. Parsing alone cannot validate whether the service’s real-world behavior matches its exported measurements. Nor does a valid OpenMetrics 1.0 fixture establish compatibility with every collector or with the evolving draft work for OpenMetrics 2.0. The test environment should name its parser and deployed versions, and operators should remain responsible for production observability.
There is also a security boundary. A raw metrics endpoint can expose sensitive labels and operational details; translation QA should use scrubbed fixtures and approved test access. Do not upload real tenant identifiers or incident payloads to a translation provider merely because HELP strings look harmless. The content inventory may need confidentiality handling before external review. Clear source control and a restricted sample corpus can protect both the organization and the translator.
Summary: translate the explanation and protect the instrument
OpenMetrics translation succeeds when a target-language reader can understand a measurement while the collector still sees the same metric family and samples. The translator’s task is not to remake the telemetry schema in another language. It is to preserve the unit, type, dimensions and arithmetic, then write a human explanation that is accurate enough for someone to make the right operational decision. That distinction turns a fragile text-editing exercise into a repeatable quality process.
A production handover example: who owns the translated phrase?
Consider a team with a central Prometheus deployment, one engineering dashboard and two localized on-call handbooks. A metric owner adds a new instrument for jobs that have been accepted but not yet started. The engineering dashboard initially calls this “queued jobs,” while a handbook translates the phrase as “unfinished jobs.” That latter wording covers both queued and running work, so it could lead an operator to diagnose worker capacity incorrectly. The semantic defect becomes visible only when a representative snapshot shows three queued jobs and five running jobs in different metrics. A reviewer who looks solely at the sentence cannot distinguish the two states.
The handoff should identify one authoritative metric definition, a named engineering owner and a translated explanation tied to that version. When the source definition changes from “accepted but not started” to “accepted or waiting for retry,” this is a material revision even if the short label remains “queued.” The translation catalog should flag all affected locales, and a reviewer should examine the changed population before approving a reused phrase. This avoids a particularly common failure: content management shows a green translation status because the same key exists, while the key’s business meaning has evolved.
Before release, run the handbook’s translated sentence through a specific decision question: if this number rises while the running-jobs gauge remains stable, which component should the engineer inspect first? The answer ought to direct attention toward admission, scheduling or backlog processing rather than imply that every unfinished job has failed. A screenshot, example values and the real alert threshold make the phrase testable. Save these alongside the approved localization bundle, so the next editor can recover the reasoning instead of copying a string without context.
A rollback should restore the prior display text without touching telemetry retention or creating new family names. If the release accidentally modified exporter HELP, restore the canonical exposition independently, then confirm scrape parsing and recorded series names. The incident report can acknowledge that a locale change reached an inappropriate layer without making a misleading claim about lost metrics. This separation of repair paths is a practical form of resilience: translation defects should be reversible without rebuilding the monitoring architecture.
Frequently asked questions
Can OpenMetrics HELP contain non-English text?
Yes. It is UTF-8 text, subject to its wire-format escaping and parser rules. In a shared production deployment, however, decide whether localization belongs in the exporter or in dashboards; the latter usually avoids language-dependent scrapes.
Should metric names be translated for non-English operators?
No, not as routine localization. Metric names are programmatic identities. Localize surrounding titles, documentation and tooltips while preserving selectors and recording rules.
Can a translated tooltip change the unit shown on the screen?
The tooltip may describe a display conversion, but the conversion itself must be implemented and tested numerically. Changing the wording alone does not convert seconds into milliseconds.
Are label values safe to translate when they look like English words?
Usually not. They commonly identify states, tenants, routes or environments and participate in time-series identity. Use a stable value and a separate display map.
Why is # EOF important?
It is the required end marker for an OpenMetrics 1.0 text exposition. The marker is a protocol token, not a phrase to translate or omit during editing.
How can a linguist review histogram descriptions?
Provide an example with observations, bucket bounds and the resulting cumulative counts. The reviewer can check phrases such as “at most” against actual arithmetic.
What if the source English HELP is wrong?
Raise a source-content issue and ask the measurement owner to correct the canonical definition or query. Do not reproduce the error merely to remain literally faithful.
Does a valid fixture prove every metrics server is compatible?
No. It proves only the checks performed on that fixture and parser. Deployment-specific collectors, caching, federation and dashboards need their own tests.
How should an untranslated locale be handled?
Use a deterministic, clearly documented fallback to verified language text, and report missing translations. Never substitute an unrelated metric’s explanation.
Can machine translation draft the HELP text?
It can suggest wording, but a technically competent reviewer must verify quantity, unit, scope, state and operational consequence before the target text is accepted.
Authoritative sources
- Prometheus: OpenMetrics 1.0 specification — published specification for metric families, metadata, escaping and text exposition.
- Prometheus: Exposition formats — supported formats and distinction between OpenMetrics 1.0 and draft 2.0.
- Prometheus: Metric and label naming — operational naming guidance for instrumented metrics.