A translation file that is read like an index, not a document

The lang resource stopped parsing its entire INI file to answer one lookup and started doing a binary search over a sorted one.

The old shape is the obvious one and it scales badly in exactly the wrong direction. A page renders a few dozen translated strings; the file holds thousands, one per phrase in the app, across every language. Parsing all of it to answer each request means the cost grows with how much has been translated rather than with how much is on the page.

Sorting the file changes what it is. It stops being a document you load and becomes an index you seek into: find the key by halving the file, read that line, done. Around it are the pieces that make that safe. Writes are atomic and keep the sort order, so a file being appended to is never a file being read wrongly. There is a per-thread cache, which matters under worker mode where the process outlives the request. And the escape format is the resource's own, because INI escaping cannot round-trip a string containing a double quote.

The day after it landed, a race showed up between concurrent processes writing at once, where a temporary file could be renamed out from under another writer. Worth knowing if you build something similar: the atomic-write recipe needs a unique temporary name per writer, not a shared one.

Engine 1.0. See the Translations chapter.