Evidence checked October 31, 2026. This is an analysis of dated primary research and an original evaluation framework, not a new ranking of current models. All numerical illustrations and service scenarios are hypothetical. Language varieties are treated as legitimate linguistic systems, not deficiencies.
A list of languages does not describe a service
A product announces support for many languages. The list is impressive, but the practical question remains: support for what? A model may identify a language, produce a greeting, translate a short sentence, summarize a document, or answer a complex question. These are different capabilities. A language appearing in a menu does not establish that all of them work reliably for its speakers.
The original XTREME benchmark, introduced in March 2020, examined cross-lingual generalization across multiple tasks and languages. Its design made clear that multilingual performance is a matrix rather than one ability. The historical benchmark's scope should not be mistaken for a current certification of any commercial model. XTREME paper.
For a public-service application, the distinction can determine whether people actually receive equal access. A system might answer routine questions fluently in one language but fail to preserve a deadline, a negation, or a required document in another. The interface can look inclusive while the operational result remains uneven. Measuring that gap requires more than checking whether the output uses the expected script.
A useful evaluation begins with the service's tasks and the language communities it intends to serve. It asks which varieties, registers, and input conditions are represented, how examples were created, and how correctness was judged. A broad average can be reported, but it should remain connected to those details. Otherwise, the number can conceal the very users for whom the system is least reliable.
The matrix has more than two dimensions
Language and task are only the beginning. Performance can also vary with domain, text length, register, script, spelling convention, and whether the input mixes languages. A model may handle formal news text while struggling with a short informal message. It may translate general prose while mishandling specialized terminology. The evaluation should reflect the combinations relevant to the intended use.
Consider a hypothetical municipal information assistant. Its users may submit polished written questions, fragments copied from forms, messages containing local place names, or mixed-language descriptions. A test consisting entirely of translated English frequently asked questions would cover only a portion of that workload. The missing portion may contain the cases most likely to need human assistance.
The article proposes an evaluation map that lists tasks, language varieties, domains, and input conditions. Not every cell must contain a large dataset immediately. Empty cells should be visible as unevaluated rather than silently absorbed into a general support claim. This helps prioritize additional data collection and prevents the absence of evidence from becoming an assumption of success.
The map should also distinguish input and output language. A user may ask in one language and request an answer in another. A system may need to read a document in one language while explaining it in a local variety. These cross-language workflows can fail differently from same-language question answering.
The purpose is not to create an impossibly large testing burden. It is to identify which combinations matter and sample them deliberately. A modest, well-described evaluation can support a narrower deployment more responsibly than a large generic benchmark used to imply competence in every linguistic situation.
An average can improve while a community loses
A multilingual score often combines results across languages. The aggregation rule matters. A micro-average weights individual examples, so languages with more test items can dominate. A macro-average gives each language equal weight, but it can obscure different sample sizes and uncertainty. Neither is inherently wrong; each answers a different question.
Take a hypothetical test with nine hundred examples in Language A and one hundred in Language B. If a model answers ninety percent correctly in A and fifty percent in B, the pooled accuracy is eighty-six percent: 810 plus 50 correct answers out of one thousand. The equal-language average is seventy percent. Both calculations are correct, but they tell different stories about the service.
Now suppose an update improves A to ninety-five percent while reducing B to forty percent. The pooled score rises to 89.5 percent, while B's users receive worse performance. A headline improvement can therefore coexist with a meaningful regression for a smaller group. The report needs per-language results and change estimates, not only the combined number.
The same issue appears within languages. A dominant standardized variety may have many more examples than regional or community varieties. An average can improve while a less represented variety deteriorates. The relevant grouping depends on the service and should be designed with linguistic expertise and community input where appropriate.
The article recommends publishing both aggregate and disaggregated results with sample counts and uncertainty. Small groups should not be presented with false precision. If privacy or sample size prevents a detailed breakdown, state that limitation and plan additional evaluation rather than letting the overall score imply evidence that does not exist.
Low resource is a property of the research environment
Calling a language low resource generally describes the availability of suitable digital data, tools, or annotations for a particular computational task. It does not mean the language is simple, less expressive, or spoken by people with less knowledge. The label can also vary by task: a language may have substantial written material but limited annotated data for a specialized application.
A hypothetical language has many online news articles but little conversational data from the region where a service will operate. It may be relatively well supplied for news classification and poorly supplied for informal question answering. A single resource label would hide that distinction. The evaluation should identify which resources are missing and why they matter.
Data volume is also an imperfect measure of representativeness. A large corpus from a few publishers may cover a narrow register. A smaller community-curated dataset may better represent local names or grammatical patterns relevant to the task. Both quantity and composition matter, and neither should be inferred from the language's population size alone.
The practical implication is to avoid treating transfer from a well-represented language as a complete substitute for local evidence. Transfer can be valuable, but its success should be measured on the target task and variety. A model's general multilingual architecture does not guarantee that it has learned the distinctions needed in a particular setting.
The article's proposed resource description includes source types, time period, geographic coverage where known, annotation expertise, and task relevance. This gives readers a concrete account of the evidence rather than an abstract hierarchy of languages. It also identifies useful investments: better annotation, more varied sources, or targeted evaluation may matter more than simply collecting a larger undifferentiated text pile.
Translation can change the test
Artetxe and colleagues' EMNLP 2020 paper shows that translation can introduce artifacts affecting cross-lingual transfer evaluation. Its findings concern specific experimental conditions, but they establish an important methodological warning: a translated test is not automatically equivalent to naturally authored material in the target language. Translation-artifacts paper.
A hypothetical English inference question may rely on a pronoun ambiguity that disappears in translation. Another may contain a wordplay or cultural assumption that cannot be preserved directly. A translator can make a reasonable choice while changing the difficulty or even the correct answer. If the evaluation assumes perfect equivalence, the model may be rewarded or penalized for a different task.
Translation direction matters too. Text originally written in the target language can differ from text translated into it. Translated material may preserve source-language structure or use vocabulary uncommon in ordinary local communication. A model that performs well on this style may not perform equally well on natural user inputs.
The article recommends recording the origin language and translation process for every relevant evaluation subset. Human translation should include review appropriate to the task, not merely a general fluency check. For tasks involving paired sentences, context may need to be preserved so that translation does not independently alter relationships between them.
A strong evaluation can include both parallel translated items and locally authored items. The parallel set supports controlled comparison across languages; the local set checks realism and cultural fit. Differences between them are informative. They should be investigated rather than averaged away as noise, because they may reveal that the benchmark measures translation style as much as the intended capability.
Human translation is evidence, not automatic perfection
The No Language Left Behind paper, introduced in July 2022, describes a large multilingual translation effort and the human-translated FLORES-200 benchmark, alongside human evaluation and safety-related assessment. Its scope is machine translation, not every possible multilingual assistant task. The benchmark's breadth is valuable, but a translation score should not be repurposed as a general competence certificate. NLLB paper.
Human translators bring expertise that automated translation may lack, but evaluation still requires a process. Translators need context, clear instructions, appropriate familiarity with the language variety, and a way to flag ambiguous items. Reviewers should be able to correct an item or mark it unsuitable rather than force a misleading equivalent.
A hypothetical term has different common translations in two regions. Choosing one may be entirely valid, but an exact-match scoring rule could reject the other. The evaluation should identify acceptable variants where the task permits them. If the task requires a particular official term, that requirement should be stated and justified rather than assumed to represent the only correct language use.
Translation quality and annotation quality should be examined separately. A sentence can be well translated while its answer label is wrong. A correct label can accompany awkward wording that changes how a model responds. Sampling review should cover both the text and the task's logic.
The article proposes preserving translator notes and adjudication decisions in an appropriate audit record. Public release may require removing personal information, but the reasoning behind difficult cases should not vanish. These records help future users understand why an item was written a certain way and whether it remains suitable for a new model or application.
Community-built data changes what gets measured
MasakhaNER, published in 2021, presents named-entity-recognition data for ten African languages through a collaborative effort involving language stakeholders. It addresses a concrete task and a documented coverage gap. It should not be treated as a complete evaluation of all African languages or all language technologies. MasakhaNER paper.
The project illustrates why participation matters to measurement. People familiar with a language and its contexts can identify names, conventions, and ambiguities that outsiders may miss. They can also question whether a proposed task reflects useful local applications rather than simply translating an established English benchmark.
A hypothetical entity-recognition dataset may need to distinguish personal names, organizations, places, and dates in text where capitalization or word boundaries behave differently from English. Copying an English annotation guideline without adaptation can create inconsistent labels. The model's errors may then partly reflect the dataset's assumptions rather than an inability to understand the language.
Community participation should involve meaningful decisions, not only unpaid correction of a finished design. The article recommends involving appropriate contributors in task selection, annotation guidance, review, and interpretation. Their work should be credited and compensated according to the project's arrangements. These are practical design recommendations, not a claim that any one participation model solves every representational issue.
The resulting dataset still needs technical scrutiny. Collaborative creation does not remove sampling bias, annotation disagreement, or distribution shift. Its strength is that the process can surface questions a distant evaluation team might not know to ask. Good measurement combines that knowledge with clear protocols, quality checks, and transparent limits on what the dataset represents.
Dialect is a test condition, not an error to normalize away
Hofmann and colleagues' March 2024 preprint studies dialect prejudice in language models using African American English and hypothetical decision tasks. It reports harmful differences in the evaluated models' judgments. The study does not establish that every current model behaves identically or that every real-world decision has been affected, but it shows why language variety can matter beyond simple comprehension accuracy. Dialect-prejudice study.
An evaluation should therefore avoid treating a standardized variety as the only legitimate input. Automatically rewriting a user's language before testing may conceal the very behavior the service needs to handle. It can also change tone, meaning, identity cues, or pragmatic context. Normalization may be useful for some tasks, but its effects should be measured rather than assumed harmless.
A hypothetical assistant receives two semantically matched messages in different varieties. It may understand both yet respond more dismissively to one, offer less useful detail, or make unsupported assumptions about the speaker. A correctness score alone could miss that difference. The rubric should include relevant interaction quality and unjustified inferences where the application warrants it.
Matched examples require linguistic care. A mechanical substitution of a few words does not necessarily create a natural or equivalent dialectal utterance. Qualified reviewers should assess meaning, register, and authenticity. The goal is to test the system's response to legitimate variation, not to construct caricatures.
The article recommends reporting the specific varieties and tasks tested, with caution about generalization. A language label can contain many communities and registers. Evidence about one should inform further investigation without being stretched into a claim about all speakers or all contexts.
Tokenization can create an unequal input budget
Petrov and colleagues' 2023 tokenizer study examines differences in encoding length across languages and discusses consequences for cost, latency, and context capacity. The reported disparities depend on the tested tokenizers and language pairs. They should not be repeated as a universal multiplier for every current model. Tokenizer study.
The evaluation implication is straightforward. A fixed token limit can accommodate different amounts of meaningful content in different languages. If one version of a document is truncated earlier, the model is not receiving equivalent evidence. A lower score may partly reflect the input budget rather than only the model's linguistic ability.
A hypothetical multilingual summarization test gives every language the same maximum token count. In one language, the full document fits. In another, the final section containing an important exception is omitted. Scoring both against a complete-document reference creates an unequal task. The report should record actual retained content and truncation, not merely the configured limit.
Output limits can create similar effects. An answer may require more tokens in one language to express comparable content. A strict shared limit can cut off required details. Equal numerical budgets are not automatically equal communicative opportunities.
The article proposes two complementary evaluations: one under the actual product constraints, because users experience those constraints, and one designed to provide comparable content access, because researchers may want to isolate linguistic performance. The difference between them is informative. It reveals whether the service's configuration contributes to the gap and whether changing the budget improves outcomes without changing the model.
Code-switching is ordinary communication
People often combine languages within a conversation, sentence, or document. The mixture can include local names, technical terms, quotations, and borrowed expressions. A system evaluated only on clean monolingual text may not be prepared for these inputs. Treating every mixed-language message as malformed can exclude ordinary users from the service's assumed norm.
A hypothetical appointment request uses one language for the main sentence, another for a service name, and a local convention for the date. The model must preserve the relevant meaning without translating a proper name incorrectly or misreading the date. A language-identification component that forces the entire message into one category may introduce errors before the main model responds.
The test set should include realistic mixtures derived from authorized examples or constructed with knowledgeable speakers. Randomly inserting foreign words is not enough. Natural code-switching follows social and linguistic patterns, and an unrealistic synthetic mixture can test a different phenomenon.
Scoring needs care as well. A correct response may appropriately preserve a term rather than translate it. An exact-match reference that insists on one language throughout can penalize a useful answer. The rubric should state which content must be translated, which should remain unchanged, and which variations are acceptable.
The article recommends recording both the input mixture and the requested output behavior. Some users want a response in one language; others prefer the same mixed register. The system should follow the task rather than infer that multilingual input licenses arbitrary switching. Evaluating these choices makes the service more responsive to actual communication without turning every language boundary into a rigid rule that users never asked for.
Local knowledge is different from language fluency
A model can write fluent sentences in a language while lacking the local information needed to answer a question correctly. Conversely, it can know a relevant fact but express it awkwardly. These are different failure modes, and a multilingual evaluation should separate them where possible.
Consider a hypothetical public-service question about an office's opening hours. A fluent answer with the wrong hours is not successful language support. A correct answer copied from a verified source but phrased imperfectly may be more useful, although clarity still matters. The evaluation should identify whether the task requires external knowledge, language understanding, or both.
A controlled test can supply the same authoritative information in each language and ask the model to use it. Another test can examine retrieval from local sources. The first helps isolate comprehension and response generation; the second tests the full information workflow. Comparing them can reveal whether a gap arises from the model or from missing search coverage and source availability.
Cultural assumptions also matter. A question translated from another setting may presume institutions, measurements, or everyday practices unfamiliar to the target community. Adapting it can improve realism but reduce direct comparability. The report should document that trade-off rather than claim that a literal translation is automatically fairer.
The article's proposed rubric separates factual grounding, task completion, linguistic quality, and local appropriateness. A single overall score can be included for convenience, but the components should remain available. This prevents fluency from masking factual failure and prevents a language-quality judgment from becoming an unsupported judgment about the user's culture or the model's general intelligence.
Annotation disagreement can reveal the task's ambiguity
When qualified reviewers disagree, the disagreement may reflect an unclear rubric, multiple valid answers, regional variation, or genuine ambiguity in the input. It should not automatically be treated as reviewer error. A multilingual dataset can become less representative if adjudication always favors one variety or one narrow interpretation without recording the choice.
A hypothetical question asks for a polite refusal. Several responses may be appropriate depending on register and relationship. A scoring guide that accepts only one phrasing can make the task artificially brittle. For a factual extraction task, by contrast, disagreement may indicate an unclear entity boundary or a missing annotation rule. The response should fit the type of task.
The evaluation process should collect reasons for disagreement and revise guidelines where necessary. Some items may need multiple accepted answers or a graded rubric. Others may be unsuitable and should be removed with an explanation. The number of excluded items belongs in the report because exclusions can change the test distribution.
Reviewer expertise should be documented at a useful level without exposing personal information unnecessarily. Fluency alone may not be enough for specialized terminology or regional usage. A reviewer familiar with formal written language may not represent every conversational variety. The project should match expertise to the task rather than assume one person can certify all uses of a language.
The article recommends measuring agreement but not treating a high agreement score as the sole quality target. Reviewers can agree on a flawed rule. The more important question is whether the annotation process captures the intended meaning and supports valid conclusions about the service. Agreement is evidence about consistency, not a complete guarantee of correctness or fairness.
Cross-lingual transfer needs a stated training condition
A model can be evaluated after training on examples in the target language, after training only in another language, or after receiving a few target-language demonstrations at test time. These are different transfer conditions. Comparing them without labels can make a model appear more capable or less capable than the experiment actually shows.
XTREME-R, introduced in April 2021, expands and refines multilingual evaluation with more challenging tasks and broader language coverage than the original benchmark. Its emphasis on nuanced evaluation is a useful historical reminder that benchmark design evolves as models improve. A score on an older, easier suite does not automatically answer the questions posed by a later one. XTREME-R paper.
A hypothetical service might use English training examples and rely on transfer to several other languages. If local annotations are later added, the improved result should be described as a different training condition. That improvement can be valuable, but it should not be credited entirely to zero-shot generalization.
Prompt language also matters. Asking a task in English about a target-language passage differs from giving the whole instruction in the target language. The model may understand the passage but mishandle the instruction, or vice versa. Evaluating both can reveal which component needs improvement.
The article recommends a training-and-prompt matrix alongside results. It should identify supervised languages, demonstration languages, instruction language, input language, and output language where relevant. This may seem detailed, but it prevents a common ambiguity: a multilingual score can otherwise combine several kinds of assistance and exposure while being presented as one seamless capability.
Error categories should connect to user consequences
A useful evaluation records what went wrong, not only whether an answer matched a reference. In multilingual services, errors can include omitted negation, changed quantities, mistranslated names, wrong language, inappropriate register, unsupported factual additions, and failure to complete the requested action. Their consequences differ.
A hypothetical translation changes “not required” to “required.” Another renders a local place name awkwardly but recognizably. Both may count as one error under a simple metric, yet the first can materially change a user's decision. The rubric should identify critical information and evaluate its preservation explicitly.
Severity categories need justification and consistent review. They should not be chosen to make one model look better. Domain experts can identify which mistakes are consequential for the service, while language experts assess whether the meaning actually changed. In some settings, uncertainty or escalation is preferable to a confident but unsupported answer.
The article proposes reporting error rates by category and language, with examples appropriately anonymized or synthetic. This can reveal actionable patterns. A model may need better handling of dates, a retrieval system may need local sources, or a template may be forcing an unsuitable register. A single low score does not identify which change would help.
The evaluation should also measure successful refusal or escalation when the task cannot be answered reliably. However, a system that refuses nearly every request in a less represented language should not be celebrated as safe without acknowledging the loss of service. Useful support requires both avoiding harmful errors and completing legitimate tasks at an acceptable rate.
A representative test needs a sampling story
A dataset's origin determines what population its results can describe. Examples collected from formal publications, volunteer submissions, customer messages, and translated benchmarks represent different slices of language use. A report should explain the sampling process rather than treating the language label as a complete description of the data.
A hypothetical city assistant is tested on messages from digitally confident volunteers. The results may not represent people who use short fragments, unfamiliar spelling conventions, or assistive technology. The solution is not to assume those users will fail; it is to recognize the missing evidence and include appropriate cases in further evaluation.
Sampling should respect privacy and consent where required. Real service messages can contain sensitive information. Carefully de-identified or constructed examples may be preferable for public benchmarks, but their realism needs validation. The report should distinguish collected and constructed material so readers can understand the trade-off.
Time matters too. Vocabulary, institutions, and usage can change. A benchmark remains useful as a stable reference, but a deployment may need updated tasks and local terminology. The evaluation should identify the period represented and avoid implying that an old dataset measures every current condition.
The article's proposed sampling record includes source, recruitment or selection method, task distribution, variety coverage, exclusions, and review. It should also identify who is absent. That last field is particularly important: a transparent statement of missing coverage can guide responsible deployment, while an unqualified multilingual claim can make the same absence invisible to the people who rely on the service.
Uncertainty grows when a language has few test items
A score based on a small number of examples can vary substantially with the selected items. Reporting several decimal places does not make it precise. Multilingual evaluations often face uneven sample sizes, so uncertainty should be shown rather than concealed behind a uniform table format.
A hypothetical language subset contains twenty questions. One additional correct answer changes accuracy by five percentage points. A model that appears slightly better than another may simply have succeeded on one different item. The report should avoid treating small differences as a stable ranking without further evidence.
The appropriate statistical method depends on the task and sampling design. Related items may not be independent, and multiple languages may share translated source questions. A simple calculation that assumes every item is unrelated can understate uncertainty. Grouped or paired analysis may be more suitable when examples share structure.
The article recommends retaining item-level outcomes and using paired comparisons when models answer the same examples. It also recommends reporting the number of independent source items, not only the number of translated rows. A benchmark with many language versions of a small source set has a different evidence structure from a collection of independently authored tasks.
Uncertainty should inform decisions, not paralyze them. A small pilot can identify obvious failures and prioritize improvements. It simply cannot support the same broad confidence as a larger representative evaluation. A responsible report states what the sample establishes, what remains tentative, and which additional data would most improve the decision about deployment.
Test the whole service, including fallback
A multilingual assistant may combine language detection, translation, retrieval, generation, and interface templates. A strong underlying model can still produce a weak service if another component mishandles the language. Evaluating only the model in isolation misses these integration failures.
A hypothetical system translates every request into English, retrieves English documents, generates an answer, and translates it back. Each stage can introduce errors. The final answer may be fluent while a crucial qualification was lost early in the chain. An end-to-end test should preserve intermediate outputs for authorized analysis so that the failure can be located.
Fallback behavior deserves attention. If the system cannot handle a language, does it clearly say so, offer a useful alternative, or silently switch languages? Does a human handoff preserve the original message? Does the user have to repeat sensitive information? These outcomes affect actual access even when they are not part of a standard language benchmark.
The article recommends testing realistic user journeys, including incomplete inputs, clarification, correction, and escalation. A one-turn answer can look successful while a multi-turn exchange drifts into the wrong language or loses context. The service should maintain the user's requested language and relevant information across the interaction.
The final report should separate component and end-to-end results. Component tests explain mechanisms; whole-service tests establish what users experience. If a gap appears only in the full pipeline, the remedy may be integration rather than retraining. This distinction can save resources and prevent a language community from being blamed for a failure caused by the system's design.
Improvement needs a local comparison, not a universal ranking
A model update can improve some languages and tasks while worsening others. The evaluation should compare the versions on a stable set and a relevant fresh set, preserving the conditions needed to interpret change. A global leaderboard movement is not enough to establish that a particular community's service improved.
A hypothetical update raises average translation quality but increases failures on local place names. The organization may need a targeted correction or a revised retrieval source rather than rejecting the entire update. Disaggregated error analysis makes that response possible. Without it, the team sees only a favorable overall number and misses the practical regression.
The article proposes a release gate based on the service's essential tasks and languages. The gate should specify acceptable performance and escalation behavior before results are known. It should also identify how uncertainty is handled when a subset is small. A requirement invented after testing is vulnerable to convenient interpretation.
Community feedback can complement the benchmark. Users may identify failures absent from the test set, and those reports can become reviewed regression cases. Feedback is not a random sample, so it should not be used alone to estimate prevalence. Its value is diagnostic and corrective.
A multilingual service becomes more credible when improvement is described concretely: which tasks, which varieties, which conditions, and which errors changed. That evidence is more useful than declaring a model universally better at language. It connects research progress to the actual work people need done and keeps smaller or less represented groups visible when aggregate numbers move.
Scripts and interface behavior can erase a correct answer
A language model's output reaches users through an interface, and that interface can introduce its own problems. Text direction, line wrapping, font support, copy-and-paste behavior, and mixed-script identifiers can affect whether a correct response remains usable. These issues should be tested separately from the model's linguistic accuracy.
A hypothetical answer includes a local-language explanation, a Latin-script reference code, and a date. The underlying text may be correct while its visual ordering makes the code difficult to read. A user copying it into a form may accidentally include hidden formatting or omit a character. An evaluation that inspects only plain text would miss the resulting task failure.
The article recommends testing representative outputs in the actual interface on the devices used by the intended audience. Include long names, punctuation, numbers, links, and mixed-direction text where relevant. The objective is not to impose one writing convention but to preserve the intended content reliably through display and interaction.
Accessibility tools add another layer. A screen reader's handling of language changes can affect pronunciation and comprehension, while input methods can shape the text users submit. These are integration conditions that should be examined with appropriate expertise rather than inferred from the model's benchmark score.
A service can report model-level success and interface-level failure separately, but the end-to-end acceptance criterion should reflect what the user can actually do. Fixing the display may be simpler than changing the model, yet it is no less important to the person trying to complete a task. Multilingual support is delivered by the whole system, including the apparently ordinary software that surrounds the generated words.
The meaningful claim is supported communication
The research reviewed here spans multilingual benchmarks, translation artifacts, community-built datasets, tokenization, and dialect prejudice. Together, it shows why language support cannot be reduced to a list of names or one average score. Different components of the service can create different gaps, and each requires evidence suited to the question.
A responsible claim identifies the tasks tested, the language varieties represented, the origin of the examples, the scoring process, and the conditions under which the service operates. It reports uncertainty and missing coverage. It distinguishes fluent output from factual correctness and successful task completion. It also gives users a workable path when the system cannot help reliably.
For organizations, the practical starting point is a language-task map and a representative pilot with qualified review. Preserve disaggregated results, inspect consequential errors, and test the complete workflow. Use broad benchmarks as context, not as a substitute for local evidence. Where the evidence is weak, narrow the claim or strengthen the evaluation before expanding the service.
For readers, the useful question after a multilingual announcement is simple: what can speakers actually accomplish, and what evidence shows that they can accomplish it? The answer may differ across languages, varieties, and tasks. Making those differences visible is not an argument against multilingual AI. It is how the technology's promise can be tested against the people it is supposed to serve.