How to Handle Names and Places Across Scripts and Languages

For production multilingual workflows, see our AI Translation service for the delivery path behind the guidance in this article.

Names are small pieces of text with outsized importance.

A mistranslated sentence may be inconvenient. A misspelled person or place can affect identity, search, legal records, navigation and trust. Names also behave differently from ordinary language because they may need preservation, transliteration, conventional translated forms or official localized names.

The safest workflow treats names as entities with authoritative data.

Do not decide name handling by translating the individual words inside the name.

Entity identity first

Before language:

• Which person/place is this?

Use stable ID.

Then attach:

• native name;
• target forms;
• aliases.

This avoids duplicate entities.

Personal names

Priority:

1. official spelling;
2. preferred spelling;
3. approved transliteration.

For legal documents, use identity record.

Do not infer spelling from pronunciation if authoritative source exists.

Name order

Cultures differ.

Examples:

• family name first;
• given name first.

Do not reorder blindly.

If database separates fields:

• given;
• family.

Display according to locale.

Middle names/patronymics

Some naming systems use:

• patronymic;
• multiple family names.

Do not force every name into US first-middle-last.

Internationalize forms/data models.

Diacritics

Preserve:

• accents;
• diacritics.

Removing them can change identity.

Use Unicode.

Transliteration

If target cannot read source script, transliterate.

Use specified scheme.

ICU provides transliteration systems, but official-person spellings override generic mapping.

Romanization

Into Latin script.

Useful for:

• passports;
• travel;
• search.

Multiple standards exist.

Names in Arabic script

Arabic script used by several languages.

Transliteration depends on:

• language;
• pronunciation.

Avoid generic Arabic-letter mapping for Persian/Urdu names without language context.

Cyrillic

Different languages use Cyrillic.

One mapping is not enough.

Ukrainian/Russian names can romanize differently.

Use country/authority rules.

Chinese names

Pinyin is common for Mandarin romanization.

But individuals may have:

• Hong Kong;
• Taiwanese;
• family-established spellings.

Respect person’s established form.

Japanese

Kanji can have multiple readings.

Do not romanize a person name from characters alone when reading is unknown.

Use authoritative metadata.

Place names

A place can have:

• local endonym;
• conventional exonym;
• official romanization.

Example conceptual categories:

• source local name;
• English conventional name.

Publication style decides.

Endonym

Name used locally.

Useful for:

• maps;
• cultural accuracy.

Exonym

Target-language conventional name differing from local.

Use when established and audience expects it.

Avoid inventing new translated place names.

UNGEGN

The United Nations Group of Experts on Geographical Names works on standardized geographical naming and provides romanization system resources.

For mapping/government work, authoritative geographic sources should guide spelling.

Political sensitivity

Some place names are disputed.

Translation systems should not silently choose political framing.

Organizations need a naming policy based on:

• legal;
• editorial;
• product context.

Historical names

Documents may refer to:

• historical city/state names.

Preserve time context.

Do not modernize automatically.

Addresses

Addresses contain both:

• translatable descriptors;
• proper names.

Postal delivery may require original/local script.

For international reference, bilingual address can be useful.

Do not translate street name unless a conventional form exists/required.

Search and aliases

Store:

• native;
• romanized;
• exonym;
• historical.

Search indexes can match all to one entity.

This improves user experience without corrupting display name.

Database schema

Entity table:

• ID;
• type;
• native name;
• language/script.

Alias table:

• locale;
• name;
• type;
• authority;
• status.

This is better than one name field.

AI entity recognition

Before translation, identify proper nouns.

Then apply:

• entity database;
• glossary.

This reduces accidental translation.

Translating organization names

Organizations may have official target names.

Check:

• official website;
• registry;
• client list.

If none:

• retain source;
• add descriptive translation if helpful.

Titles

A book/film may have official localized title.

Use official target version.

If scholarly work, source title + translation may be appropriate.

Quality checks

Search target for:

• spelling variants;
• missing diacritics;
• inconsistent romanization.

Names deserve dedicated QA.

Legal/medical records

Identity is critical.

Use authoritative person name.

Do not translate or normalize.

Multilingual transcription

ASR often misrecognizes names.

Provide:

• participant list.

Correct source before translating.

Human review

Reviewers can confirm local conventional names.

But use authoritative source for official identity.

Human familiarity is not a substitute for evidence.

Entity management in a translation pipeline

Before translation, run named-entity extraction and look up candidates in an authoritative entity table. The target request can then include:

• entity ID;
• source form;
• approved target form;
• handling rule.

After translation, verify that the approved form appears. This prevents the model from deciding independently in every paragraph.

Conflicting authoritative sources

Names can differ across:

• passport;
• corporate website;
• news style;
• database.

Define a hierarchy by use case.

For a contract, the registered legal name may win. For a publication about a public figure, the person’s established English spelling may be appropriate. Record the source of authority with the entity alias.

Place-name policy for maps versus prose

A map may prioritize official/local geographical names, while an English news article may use a conventional English exonym. One global “translate place names” rule cannot satisfy both.

Create a content-type policy:

• map display;
• address;
• academic citation;
• general prose.

Multilingual entity QA at scale

A large project can automatically flag:

• same entity with two target spellings;
• native script accidentally translated;
• missing diacritics;
• prohibited historical name;
• wrong romanization system.

Humans then review ambiguous/disputed cases.

Search, analytics and entity IDs

