Internationalization Is an Engineering Problem: A Conversation with Neha Heera

Digital reading has gone global much faster than the software underneath it. Worldwide eBook revenue is projected to reach $15.14 billion in 2026, yet most reading software was designed by people thinking in English, for readers assumed to be doing the same. Whether a Hindi novel opens cleanly on a device in Jaipur comes down to engineering decisions nobody ever sees.

Neha Heera, Senior Engineering Manager at Toast, has spent more than 18 years building mobile, embedded, and AI systems, and she wrote a book about exactly this problem, Building Global-First Systems: Internationalization Beyond Translation. A decade before writing it, she led the engineering that put 5 Indian languages on Kindle eReaders for the device's India launch, on hardware with almost no room to spare.

We spoke with Heera about that launch, what it took to fit complex scripts onto stubborn hardware, and why she thinks the lessons matter more now that AI is moving into the text stack.

When a product built in English moves into a new language market, what breaks first?

The text pipeline, and it breaks in places teams never think to look. Translation gives you new strings. It does not give you script shaping, line breaking, sorting or input. English spoils engineers: a character is a glyph, words break at spaces, the alphabet sorts itself. Step outside that bubble and each of those comforts turns into a bug.

And the bill is commercial, not cosmetic. Reading products feel this more sharply than most, because nobody buys a book their device cannot display. A catalog in a language your software cannot render is inventory you cannot sell. That is why I have always treated internationalization as engineering with a revenue line attached rather than a localization checkbox.

How do you scope a launch that has to ship Hindi, Tamil, Marathi, Gujarati and Malayalam at once, on devices with very little memory to spare?

You start by admitting the scope is bigger than anyone budgeted for. Rendering the scripts correctly was only the visible layer. Underneath it sat keyboards and predictive text for each language, search and sorting that respected each language's rules, text-to-speech and accessibility, all squeezed into the memory, storage and latency limits of e-ink hardware. The bar we set was blunt: a reader in Pune buying a Marathi novel should get an experience as good as the English one.

The business case was straightforward - many readers prefer to buy and read in their native language. India was already one of Amazon's fastest-growing Kindle markets, with sales reportedly up more than 200% in 2015. Leadership publicly expected the country to overtake the U.S. within a few years. At launch we had thousands of digital books in those 5 languages on devices and apps, bestsellers and classics included. Every language we enabled opened a shelf that readers could actually buy from.

What makes Indic scripts so difficult to render correctly, and what additional challenges did e-ink hardware create?

The difficulty is real, though for more interesting reasons than people assume. In Devanagari and the southern scripts, a character is not a glyph. Consonants fuse into conjuncts, vowel signs attach above, below or beside the base letter, and some marks visually reorder, so the vowel you type after a consonant gets drawn before it. The shaping engine has to get all of this right at every font size and every line break. Miss a single rule and the text is not slightly off. It is misspelled, and a native reader sees that instantly.

E-ink then takes away your escape hatches. We had limited memory, slow refresh and a battery promise measured in weeks, so we could not solve shaping by throwing compute at it. Fonts and layout logic had to fit budgets that would make a phone engineer laugh, while page turns stayed instant. Most of that work is invisible by design. It only shows up as the absence of lag.

Once the scripts rendered correctly, where did the project come closest to breaking?

Typing. Rendering is a closed problem, you control the content and the fonts. Input is wide open: real people typing real words with habits you never predicted. Keyboards and predictive text for 5 scripts forced us to rethink layouts, dictionaries and memory use all at once. Sorting was the quiet danger. Collation rules differ by language, and a library that orders titles wrong looks broken even when everything else works perfectly.

The near disasters were tradeoffs, never bugs. Better prediction wanted bigger dictionaries than the device could hold. Richer typography wanted storage the catalog needed. We cut features that demoed beautifully but blew the latency budget, and kept the ones a daily reader would touch 100 times. Deciding what production quality meant before we wrote the code, that turned out to be the actual project.

Why are you skeptical of the current push to put large AI models into keyboards and other input systems?

I made the argument at length in my hackernoon article, Why Smarter Models Make Worse Keyboards, and the short version is that a keyboard is a real-time system before it is an intelligence problem. Smarter usually means bigger, and bigger means slower and less predictable. Users feel every millisecond of an input surface. A keystroke that lands late, or a suggestion that shifts mid-thought, costs trust that no amount of accuracy buys back.

That skepticism comes straight from the eReader years. Once you have shipped text systems on hardware with no headroom, you stop believing capability automatically improves experience. Plenty of teams now over-model and under-engineer. Whether the system stays fast and predictable while the model works matters far more than how clever the model is.

After almost 20 years of watching companies chase global users, what do you still see teams getting wrong?

They bolt internationalization on at the end, every time. The decisions that matter are made in week one: how strings are handled, what layouts assume about text direction and length, how sorting and input work. Retrofitting those after launch costs a multiple of doing them early, and the bill always arrives at the worst moment, right when the company wants to expand. I have watched a team discover their stack could not sort a new market's alphabet 6 weeks before launch.

The fix is unglamorous: treat new languages as an engineering requirement, not a content task. Budget for script complexity, test with native readers early, and measure quality in the target language rather than the source one. Teams that work this way stop thinking of English as the product and everything else as a port. The default user does not exist anymore.

As AI moves deeper into the text stack, what changes about internationalization and what stays the same?

It raises the ceiling and lowers the floor at the same time. Translation, speech and prediction are improving fast, but model quality is uneven across languages because training data is uneven. A language can have hundreds of millions of speakers and still be poor in data. India alone was set to cross 900 million internet users in 2025, with 98% of them consuming Indic-language content, and products that lean on AI without checking that data gap will feel worse in exactly those markets.

So my focus has not really moved in 10 years: real-time systems, constrained environments, users whose language the original spec never imagined. The industry still files those readers under edge cases. They are not edge cases. They are the market, and the products that win them will be the ones engineered for them from the first commit.