Same company, different alphabet: we ran 14 names through our own engine and 12 failed

In the suffix post I waved at transliteration — turning Газпром into Gazprom — and called it “its own rabbit hole.” This is the rabbit hole.

I meant to write the polished version: here’s the problem, here’s how we solve it. Then I did the thing I should have done first. I took 14 companies, wrote each one twice — once in its native script, once the way it shows up in a Western database — and ran both through our production pipeline. If transliteration works, each pair should come out as the same canonical string.

Two of the fourteen matched. Every output below is real, unedited, from the live API on October 3, 2026. The failures turned out to be more instructive than any explanation I could have written, so here they are.

The scorecard

How the engine transliterates (and why it’s the obvious design)

Our transliterate stage does what nearly everyone’s does: walk the string one character at a time, look each non-ASCII character up in a mapping table, and fall back to a generic any-script-to-ASCII mapping for anything the table doesn’t cover. It’s fast, it’s simple, and it handles the easy cases. Лукойл → lukoil works. トヨタ (katakana) → toyota works. Katakana is a clean syllabary, Russian Cyrillic maps almost letter-for-letter, and if your data is mostly those, you’ll ship it and feel good.

The trouble is the one input the stage never looks at: which language the text is in. The table is keyed by character alone. Everything below follows from that.

1. A script is not a language

トヨタ自動車株式会社 is Toyota Motor Corporation — Toyota Jidōsha Kabushiki-gaisha. Our output: toyotazi dong che zhu shi hui she.

The katakana part went fine. Then the kanji arrived, and kanji are Chinese characters, so a character-level mapper gives them their Mandarin readings: 自動車 becomes zi dong che instead of jidōsha, and 株式会社 becomes zhu shi hui she instead of kabushiki-gaisha. As a bonus, the boundary between scripts vanished, gluing “toyota” onto the first kanji to make toyotazi.

We sent country: "jp" with that request. It didn’t matter, because the stage doesn’t use it. And the fix isn’t a bigger table — a Japanese kanji has several readings depending on the word around it. You need a Japanese reading dictionary, not a character map.

2. Even inside one alphabet, there’s more than one way to spell it

Ukrainian and Russian share most of Cyrillic, but Ukraine has its own official romanization, and it disagrees with Russian conventions on exactly the letters that show up in company names. Under Ukraine’s 2010 national standard, Укрзалізниця (the state railway) is Ukrzaliznytsia. Our engine produced ukrzaliznitsya — a Russian-style romanization of a Ukrainian word. Same with України: the standard says Ukrainy, we said ukrayini.

Greek does it too. ISO 843 renders η as i, so Εθνική is Ethniki; our table says e, giving ethnike. And Russian ё is e on a passport but yo in other systems — we produced shchyelkovo, which matches neither.

Then there’s the company’s own preference, which follows no standard at all. Ukraine’s national gas company is Нафтогаз; the official romanization is Naftohaz, and the company itself mostly writes Naftogaz. Both appear in real registries. A transliterator that commits to one system will be right about one of them.

3. Characters aren’t words

Chinese is written without spaces, and each character is a syllable. Romanize character by character and 华为 becomes hua wei — two tokens — while every Western record says Huawei, one token. Our canonical for 华为技术有限公司 is hua wei ji zhu you xian gong si: eight syllables, no word boundaries, nothing that lines up with “huawei technologies.”

And some brand names aren’t transliterations at all. 腾讯 is Tengxun in pinyin and Tencent everywhere else. No romanization system will ever get you from one to the other. That’s a lookup, not a transformation.

4. The stages after transliteration assume Latin input

My favorite failure, and the most embarrassing:

阿里巴巴集团 (Alibaba Group) → ariba british airways ji tuan

Transliteration turned 巴巴 into the syllables ba ba. A later stage expands known acronyms — and BA is a known acronym. For British Airways.

That’s the general lesson: once you transliterate early in a pipeline, every later stage sees text that looks Latin but wasn’t written in Latin. Stop-word lists, acronym tables, and token rules tuned on English-language records fire on romanized syllables that happen to collide with them. A pinyin syllable is not an abbreviation, and nothing downstream knows that.

5. Legal suffixes get lost in translation

On the Latin side, the pipeline recognises PJSC, Ltd, and KK as legal forms and sets them aside. On the native side it recognised none of ПАО, 有限公司, 株式会社, Α.Ε., or ش.م.ع. They stayed in the name as pao, you xian gong si, zhu shi hui she, a lone e, and sh m.

Gazprom shows how much this costs. Both sides got all the way to gazovaya promyshlennost — even the synonym expansion lined up — and the pair still failed on three letters of an unrecognised suffix. Sberbank failed the same way. The lesson from the suffix post applies with extra force here: legal forms need to be recognised in their native script, before transliteration turns them into meaningless syllables.

6. You can’t transliterate vowels that were never written

Arabic and Hebrew are abjads: in everyday and business writing, most vowels simply aren’t there. בזק, Israel’s telecom company, is three consonants. Our output is bzk; the company calls itself Bezeq. أرامكو السعودية comes out as aramkw alsawdya. No character mapping can put back information the writer left out.

Aramco adds one more twist. The Latin side matched a synonym and became saudi arabian oil — the legal name — while the Arabic side never reached that synonym at all. The two sides weren’t even trying to match the same name.

What would actually work

None of this is a secret; it’s just more work than a character table. Roughly:

• Transliterate per language, not per script. The country or language hint has to choose the rules — Japanese kanji need Japanese readings, Ukrainian needs the Ukrainian standard.
• Match against several romanizations, not one. Generate the plausible spellings (passport, GOST, BGN/PCGN, the company’s own) and treat any hit as a candidate, or compare in a looser phonetic key.
• Strip legal forms in the native script first. ПАО and 株式会社 are easy to recognise as themselves and hopeless once romanized.
• Treat brand exonyms as data. Tencent, Huawei, Saudi Aramco: a curated mapping, because there’s no rule to find.
• Keep Latin-only stages away from romanized text. Track which tokens started life in another script, and don’t run acronym expansion on them.
• For abjads, compare consonant skeletons. If one side can’t have vowels, strip them from the other side before comparing.

These are now on our own list. I’m not putting dates on them here — I’d rather update this post with a new scorecard when they ship.

A correction

Writing this, I found that our transliteration tool pages claimed things the engine doesn’t do — that the country hint selects the transliteration rules, and that native and Latin forms of a name normalize to the same string. Neither was true, and the pages now say what the tools actually do. The tools are still free, and still useful for seeing exactly what a character-level transliterator does to your data.

Send me your failures

If you work with multi-script company data, you have examples worse than these. Paste them into the tools, and if the output is wrong, tell me — every pair someone sends becomes a test case for the next scorecard.

And if you’d rather call an endpoint than build all of the above yourself, Ambect is the entity-normalization API this came out of — with the honest caveat that you’ve just read exactly where its transliteration stands today.