Translate AI Model Cards, Metrics & Limits

50-second summary: A model card explains what an AI model is intended to do, which data and evaluations support it, and where it may fail. Translate the claims at their original scope. Keep benchmark names, dataset splits, subgroup numbers, licences, version identifiers and disallowed uses intact. Never turn a test score into a universal accuracy promise, a model limitation into a footnote, or an evaluation report into independent certification.

How should you translate an AI model card without turning a measured benchmark score into a sweeping promise about an artificial-intelligence system? Begin by preserving the model’s intended use, evaluation dataset, measurement conditions, limitations and version. This article explains AI model card translation, benchmark accuracy and F1 score localisation, training-data disclosures, subgroup results, bias warnings, model repository metadata and the precise wording of performance claims.

A typical AI model card contains natural language alongside technical identifiers, tables, code-like metadata and statements about risk. In one language a sentence says ‘accuracy on a curated test set’. A careless version says ‘accurate for all real-world users’. The number may remain unchanged while the claim becomes false. This happens when the translator drops the evidence boundary around the statistic or treats an intended-use statement as an actual safety authorisation.

Common questions include ‘how to translate model cards’, ‘what does benchmark accuracy mean’, ‘how to translate F1 score’, ‘what is the difference between intended and out-of-scope use’, ‘how to localise model README metadata’ and ‘how to preserve AI safety limitations in translation’. These searches have a common answer: preserve the connection among a claim, the data used to test it, and the intended conditions of deployment. Clear language should narrow uncertainty, not conceal it.

Imagine a fictional classifier tested on 800 labelled images from one region. Its model card reports 0.88 macro F1 for that test set and warns that performance on nighttime images was not measured. A fluent translation that calls it ‘88% accurate in all conditions’ has confused a different metric with an untested domain. The following method teaches readers to audit such mistakes through original, deliberately invented examples; none of the sample model scores belongs to a real released system.

The visible problem: confident AI prose can outrun the evidence

A model card is a compact interface between a technical team and many readers: developers, teachers, auditors, journalists, procurement staff, researchers and ordinary users. These groups do not ask the same questions. A developer wants an exact model identifier and usable deployment restrictions. A parent may ask whether a chatbot is appropriate for a child. A researcher wants the dataset, split and metric definition. Translation fails when it answers the reader’s imagined question instead of accurately reporting the source author’s claim.

The Hugging Face Hub documentation describes a model card as a README with structured metadata and human-readable material covering intended uses, limitations, training, datasets and evaluation. The NIST AI Risk Management Framework encourages context-aware examination of AI risks. Neither resource means that the mere presence of a well-written model card certifies a model as safe. The translator’s job is therefore evidence-preserving communication, not endorsement.

First principles: what a model card actually establishes

1. A model card describes claims, not guarantees

The card reports what an author or organisation says about a model and its evaluation. A high score is not a legal certification, a promise of safety or a replacement for deployment testing. Translate reported claims as reported claims. Preserve attribution, date and version, especially if the source itself uses tentative wording such as ‘preliminary’, ‘estimated’ or ‘internal evaluation’.

Ask the same three evidence questions here: who made the claim, under what data and conditions, and what remains unknown? Those boundaries belong in the target language even when a marketing-friendly sentence would be shorter. A strong translator can show the precise source wording and the exact reason a tempting paraphrase would extend the claim.

2. Model identity must survive localisation

Repository names, model IDs, checkpoints, commit hashes, version tags, architecture variants and provider names are not ordinary words to paraphrase. Keep exact strings and distinguish a base model from a fine-tuned derivative. If an explainer uses a translated nickname, retain the exact technical identifier alongside it so a reader can retrieve the intended artefact.

3. The metric has a definition

Accuracy, precision, recall, macro F1, micro F1, AUROC and loss are different measurements. Their mathematical definitions and relevant task assumptions matter. Translating one as ‘success rate’ can erase its denominators or its treatment of class imbalance. Keep the metric name and use a contextual explanation rather than inventing a more flattering umbrella term.

4. A test score has a population and split

Training, validation and test datasets play different roles. A result on a held-out test set is not necessarily a performance figure for future deployments, language communities or data collected with different equipment. Preserve test-set size, sampling criteria and data dates. Do not generalise a limited sample into the whole world.

5. Task and environment change meaning

Text classification, image recognition, transcription, ranking, generation and detection do not share a single definition of correctness. A translation should state what inputs the model was evaluated on and what output it produces. An in-domain evaluation cannot silently become an out-of-domain performance assurance. Deployment context is part of any meaningful performance claim.

6. Disaggregated results may reveal different outcomes

An overall average can mask subgroup or language performance. Translate the grouping definitions and sample sizes accurately and avoid replacing a low subgroup result with the global average. Uncertainty and small samples can limit interpretation, and the source may explicitly warn against comparing groups. Keep such limitations visible and near the figures.

7. Missing evaluation is not evidence of success

If a model card says that a group, language or harmful-use scenario was not tested, the correct rendering is ‘not evaluated’ rather than ‘no problem found’. Absence of evidence cannot be converted into evidence of safety. Distinguish an evaluation omission, an explicitly observed limitation and a documented mitigation measure.

8. Data sources need provenance and rights

The card may name training, fine-tuning and evaluation datasets, their licences and restrictions. Do not translate a dataset’s identifier into a different product or imply that a dataset is public because its name appears. Keep provenance, usage limitations and privacy statements as sourced assertions, not as a translator’s independent permission to reuse data.

9. Structured metadata is different from prose

A model card may contain YAML front matter, tags, language identifiers, pipeline labels and library names. These fields enable discovery and software behaviour. Translate human-facing descriptions but keep schema keys and standard identifiers unchanged unless an authorised localisation specification says otherwise. A fluent translation that breaks machine metadata is not correct.

10. Safety and out-of-scope statements are central

Terms such as ‘not for medical diagnosis’, ‘research use only’, ‘not evaluated for minors’ and ‘may produce offensive outputs’ define critical limits. Do not bury them after promotional examples, soften their modal force or transform an unsafe use into a supported use. Preserve distinctions among prohibited, unsupported and untested.

11. Metric uncertainty and sample size are part of the result

A single percentage can be misleading without denominator, confidence interval, variance, cross-validation design or error bars. Translate all of those if present. Do not add precision by multiplying decimals or suppress uncertainty ranges because the target sentence feels crowded. Statistics are bounded statements about how a measurement was obtained.

12. Model-card translation must be versioned

Models, evaluations, licences and policies change. Store the source URL, revision or commit identifier and the translation date. If a new card updates a risk warning, the old translation should not remain silently authoritative. A good release procedure can identify what changed without conflating a new model version with a newly translated document.

The repeatable eleven-step method for model-card localisation

Step 1: Identify the exact model revision

Record the publisher, repository ID, model checkpoint, release version and the date or commit hash of the card. Distinguish the card’s update from a change in the actual model weights. Without identity control, two localised cards can describe different systems under one friendly name.

The deliverable for this step is a checkable artefact: an identifier table, benchmark record, terminology decision, rendered preview or unresolved query. Each decision should be reversible by another reviewer using the cited source version. When the next stage cannot reproduce the evidence trail, improve the documentation before releasing the translated card.

Step 2: Map audiences and task

Write down intended readers, intended uses, out-of-scope uses, input and output types. A technical README and a public-facing summary may require different language registers, but they must not make different factual claims. Maintain a complete source record when producing both.

Step 3: Separate human descriptions and machine metadata

Mark YAML keys, tags, language codes, dataset identifiers, model IDs and code samples as structure. Translate prose values only when the hosting system permits them. Test that the translated README still parses and renders correctly; do not transform a data file into a prettier but broken document.

Step 4: Create an evidence table for metrics

For every score record metric name, result, scale, confidence or variation, evaluation set, split, sample size, date and measurement procedure where available. If a field is absent, write ‘not reported’ in the audit table rather than inventing a standard practice. This exposes scope errors before prose is drafted.

Step 5: Preserve technical comparisons

Check whether the source compares to a baseline, older version, human annotators or other models. Record what is held constant. ‘Improved by five points’ is not automatically ‘five percent more accurate’; percentage points and relative percent changes are different calculations.

Step 6: Translate limitations before sales copy

Draft known weaknesses, unsupported populations, languages, geographic limits and prohibited uses with particular care. A reader should encounter warnings in an equivalent place, with equivalent strength, in each language. Do not trade a clear negative for diplomatic vagueness.

Step 7: Validate terminology and statistical units

Confirm the field’s exact terms using authoritative documentation: accuracy, macro F1, hallucination, calibration, precision and recall. Retain standard abbreviations with a clear explanation where useful. Numbers, fractions and percentages must not be interchanged without explicitly showing a calculation.

Step 8: Read the card as a scientist and as a user

A technical reviewer verifies whether the result still means the same statistic. A reader reviewer asks whether the target text implies a different promise. Both views are necessary. A score can survive character-for-character while a nearby clause changes its scope drastically.

Step 9: Run rendering and metadata checks

Preview Markdown headings, tables, code blocks, links, YAML front matter, licences, badges and warnings. Ensure RTL or long target-language text does not obscure negative qualifiers or separate a warning from its table. Keep names and identifiers machine-readable.

Step 10: Check fairness statements without reinterpretation

Preserve the reported groups, data limitations, metrics, sample sizes and evaluators’ conclusions. Do not diagnose bias or certify fairness beyond the source. Where a result is inconclusive, translate uncertainty as uncertainty. Route policy decisions to the organisation responsible for deployment.

Step 11: Release with provenance and change tracking

Publish the translation with source version, language and scope. Use a discrepancy log for ambiguous statements and a reviewer sign-off for technical facts. When the source changes, conduct a differential review that prioritises new use restrictions, metric definitions, datasets and risk information.

Twenty worked cases: source evidence, tempting paraphrase and correction

All models, scores, datasets, groups and identifiers in these worked cases are hypothetical. No example establishes the performance of a real model. Read each as a short debugging exercise in what a translated claim allows the reader to infer.

Worked case 1: Accuracy on a curated dataset

Invented source: Accuracy 92% on TestSet-A (n=500). Dangerous translation: 92% accurate for everyone. Defensible translation: 92% accuracy on the named 500-item test set.

A controlled test score does not establish universal performance on new domains, groups or real-world deployment. ‘Everyone’ changes a sample statistic into a general promise. Preserve the dataset and denominator whenever a reader could mistake the claim’s scope. Notice that translation quality cannot be judged only by whether the same numeral appears. A qualifier, task, model version or dataset name may be doing more work than the number itself. The reader should reach the same bounded conclusion from either language.

Evidence check: Check metric name, score, set, split, size and source version. A reviewer should be able to identify the exact source field and explain why the rejected wording says too much, too little or something technically different.

Transfer challenge: rewrite this item as a two-sentence public explainer that includes the measurement or disclosure and its limitation. Then shorten it to one sentence without losing a necessary qualifier. Compare both versions to the source. Good compression reduces words, not responsibility; it never converts an unmeasured domain into a verified outcome.

Worked case 2: Macro F1 recast as ordinary accuracy

Invented source: Macro F1 = 0.88. Dangerous translation: 88% correct predictions. Defensible translation: Macro F1 score of 0.88.

Macro F1 combines per-class precision and recall into an unweighted mean across classes. It is not equivalent to raw accuracy, especially with class imbalance. Translators should keep the metric’s name and, where space permits, explain its scope. Notice that translation quality cannot be judged only by whether the same numeral appears. A qualifier, task, model version or dataset name may be doing more work than the number itself. The reader should reach the same bounded conclusion from either language.

Evidence check: Compare target wording against the actual evaluation metric definition. A reviewer should be able to identify the exact source field and explain why the rejected wording says too much, too little or something technically different.

Worked case 3: Percentage points versus percent increase

Invented source: Accuracy rose from 80% to 85%. Dangerous translation: Accuracy improved by 5%. Defensible translation: Accuracy rose by 5 percentage points.

A shift from 80 to 85 is five percentage points but a 6.25% relative increase. Using ‘five percent’ without context can be quantitatively misleading. The translator should preserve the original kind of difference and avoid recomputing without attribution. Notice that translation quality cannot be judged only by whether the same numeral appears. A qualifier, task, model version or dataset name may be doing more work than the number itself. The reader should reach the same bounded conclusion from either language.

Evidence check: Write the two values and identify absolute versus relative change. A reviewer should be able to identify the exact source field and explain why the rejected wording says too much, too little or something technically different.

Worked case 4: Validation and test split

Invented source: Validation 1,000 records; test 400. Dangerous translation: All results use 1,400 independent test records. Defensible translation: Keep validation and test populations separate.

Validation may influence development decisions whereas a held-out test is used to assess the resulting system. Combining their counts makes a more impressive sounding evaluation but changes study design. Notice that translation quality cannot be judged only by whether the same numeral appears. A qualifier, task, model version or dataset name may be doing more work than the number itself. The reader should reach the same bounded conclusion from either language.

Evidence check: Create separate table rows for each split and its role. A reviewer should be able to identify the exact source field and explain why the rejected wording says too much, too little or something technically different.

Worked case 5: Unknown performance in another language

Invented source: Evaluated in English; Thai not evaluated. Dangerous translation: Supports Thai with comparable quality. Defensible translation: English evaluation reported; Thai evaluation not reported.

A system may technically accept a script while lacking evidence of useful quality. Translators must not convert language tags or input capability into measured performance claims. The missing test is central to the user’s decision. Notice that translation quality cannot be judged only by whether the same numeral appears. A qualifier, task, model version or dataset name may be doing more work than the number itself. The reader should reach the same bounded conclusion from either language.

Evidence check: Check the language list against the language of actual evaluation data. A reviewer should be able to identify the exact source field and explain why the rejected wording says too much, too little or something technically different.

Worked case 6: Subgroup averages conceal a gap

Invented source: Overall 90%; Group A 93%; Group B 76%. Dangerous translation: Reliable equally for all groups. Defensible translation: Report overall and both subgroup values.

An overall number does not remove a measured discrepancy. A translation that only keeps the headline average can conceal an important limitation. However, the numbers alone do not determine cause; avoid inventing a diagnosis or fairness judgement. Notice that translation quality cannot be judged only by whether the same numeral appears. A qualifier, task, model version or dataset name may be doing more work than the number itself. The reader should reach the same bounded conclusion from either language.

Evidence check: Preserve group definitions, sample sizes and source discussion. A reviewer should be able to identify the exact source field and explain why the rejected wording says too much, too little or something technically different.

Worked case 7: Small subgroup count

Invented source: Group C F1 0.65 based on n=12. Dangerous translation: Group C performance definitively 65%. Defensible translation: F1 0.65 on a 12-item group, with interpretive caution.

A small sample offers limited precision and can make a number unstable. The translation must preserve the denominator and any uncertainty note. It should not convert exploratory findings into a final fixed property of a population. Notice that translation quality cannot be judged only by whether the same numeral appears. A qualifier, task, model version or dataset name may be doing more work than the number itself. The reader should reach the same bounded conclusion from either language.

Evidence check: Mark the metric type and denominator on the same line. A reviewer should be able to identify the exact source field and explain why the rejected wording says too much, too little or something technically different.

Worked case 8: In-domain success versus out-of-domain risk

Invented source: Tested on daylight street scenes; nighttime untested. Dangerous translation: Works reliably day and night. Defensible translation: Only daylight scenes evaluated; nighttime performance not measured.

The source tests one environmental slice. Inferring another is a generalisation not warranted by the model card. The translation should help readers notice the boundary rather than requiring them to know the evaluation dataset. Notice that translation quality cannot be judged only by whether the same numeral appears. A qualifier, task, model version or dataset name may be doing more work than the number itself. The reader should reach the same bounded conclusion from either language.

Evidence check: Link the environment limit directly to the performance result. A reviewer should be able to identify the exact source field and explain why the rejected wording says too much, too little or something technically different.

Worked case 9: Label-definition drift

Invented source: Positive class: confirmed defects. Dangerous translation: Positive class: suspected defects. Defensible translation: Keep ‘confirmed defects’ as defined.

Changing the label definition changes what precision and recall actually measure. ‘Positive’ is not a self-explanatory real-world property. Translate the dataset’s annotation policy and avoid inserting a more intuitive but different class. Notice that translation quality cannot be judged only by whether the same numeral appears. A qualifier, task, model version or dataset name may be doing more work than the number itself. The reader should reach the same bounded conclusion from either language.

Evidence check: Review class definitions with annotation guidelines. A reviewer should be able to identify the exact source field and explain why the rejected wording says too much, too little or something technically different.

Worked case 10: Baseline model confusion

Invented source: A fine-tuned model improved over baseline B. Dangerous translation: The base model B achieved the new score. Defensible translation: Attribute the result to the fine-tuned version.

Model lineage and evaluation results belong to specific variants. Reassigning a score to the base weights may lead to selection of a model that was never tested at that level. Notice that translation quality cannot be judged only by whether the same numeral appears. A qualifier, task, model version or dataset name may be doing more work than the number itself. The reader should reach the same bounded conclusion from either language.

Evidence check: Compare checkpoint IDs and version tags near the results. A reviewer should be able to identify the exact source field and explain why the rejected wording says too much, too little or something technically different.

Worked case 11: Human review condition omitted

Invented source: Output requires professional review before use. Dangerous translation: Approved for unsupervised deployment. Defensible translation: Human review requirement remains explicit.

An operational safeguard can be part of the stated intended-use conditions. Deleting it to improve reading speed can make unsupported automation appear authorised. Translate the requirement at the same strength as the source. Notice that translation quality cannot be judged only by whether the same numeral appears. A qualifier, task, model version or dataset name may be doing more work than the number itself. The reader should reach the same bounded conclusion from either language.

Evidence check: Verify the modality of ‘must’, ‘should’, ‘may’ and ‘not’. A reviewer should be able to identify the exact source field and explain why the rejected wording says too much, too little or something technically different.

Worked case 12: Medical-use restriction softened

Invented source: Not intended for medical diagnosis. Dangerous translation: Useful for diagnosis when convenient. Defensible translation: Not intended for medical diagnosis.

An excluded high-stakes use cannot become a suggested possibility because the target language prefers a positive sentence. The model card gives limitations, not a medical regulator’s authorisation. Notice that translation quality cannot be judged only by whether the same numeral appears. A qualifier, task, model version or dataset name may be doing more work than the number itself. The reader should reach the same bounded conclusion from either language.

Evidence check: Compare every use restriction line by line before release. A reviewer should be able to identify the exact source field and explain why the rejected wording says too much, too little or something technically different.

Worked case 13: YAML schema field translated

Invented source: license: apache-2.0. Dangerous translation: licence: permissive-open. Defensible translation: Keep machine key and exact SPDX-style identifier if given.

Repository metadata can be parsed by tools. Translating its key or replacing a licence identifier with a broad English category could break discovery and erase legal specificity. Localise explanatory prose, not the structured identity. Notice that translation quality cannot be judged only by whether the same numeral appears. A qualifier, task, model version or dataset name may be doing more work than the number itself. The reader should reach the same bounded conclusion from either language.

Evidence check: Run a YAML parse and verify the known field identifiers. A reviewer should be able to identify the exact source field and explain why the rejected wording says too much, too little or something technically different.

Worked case 14: Dataset name mistaken for a description

Invented source: Training data: DATASET-47. Dangerous translation: Training data: dataset of 47 samples. Defensible translation: Retain DATASET-47 as the dataset ID.

Names may contain digits without denoting counts. Translators should not interpret proper identifiers as factual descriptions. A separate explanation may be added only if supported by the actual dataset documentation. Notice that translation quality cannot be judged only by whether the same numeral appears. A qualifier, task, model version or dataset name may be doing more work than the number itself. The reader should reach the same bounded conclusion from either language.

Evidence check: Cross-check published dataset identifier and version. A reviewer should be able to identify the exact source field and explain why the rejected wording says too much, too little or something technically different.

Worked case 15: Annotation disagreement concealed

Invented source: Inter-annotator agreement was limited. Dangerous translation: All annotations were verified. Defensible translation: State the reported limits of agreement.

Labels are not necessarily ground truth free of ambiguity. When the source reports disagreement, deleting it creates false certainty about evaluation and training data quality. Notice that translation quality cannot be judged only by whether the same numeral appears. A qualifier, task, model version or dataset name may be doing more work than the number itself. The reader should reach the same bounded conclusion from either language.

Evidence check: Keep annotator protocol and uncertainty note visible. A reviewer should be able to identify the exact source field and explain why the rejected wording says too much, too little or something technically different.

Worked case 16: Latency with percentile dropped

Invented source: p95 latency 240 ms under setup X. Dangerous translation: Average response time 240 ms everywhere. Defensible translation: 95th-percentile latency 240 ms in setup X.

A percentile is not an average, and hardware or batch settings influence latency. The translation should carry the percentile and environment, without pretending one measurement predicts all deployments. Notice that translation quality cannot be judged only by whether the same numeral appears. A qualifier, task, model version or dataset name may be doing more work than the number itself. The reader should reach the same bounded conclusion from either language.

Evidence check: Record percentile, unit, hardware and test conditions. A reviewer should be able to identify the exact source field and explain why the rejected wording says too much, too little or something technically different.

Worked case 17: Reported limitation versus observed failure

Invented source: May generate unsupported citations. Dangerous translation: Always fabricates references. Defensible translation: May generate unsupported citations.

Possibility, rate and universality are not synonyms. Avoid sensational amplification as much as unwarranted reassurance. The source notes a risk; the translator does not know its frequency unless measured. Notice that translation quality cannot be judged only by whether the same numeral appears. A qualifier, task, model version or dataset name may be doing more work than the number itself. The reader should reach the same bounded conclusion from either language.

Evidence check: Check modal force and any accompanying frequency statistics. A reviewer should be able to identify the exact source field and explain why the rejected wording says too much, too little or something technically different.

Worked case 18: Safety mitigation portrayed as elimination

Invented source: A content filter reduces certain outputs. Dangerous translation: All unsafe outputs are impossible. Defensible translation: Describe the filter and its limited reported effect.

A mitigation can reduce risk without proving that risk has vanished. Translation should preserve the author’s stated evidence for a control and the residual uncertainty. This matters for deployment governance. Notice that translation quality cannot be judged only by whether the same numeral appears. A qualifier, task, model version or dataset name may be doing more work than the number itself. The reader should reach the same bounded conclusion from either language.

Evidence check: Compare what was measured before and after the mitigation. A reviewer should be able to identify the exact source field and explain why the rejected wording says too much, too little or something technically different.

Worked case 19: Licence name made into permission

Invented source: License listed, restrictions apply. Dangerous translation: Free to use for every purpose. Defensible translation: Preserve exact licence and listed use conditions.

A repository licence, service terms and dataset rights may differ. The model card can inform users but does not authorise a translator to broaden redistribution or commercial-use permission. Notice that translation quality cannot be judged only by whether the same numeral appears. A qualifier, task, model version or dataset name may be doing more work than the number itself. The reader should reach the same bounded conclusion from either language.

Evidence check: Keep exact source licence link and review legal limits separately. A reviewer should be able to identify the exact source field and explain why the rejected wording says too much, too little or something technically different.

Worked case 20: Version change silently ignored

Invented source: Card revision 3 adds a new excluded use. Dangerous translation: Translated revision 2 still says unrestricted. Defensible translation: Update restriction with clear revision provenance.

A correct historical translation can become misleading after the underlying model card changes. Version tracking must trigger a targeted re-review, especially where the new content concerns an evaluated hazard or excluded application. Notice that translation quality cannot be judged only by whether the same numeral appears. A qualifier, task, model version or dataset name may be doing more work than the number itself. The reader should reach the same bounded conclusion from either language.

Evidence check: Record card date, model version and translation revision. A reviewer should be able to identify the exact source field and explain why the rejected wording says too much, too little or something technically different.

Failure modes and repair techniques

1. Marketing amplifies a narrow test

A claim of ‘on Benchmark A’ becomes ‘world-class across all tasks’. Keep the dataset and task boundary visible. Detect the error by comparing a structured evidence table rather than reading the target paragraph alone. Repair the exact missing qualifier, label or identifier; document whether the problem originated in translation, in the source card or in the reader’s interpretation. Escalate unsupported technical claims to the model owner.

2. A metric name is replaced with accuracy

Precision, macro F1 or recall is called accuracy because readers recognise it. Keep the exact metric and define it. Detect the error by comparing a structured evidence table rather than reading the target paragraph alone. Repair the exact missing qualifier, label or identifier; document whether the problem originated in translation, in the source card or in the reader’s interpretation. Escalate unsupported technical claims to the model owner.

3. A test split vanishes

Validation scores are presented as untouched independent test results. Preserve the declared split and evaluation design. Detect the error by comparing a structured evidence table rather than reading the target paragraph alone. Repair the exact missing qualifier, label or identifier; document whether the problem originated in translation, in the source card or in the reader’s interpretation. Escalate unsupported technical claims to the model owner.

4. Limits are moved out of view

A warning in the source heading becomes a buried appendix remark. Preserve prominence as well as literal meaning. Detect the error by comparing a structured evidence table rather than reading the target paragraph alone. Repair the exact missing qualifier, label or identifier; document whether the problem originated in translation, in the source card or in the reader’s interpretation. Escalate unsupported technical claims to the model owner.

5. The model variant changes

A result for a fine-tuned checkpoint is attributed to the base model. Map variant IDs and data lineage first. Detect the error by comparing a structured evidence table rather than reading the target paragraph alone. Repair the exact missing qualifier, label or identifier; document whether the problem originated in translation, in the source card or in the reader’s interpretation. Escalate unsupported technical claims to the model owner.

6. Data provenance is simplified into a promise