Never use a display string as the unique identifier for a person/place. If the English spelling changes, analytics and search should still recognize the same entity.

Stable IDs allow the language layer to evolve while the data model preserves identity.

Entity extraction confidence and human verification

Named-entity recognition can miss unusual names or misclassify ordinary words as names. Use automatic extraction as a candidate generator, then verify high-risk entities.

For a legal or financial document, a person or company name should be checked against:

• client data;
• registry;
• source document.

The translation model should not be the source of truth for identity.

Name changes over time

People and places can change names.

Store alias records with:

• effective dates;
• source authority;
• historical/current status.

A historical article may correctly use an older name. Automatic “normalization” to the current form can change the source.

Geographic hierarchy

Place records should distinguish:

• city;
• region;
• country.

This helps disambiguate repeated names and choose the correct target-language conventional form.

For addresses, keep the postal form as well as the display/localized form if needed.

Language of origin

The same Latin spelling may represent names from different languages with different target-script transliterations. If transliterating into another script, the language of origin or known pronunciation can matter.

Do not transliterate from the Latin spelling blindly when better source-language data exists.

Entity resolution

Two spellings may refer to one entity:

• native script;
• romanized;
• exonym.

Entity resolution links them to one ID. Search and analytics then remain stable while display adapts by locale.

Quality incident example

Suppose the same executive appears in 300 translated documents with two different spellings. Fixing each file manually is inefficient.

Correct the central entity record, identify affected outputs by entity ID and revalidate them. This is the advantage of entity-aware localization.

Maps and directions

Navigation products have special priorities:

• local official names;
• road-sign recognition;
• user search aliases.

The best display form may differ from a news article. Use product-specific naming policies.

Sensitive/disputed geography

For disputed territories and politically sensitive place names, organizations should have an editorial/legal policy. Do not ask a generative model to decide geopolitical naming case by case.

Record the policy and target market context.

Person-preferred names

When a person provides a preferred spelling, honor it where the context allows. Official legal documents may still require the registered form.

A user profile can store:

• preferred display;
• legal name;
• native script.

Do not merge these fields.

Names in machine translation evaluation

A translation can receive high semantic score despite a wrong name. Entity accuracy should therefore be measured separately.

For high-risk documents, any wrong legal entity can be classified as major or critical regardless of overall translation fluency.

Final checklist

For every important entity:

• identity resolved;
• authoritative form selected;
• transliteration/exonym policy applied;
• locale form consistent;
• source script preserved where required;
• aliases linked;
• target occurrences checked.

Entity management is one of the simplest ways to make multilingual content feel professional and trustworthy.

Name-list preparation for audio projects

Before transcribing interviews, hearings or meetings, prepare a name list containing:

• participant names;
• organizations;
• locations;
• product names;
• likely alternate pronunciations.

Use it for ASR vocabulary hints and reviewer reference. This often produces a larger quality improvement than generic language-model tuning for a one-off project.

Transliteration confidence and verification

If the system must generate a target-script name with no authoritative form, mark the result as:

• machine-generated transliteration;
• reviewer-verified.

Do not store a machine guess as if it were official identity data.

Address handling example

A Japanese address translated for an English reader may need:

• original/local form for postal use;
• romanized form for reading;
• translated country/administrative labels.

The correct order and level of translation depends on whether the output is for mailing, legal evidence or explanatory prose.

Bibliographic and academic names

Academic authors may have established romanizations used in publications. Use those forms for citation consistency even if a different transliteration would be theoretically possible.

Search ORCID, institutional profiles or the source publication where appropriate.

Geographical database hierarchy

For place names, store parent relationships:

• city → region → country.

This helps disambiguate identical names and choose the correct target alias.

It also allows locale policies to differ for a city name versus the country name.

Entity policy for historical documents

Historical sources may use names no longer current. Preserve the historical form in the source transcript/translation if that is what the document says, and optionally add a modern explanatory note.

Do not silently modernize evidence.

Names in subtitles and lower thirds

Video localization should use the same entity record for:

• caption;
• speaker lower third;
• description;
• article.

A single source of truth prevents visibly different spellings around the same person.

High-risk name errors

Treat as major or critical when wrong identity could affect:

• legal party;
• medical patient;
• financial beneficiary;
• academic attribution.

A general semantic metric may barely penalize one letter in a name, so entity QA must be independent.

Reviewer escalation

If the source name is unclear:

• replay audio;
• check file metadata;
• ask client;
• mark uncertain.

Do not choose the most common plausible name.

Final operational principle

Names and places deserve their own data layer because they combine language, identity and external authority. Once entities are resolved centrally, translation becomes much more consistent across scripts, documents and markets.

Frequently asked questions

Should city names be translated?

Use established target-language names when appropriate; otherwise preserve/transliterate.

Should personal names ever be translated?

Generally no.

What if a person has multiple romanizations?

Use the individual’s official/preferred spelling for the context.

What is an exonym?

A target-language name for a place that differs from the local name.

How do I keep multilingual names consistent?

Use stable entity IDs and approved alias records.

Conclusion

Names and places should be managed as entities rather than ordinary translatable strings.

Identify the entity, retrieve the authoritative form, apply a deliberate transliteration or exonym policy and keep native script in the data model.

This approach protects identity and makes multilingual search, documents and products far more reliable.

Research references

• UNGEGN Romanization Systems:
• ICU Transliteration:
• W3C Language Tags:
• Unicode Bidirectional Algorithm: