A model asked in French about the same country you asked about in English will write Allemagne, and this is not a translation error to be patched out. It is the correct French name. The engineering question is not how to stop it, but where in your system a country is a name at all rather than a code.
One country, many correct names
The country whose ISO 3166-1 alpha-2 code is DE is written differently in every language that has a word for it:
DE English Germany
German Deutschland (endonym)
French Allemagne
Spanish Alemania
Polish Niemcy
Finnish Saksa
Swedish Tyskland
Russian Германия
Japanese ドイツ (from Deutsch, via Dutch)
Chinese 德国
Every one of these is right in its language. Deutschland is the endonym — the name used by the people who live there — and the rest are exonyms, names used by outsiders. The Polish and Finnish forms are not corruptions of the German: they derive from entirely different historical roots, one from a Slavic word for people who did not speak the local language, one from the name of a Germanic tribe. There was never a single original that the others diverged from.
The same applies everywhere. Hungary is Magyarország in Hungarian, Greece is Elláda in Greek, Japan is Nihon in Japanese, Egypt is Miṣr in Arabic, China is Zhōngguó in Chinese, and Finland is Suomi in Finnish. A model producing the locale-appropriate form is doing its job. A model producing Deutschland inside otherwise-French output is the actual bug.
Why exonyms exist and do not go away
They exist because the names are old, arrived through intermediary languages, and were adapted to each borrowing language’s sound system. Doitsu in Japanese reached Japanese via Dutch. English Japan reached English via Malay and Portuguese from a southern Chinese pronunciation. These are historical accidents that then became load-bearing: the exonym is what the speakers of that language actually say, and a name nobody uses is not more correct for being closer to the endonym.
The reference data for this is maintained rather than guessed. The Unicode Common Locale Data Repository publishes territory display names for every ISO 3166 region code in every locale it covers, along with short forms and variant forms, and it is what the internationalisation libraries in every major language runtime read from. If you need Germany’s name in Thai, you look it up; you do not ask a model and you do not translate the English string.
Where localising the name is the bug
The rule is that a country name is localisable when it is prose and must not be when it is an identifier. Four cases where localising causes a real failure:
- Postal addresses. The destination country on an international shipment should be written so that the origin country’s postal service can route it, conventionally in the language of the sending country and repeated in English. What must not happen is the interior of the address — street, city, region — being translated: those lines are read by carriers in the destination country and must arrive in their own language. Covered further on address formats by country.
- Legal and financial documents. Contracts, invoices and customs declarations that name a jurisdiction should use the form the governing document uses, not a rendering chosen by locale.
- Database values and API payloads. A country field should hold
DE, not a name in any language. Storing display names makes joins locale-dependent and turns a change of UI language into a data-integrity incident. - Organisation and place names containing a country name. “Bank of China” is a proper name, not a phrase to be recomposed from parts. The same reasoning governs personal names, which is why names are transliterated rather than translated.
Names that changed, and names that are contested
A separate category, and the one where getting it wrong has consequences beyond a rendering glitch. Some countries have formally requested a specific name in international use, and the request is not a matter of translation preference.
- Türkiye. The country requested in 2022 that this form be used in place of “Turkey” in all languages; the United Nations member state list records the current official forms and is the reference to check.
- Côte d’Ivoire has asked since the 1980s that its name not be translated, which is why “Ivory Coast” appears in casual English and not in diplomatic usage.
- Czechia was registered as the short form alongside the Czech Republic in 2016, and both remain in use.
- Contested and politically loaded cases — the naming of territories with disputed status — are ones where a model will produce whichever form dominated its training data, and where your product needs an explicit editorial policy rather than a default.
Official names change, and models carry the naming conventions of their training data. Where a name matters legally or diplomatically, resolve it from a maintained list at request time rather than relying on generated text.
The pattern that makes both cases work
One rule handles nearly all of it: store the code, render the name. Keep DE in the database, in the API, in the event log and in the analytics event. Resolve it to a display string at the last possible moment, from CLDR data, using the viewer’s locale.
For model output specifically, the corollary is to give the model the locale rather than the name. A system prompt that establishes the output language will produce locale-appropriate country names for free, because that is what the training data looks like. Where a name must be exact — a legal entity, a contested territory, a customs form — supply the required string in the prompt and instruct the model to use it verbatim, rather than hoping the default matches your policy.
And when a name comes back from a model in a form you did not expect, check whether it is wrong before treating it as wrong. Most of the time the variation is the correct behaviour of a system that understood which language it was writing in.
Top comments (0)