‘Curated from public web sources’ turns into ‘licensed for unrestricted reuse’. Licensing is not inferable from availability. Detect the error by comparing a structured evidence table rather than reading the target paragraph alone. Repair the exact missing qualifier, label or identifier; document whether the problem originated in translation, in the source card or in the reader’s interpretation. Escalate unsupported technical claims to the model owner.

7. An excluded use sounds like a recommendation

‘Not evaluated for safety-critical decisions’ becomes ‘suitable for safety use’. Preserve negation and scope. Detect the error by comparing a structured evidence table rather than reading the target paragraph alone. Repair the exact missing qualifier, label or identifier; document whether the problem originated in translation, in the source card or in the reader’s interpretation. Escalate unsupported technical claims to the model owner.

8. Percent and percentage points swap

A five-point absolute difference is written as a five-percent relative improvement. Show original values and proper arithmetic. Detect the error by comparing a structured evidence table rather than reading the target paragraph alone. Repair the exact missing qualifier, label or identifier; document whether the problem originated in translation, in the source card or in the reader’s interpretation. Escalate unsupported technical claims to the model owner.

9. Subgroup evidence disappears

A low score or small denominator is omitted for a cleaner headline. Keep disaggregated results and caveats. Detect the error by comparing a structured evidence table rather than reading the target paragraph alone. Repair the exact missing qualifier, label or identifier; document whether the problem originated in translation, in the source card or in the reader’s interpretation. Escalate unsupported technical claims to the model owner.

10. YAML is translated as copy

Structured keys and IDs are modified while ordinary prose is localised. Protect parseable metadata and test rendering. Detect the error by comparing a structured evidence table rather than reading the target paragraph alone. Repair the exact missing qualifier, label or identifier; document whether the problem originated in translation, in the source card or in the reader’s interpretation. Escalate unsupported technical claims to the model owner.

11. Research uncertainty is deleted

A preliminary, unreproduced evaluation is called proven. Retain authors’ degree of confidence and provenance. Detect the error by comparing a structured evidence table rather than reading the target paragraph alone. Repair the exact missing qualifier, label or identifier; document whether the problem originated in translation, in the source card or in the reader’s interpretation. Escalate unsupported technical claims to the model owner.

12. The source changes after release

A corrected model card adds a new limitation but a stale translated page remains. Track versions and review differences. Detect the error by comparing a structured evidence table rather than reading the target paragraph alone. Repair the exact missing qualifier, label or identifier; document whether the problem originated in translation, in the source card or in the reader’s interpretation. Escalate unsupported technical claims to the model owner.

Practice and transfer lab

Drill 1: A classifier reports 0.91 precision and no recall figure.

Expected reasoning: Do not call the result 91% accuracy. Preserve precision and mark recall not reported. Have a second reader identify which claims are observed, which are assumptions and which are still unknown. An effective answer remains useful without pretending that the model card contains more evidence than it does.

Drill 2: A system advertises a repository tag for Spanish but has no Spanish evaluation.

Expected reasoning: Distinguish supported input capability or metadata from actually tested Spanish-language quality. Have a second reader identify which claims are observed, which are assumptions and which are still unknown. An effective answer remains useful without pretending that the model card contains more evidence than it does.

Drill 3: A benchmark contains only clean photographs, while customers submit blurry images.

Expected reasoning: Keep the original clean-image results and state that blurry-image performance was not established by that evaluation. Have a second reader identify which claims are observed, which are assumptions and which are still unknown. An effective answer remains useful without pretending that the model card contains more evidence than it does.

Drill 4: One model revision is trained on new data and inherits the old model’s translated card.

Expected reasoning: Refresh the card and recheck evaluation, data, licensing, versions and risk statements against the revised source. Have a second reader identify which claims are observed, which are assumptions and which are still unknown. An effective answer remains useful without pretending that the model card contains more evidence than it does.

Drill 5: An F1 score is reported for a small class of fourteen items.

Expected reasoning: Preserve the metric, class and denominator and do not imply reliable population-wide performance. Have a second reader identify which claims are observed, which are assumptions and which are still unknown. An effective answer remains useful without pretending that the model card contains more evidence than it does.

Drill 6: The model card says an answer needs expert review.

Expected reasoning: Keep the review condition in the translated intended-use section; do not recast it as optional convenience. Have a second reader identify which claims are observed, which are assumptions and which are still unknown. An effective answer remains useful without pretending that the model card contains more evidence than it does.

Drill 7: YAML includes language: en and an English-only evaluation statement.

Expected reasoning: Keep the machine language tag and make the English-only evaluation condition explicit in prose. Have a second reader identify which claims are observed, which are assumptions and which are still unknown. An effective answer remains useful without pretending that the model card contains more evidence than it does.

Drill 8: A mitigation decreases harmful-response frequency in a specific test.

Expected reasoning: Do not write ‘eliminates harmful responses’. Preserve tested context, result and remaining uncertainty. Have a second reader identify which claims are observed, which are assumptions and which are still unknown. An effective answer remains useful without pretending that the model card contains more evidence than it does.

Frequently asked questions

Is a model card a certificate that an AI system is safe?

No. It is documentation of a model, its claims, evaluations, intended uses and limitations. Its quality varies, and deployment suitability requires context-specific assessment. Translation must not make the card sound like independent regulatory authorisation.

For production decisions, check the current model owner’s documentation, applicable terms and independent evaluations. Translation is a way of transmitting evidence across languages, not a substitute for governance, testing or professional judgement.

Should I translate accuracy, F1 and recall into the same general word?

No. These are distinct metrics with different definitions. Keep the metric name and add an explanation suitable for the reader. The number’s mathematical meaning must survive any simplification.

Can a benchmark figure be used as real-world reliability?

Not without relevant supporting evidence. Performance may change with population, input quality, task, time and deployment conditions. Preserve precisely what the benchmark evaluated and any stated limits.

What is a model card on Hugging Face?

It is usually the repository README with human-readable descriptions and metadata, including intended uses, training information, evaluation results and limitations. Translators should distinguish prose from YAML and other machine-readable fields.

What does ‘not evaluated’ mean?

It means the card does not provide a reported evaluation for that question. It is not the same as success, failure or a confirmed absence of risk. Do not convert nonmeasurement into a positive conclusion.

How should model licence identifiers be translated?

Preserve standard identifiers and their source links. A plain-language explanation may be added, but it cannot replace legal terms or infer rights absent from the governing licence and other applicable conditions.

What happens when subgroup results differ?

Report them as given, with definitions and sample sizes. Do not erase them in the average or diagnose causes without evidence. A target reader should be able to see which groups were evaluated and where uncertainty remains.

May I localise a README by replacing YAML keys?

Only if an authorised system explicitly supports that change. Ordinary YAML keys, model IDs and code snippets often need to remain parseable. Test the resulting card in the actual hosting environment.

Are model-card warnings always legally binding restrictions?

Not necessarily; their status depends on the source, licence, applicable terms and context. Translate the precise force of the warning and refer legal questions to the proper source rather than assigning extra authority.

Can an LLM automatically translate another model’s card?

It can generate an initial draft, but automated translation may smooth away limitations, rename metrics or alter numeric details. A human technical reviewer should compare the source, particularly consequential claims and structured data.

What source version should be cited?

Use the exact repository revision or document version when available, along with the translation date. Distinguish changes to documentation from updates to model weights or evaluation results.

How do we know the translation is accurate?

Another person can reconstruct exactly the model identity, task, dataset, metric, reported result, scope, risks and intended uses from either language. Discrepancies and unanswered questions remain visible rather than silently corrected.

Release checklist for a bilingual model card

Check that source repository and revision match the translation. Compare metric values, denominators, data splits, class definitions and environment constraints. Verify warnings about excluded users, medical or financial use, bias, privacy and harmful outputs. Check Markdown tables, YAML parsing, links, identifiers and licence names. Have a technical reviewer inspect numerical meaning and a language reviewer inspect natural clarity. Finally, make the translation’s date and scope visible. A properly reviewed card should make uncertainty easier to understand, not harder to find.

The deeper lesson is a transferable reading skill: a statistic describes evidence within a method and context. Change the method or erase the context, and you may change what the sentence responsibly claims. Students can practise the same discipline in science reporting, mathematics word problems, media literacy and reading comprehension. Language accuracy is a form of evidence accuracy.

Primary sources and contextual next routes

Next route: choose the Vocabulary Learning Hub when a metric term is unclear, How English Works when a qualifier modifies the wrong claim, and the original model owner’s current documentation when the reader needs to know whether the model is suitable for a real task. The translator should help the reader see the evidence and its limits together.

Top Ways to Translate Correctly | Translate AI Model Cards, Benchmark Metrics and Dataset Limits Without Inflating Performance