Blending names that are not English
Engine version 1.0 · Research Desk · Cases computed from the live engine
The engine's splitting rule finds groups of Latin vowels. That rule holds up well for names transliterated into Latin script with the vowels written out, and it degrades or fails entirely elsewhere. This page says where each of those lines falls, with the engine's real output for every case.
Several competing tools advertise support for a long list of languages. As far as we can tell, that means the interface has been translated, not the analysis. We would rather document the limit than translate the buttons.
Aditi + Rohan
Hindi, transliterated
Aditi splits at 1, 2, 3, 4 · engine returns Rohaditi, Adithan, Rohaiti · top candidate keeps 80% of Aditi and 80% of Rohan
Holds up. Both names transliterate into clear vowel-separated syllables, which is exactly what the split rule is built for. The fragments it finds correspond to real syllables in the original.
Ayesha + Bilal
Urdu, transliterated
Ayesha splits at 1, 2, 3, 4, 5 · engine returns Ayeslal, Bilesha, Bilaesha · top candidate keeps 67% of Ayesha and 60% of Bilal
Holds up. The same reason. Transliteration into Latin script with vowels written out gives the engine the boundaries it needs.
Seojun + Haeun
Korean, romanised
Seojun splits at 3, 4, 5 · engine returns Haeujun, Haeuun, Seojn · top candidate keeps 50% of Seojun and 80% of Haeun
Holds up. Korean given names romanise into two clear syllables, which is why Korean fandom blends are unusually clean. This is the best case the engine has.
Nguyen + Thao
Vietnamese, without diacritics
Nguyen splits at 3, 4, 5
Degrades. Vietnamese tone and vowel-quality marks carry meaning, and stripping them changes the name. The engine counts characters correctly and the characters are no longer the name.
Siobhan + Padraig
Irish
Siobhan splits at 3, 4, 5, 6 · engine returns Siobraig, Siobaig, Sioraig · top candidate keeps 57% of Siobhan and 57% of Padraig
Degrades. The spelling and the pronunciation diverge sharply. A split that looks clean in writing can cut through a single spoken sound, and the engine cannot see that because it never hears anything.
Zhang + Xiuying
Chinese, pinyin
Zhang splits at 3, 4 · engine returns Zhaying, Zhanying, Zhaning · top candidate keeps 60% of Zhang and 57% of Xiuying
Degrades. Pinyin initials and finals are not the same units as Latin vowel groups. The split points found here are real positions in the string and they are not syllable boundaries in Mandarin.
Where it should not be used at all
Names written in Arabic, Devanagari, Han, Hangul, Cyrillic, Thai or any other non-Latin script. The engine will accept the input and return candidates, because it operates on characters and those are characters. The coverage figures will be literally true about characters and will not mean what they mean for a Latin-script name, because the split points are not syllable boundaries in those writing systems.
If you are blending names in one of those scripts, transliterate them first and treat the result as a starting point rather than an answer. Then do the part the software cannot: say it to somebody who speaks the language.
The pattern behind all of this
The engine works when spelling predicts sound and fails when it does not. English itself is a poor case by that standard and gets away with it because the names most often blended in English are short and regular. Korean romanisation is a better case than English. Irish is a worse one.
That framing is more useful than a list of supported languages, because it tells you what to expect for a language we have not tested. The limits report covers the failures that are not about language, and the methodology page documents the splitting rule itself.
Common questions
Does the name combiner work with non-English names?
It works well on names transliterated into Latin script with the vowels written out, which covers most Hindi, Urdu, Arabic, Korean and Japanese given names as they are usually spelled online. It degrades on languages where spelling and sound diverge, and it should not be trusted on non-Latin scripts at all.
Can I enter names in Arabic, Hindi or Korean script?
The tool will accept them and return something, and you should not rely on it. The splitting rule looks for Latin vowel groups, which do not exist in those scripts, so the positions it finds are not syllable boundaries in any meaningful sense.
What about accented characters?
Accented Latin characters pass through and are counted correctly. What the engine does not know is that in some languages an accent changes the word rather than decorating it, so a blend that drops one may have dropped the name.
Why not just add support for more languages?
Because that is a research problem rather than a translation problem. Doing it properly means a different splitting rule per language and regression cases to prove it works. Adding a language selector without that would produce measurements we could not defend, which is worse than admitting the limit.