Unicode Case Folding, String Algorithms & Software Naming Conventions

01. The Infamous "Turkish i" Bug

Turkish and Azeri use two distinct letters for the i sound: dotted i / İ and dotless ı / I. Under Turkish rules:

• lowercase dotted i uppercases to dotted capital İ (U+0130), not I;
• lowercase dotless ı (U+0131) uppercases to I.

The bug appears when a library silently picks the machine's locale. In Java, "admin".toUpperCase() without an explicit locale gives "ADMİN" on a Turkish system, and C# ToUpper() behaves the same way with the current culture. A check like role.toUpperCase().equals("ADMIN") then fails only for Turkish users, and only in production.

JavaScript is safer here: toUpperCase() and toLowerCase() ignore the host locale, and only toLocaleUpperCase("tr") applies Turkish rules. The rule that follows is simple: use locale-independent conversions for identifiers, keys and protocol strings, and locale-aware conversions only for text shown to people.

"title".toUpperCase()              // "TITLE"  (always)
"title".toLocaleUpperCase("tr")    // "TİTLE"  (explicit Turkish rules)
"I".toLocaleLowerCase("tr")        // "ı"      (dotless)

02. When Uppercase Changes the Length

Unicode case mappings are not always one character to one character. Three examples show up regularly:

• German sharp s: "straße".toUpperCase() returns "STRASSE". One character became two.
• Ligatures: the single character fi (U+FB01) uppercases to FI.
• Greek final sigma: Σ lowercases to σ in the middle of a word but to ς at the end, so lowercasing depends on context.

If you store an uppercased value in a fixed-width column or a fixed-size buffer, a string that fit before conversion may be truncated or rejected after it. Always measure the converted string, not the original.

03. Case Folding: Comparing Strings Without Case

Lowercasing and case folding are different jobs. Lowercasing prepares text for display. Case folding, defined in the Unicode CaseFolding.txt data file, prepares text for caseless comparison. The difference is visible with the German example:

"STRASSE".toLowerCase() === "straße".toLowerCase()   // false: "strasse" vs "straße"
// Full case folding maps both to "strasse", so they compare equal.

JavaScript has no built-in caseFold(). Practical options are to compare with Intl.Collator(undefined, { sensitivity: "base" }) for human-facing matching, or to normalize and lowercase consistently on both sides of every comparison for identifiers. The important habit is applying one canonical transformation everywhere a value is stored and looked up.

04. Normalization: One Character, Two Representations

The letter é can be a single code point (U+00E9) or an e followed by a combining acute accent (U+0065 U+0301). They look identical and compare as different strings:

"\u00e9" === "e\u0301"                              // false
"\u00e9" === "e\u0301".normalize("NFC")               // true
"\uFB01".normalize("NFKD")                            // "fi"
"\uFF21".normalize("NFKD")                            // "A" (full-width A)

For usernames and similar identifiers, a common safe pipeline is normalize (NFKC), then lowercase or case-fold, then compare. Skipping the first step lets two visually identical names coexist as different accounts.

05. Naming Conventions Across the Stack

Modern projects pass data across several environments, each with its own convention. Mixing them inside one layer is what causes mapping bugs:

Bridging these conventions needs a deterministic splitter that breaks words on uppercase transitions, digits and punctuation, then re-joins them in the target style. That is what the ToolsGrid Case Converter does, using locale-independent JavaScript conversions so the output is identical on every device. Its slug mode applies NFD and strips combining accents, so Café Menu becomes cafe-menu.