Writing Systems That Aren't Roman Scripts
I spent three days debugging a form validation issue last year that came down to character normalization. The user typed "é" in their name. On Windows with the default system font it looked fine. On the staging server running a different locale it rendered as two separate characters. The validation regex matched one input method but rejected another. I ended up using NFC normalization on the backend and a font stack that included Noto Sans for the edge cases. Took about four hours to get right. You don't really notice these problems until they hit production. There's no single "alphabet" that covers most languages. People say "alphabet" when they mean any writing system, but that's imprecise. The Latin alphabet you're reading now is just one of dozens. Some languages use modified versions of it. Others use completely different systems. A lot of languages have switched scripts over time. Vietnamese used ch Nôm, a logographic system based on Chinese characters, before switching to Latin script in the 17th century under Portuguese missionaries. That transition wasn't smooth. There are still debates about it today.
What Alphabet In Different Languages Actually Looks Like
The Latin alphabet has 26 letters. Modified versions add diacritics, ligatures, or entirely new characters. Turkish has "ı" (dotless i) and "İ" (dotted I). That distinction matters in sorting and case conversion. Azeri uses the same Latin base but adds "". Kazakh is switching from Cyrillic to Latin in 2025. The migration is causing real headaches for software that hardcodes character ranges. Greek has 24 letters. It's not a direct replacement for Latin in most contexts because the sound values shifted over millennia. "Beta" doesn't sound like English "beta". Technical terms borrowed from Greek keep the original spelling in most languages, which is why you see "" for phi and "" for psi in math and physics papers. The Greek lowercase "" only appears at the end of words. That's a positionally dependent character, which means your regex needs to handle it differently than other letters. Cyrillic looks like Latin to most people because they share origins. But the mapping isn't one-to-one. "" looks like Latin "P" but represents /r/. "" looks like Latin "H" but is /n/. "" is /s/. This causes confusion in transliteration and makes character-by-character comparison unreliable across scripts. I learned this the hard way when building a search feature that indexed names across Russian, Bulgarian, and Serbian. The collation rules differ for each language even though they share the same script.
Abugidas and Syllabaries
Most of the world's writing systems aren't alphabets. They're abugidas, where each character represents a consonant-vowel pair and the vowel is marked with a diacritic. Devanagari (used for Hindi, Sanskrit, Nepali) is one. Thai is another. Amharic, used in Ethiopia, is a third. These systems are efficient for their languages but break naive assumptions about character counting and indexing. Japanese has three scripts running simultaneously. Hiragana for grammatical elements, katakana for foreign loanwords and emphasis, kanji for content words. A single sentence might mix all three. The Unicode normalization form matters here because some characters have precomposed and decomposed forms. I hit this when building a text processing pipeline for a Japanese content platform. The same word could appear in multiple normalized forms depending on how it was entered. We ended up using Unicode Normalization Form C on input and stored the normalized version. The edge case was legacy data that had been entered with incompatible normalizations, which took a separate pass to fix. Korean uses Hangul, an alphabet in the technical sense but with syllabic blocking. Each "character" you type is actually a cluster of jamo (consonants and vowels) that form a single codepoint. The composition rules are deterministic, which makes it one of the more predictable non-Latin systems. But compatibility characters exist for historical reasons, and mixed composed/decomposed forms show up in real data. If you're doing character-level operations on Korean text, use grapheme clusters, not codepoints. The difference matters for things like word boundaries and text selection.
Get the Full Details
Right-to-Left Scripts
Arabic, Hebrew, Persian, Urdu, and others write right to left. This isn't just a direction flag. Arabic changes shape depending on its position in a word. Initial, medial, final, and isolated forms are different characters. Some languages like Kurdish Sorani use modified Arabic scripts. Pashto adds new letters. The Unicode standard handles this with contextual shaping and bidirectional algorithm, but font rendering varies. I worked on a project where the CMS displayed Arabic content correctly in Chrome but broke in Firefox on Linux. The issue was a missing font fallback chain. Adding a proper font stack with Amiri or Noto Naskh Arabic fixed it. Hebrew is interesting because it's written without vowels in most modern texts. Niqqud marks exist but are rare outside religious or educational material. This means the same sequence of consonants can be read differently depending on context. Transliteration systems like Libnit or ISO 259 don't capture all the ambiguities. If you're building a search or matching feature for Hebrew content, account for the fact that users may enter text with or without vowel marks unpredictably.
Logographic Systems
Chinese characters, Japanese kanji, and Korean hanja share a common origin but aren't identical systems. Simplified Chinese dropped many radical forms. Traditional Chinese kept them. Japanese simplified some characters differently again. A character that looks the same might have a different pronunciation or meaning in each language. I encountered this when building a cross-language dictionary lookup. The character "" means "study" in all three, but the word for "learning" is "" in Chinese, "" in Japanese, and "" in Korean. The character is shared, the usage isn't. Treating them as interchangeable breaks the tool. Vietnamese ch Nôm is largely extinct as a writing system. Modern Vietnamese uses Latin script with extensive diacritics. The tone marks (acute, grave, hook, tilde, dot below) combine with the base letter to create distinct characters. There are 12 total tones in Northern Vietnamese. Each tone has a specific mark. The character "á", "à", "", "ã", "" are all different codepoints, not combinations. This makes string comparison straightforward but character entry tricky. Most Vietnamese users type with Telex or VNI input methods, not by selecting diacritics manually.
Practical Considerations for Building With Multiple Scripts
Unicode normalization is non-negotiable. Use NFC for most purposes. Decomposed forms show up when users copy text from PDFs or older systems. Precomposed forms are what you get from modern input methods. Mixing them breaks equality checks. Python's unicodedata.normalize('NFC', text) handles this. JavaScript has normalize() but it's less commonly used. Make sure your entire pipeline normalizes consistently. Font fallback matters more than you'd expect. When a font doesn't contain glyphs for a script, the OS falls back to another font. The fallback chain varies by platform. macOS includes a broad set of system fonts. Windows is more limited unless you install Noto or other open fonts. Linux depends on the package. If you're building a web application, specify a font stack with Noto Sans as a catch-all. It covers most modern scripts. Bidirectional text is the hardest practical problem. A page that mixes Latin and Arabic text can render incorrectly if the browser's BIDI algorithm gets confused. This happens with inline quotes, mixed-direction lists, and form labels. The tag helps but doesn't solve everything. Test with real content, not just placeholder text. Lorem ipsum won't catch BIDI issues.
Character counting is unreliable without grapheme clusters. Emoji with skin tone modifiers, flag sequences, and combining marks all count as single visual characters but multiple codepoints. Swift and Java have proper grapheme cluster support. Python's regex module does too. JavaScript doesn't have first-class grapheme cluster handling, so string length is often wrong for multilingual content. Use the Intl.Segmenter API if you need to count graphemes in JS. Sorting varies by language. German sorts ß as ss. Swedish puts Å, Ä, Ö at the end. Turkish has the dotted/dotless I issue I mentioned. Collation rules are language-specific. Use the appropriate locale in your sorting function. Don't rely on Unicode codepoint order for anything user-facing.
What Doesn't Work
Assuming any script maps 1:1 to Latin is the most common mistake. It breaks transliteration, search, and matching. Trying to validate input by character whitelist fails for scripts with thousands of characters. Using regex ^[a-zA-Z]+$ on any form that accepts non-Latin input will reject valid content. I've seen this in production systems across multiple companies. Hardcoding font sizes for non-Latin scripts causes layout breaks. CJK characters are typically square and take up more horizontal space than Latin at the same size. Line height needs adjustment. Some systems use em units to handle this, but it's not universal. Database collations are often wrong out of the box. MySQL's default utf8mb4 collation sorts by Unicode codepoint, which is wrong for most languages. Set the collation to match the language of your content. utf8mb4_unicode_ci is closer to what you want for most purposes, but language-specific collations exist for German, Turkish, and a few others.
IME (Input Method Editor) support is platform-specific. Chinese, Japanese, and Korean users rely on IMEs to convert typed romanization into characters. Web forms sometimes break IME composition, causing characters to appear one at a time instead of as a complete glyph. The compositionend event in JavaScript helps detect when the IME is done. Not all frameworks handle this well.
Where to Get Reference Material
The Unicode Standard is the authoritative source. It defines codepoints, properties, and algorithms. The book "Unicode Explained" by Mark Davis is a readable introduction. For font information, the Unicode Consortium maintains a chart viewer. For script-specific details, each writing system has its own section in the standard. CLDR (Common Locale Data Repository) provides locale-specific sorting, numbering, and formatting rules. It's what most operating systems and browsers use under the hood. The repository is maintained by the Unicode Consortium. Download the data directly if you need to implement locale-aware features without relying on the OS. For practical testing, use the University of Texas's Unicode Character Database. It has properties for every codepoint. Script, category, and bidirectional class are all available. If you're building a validator or sanitizer, query this database instead of hardcoding character ranges.
Font testing tools include the Noto font family from Google. It covers the vast majority of modern scripts. The Noto Color Emoji variant handles emoji properly. For legacy scripts like Egyptian hieroglyphs or cuneiform, the Code2000 font is one of the few options that supports them, though it's outdated. The New Adobe Sangam MS is another legacy option. When building multilingual systems, the work isn't in the alphabet itself. It's in the normalization, collation, font rendering, and input handling around it. Those are the parts that break in production. I learned that the hard way with the NFC issue and the Hebrew niqqud ambiguity. Both were fixable. Neither was obvious from the spec.
