The Hong Kong problem: what shipping language variants taught me about designing for people who know less than I assumed

I'm a chef by trade — I run five kitchens in Mendoza, Argentina, one of them listed in the Michelin Guide. I started building EzWrite (turns a rough message into 3 polished versions, in whatever tone and language you need) with Claude as my coding partner, no dev background going in.

Last week I shipped something that took way longer to design than to code: regional language variants.

EzWrite already had this for Spanish — Argentina, Uruguay, Spain, and "neutral LatAm" write pretty differently in a formal message, and the app auto-detected which one to use. But English, German, French, Portuguese all have the same problem and none of them had it. Formal British English isn't formal American English. Swiss German drops the ß. Québécois French has its own register.

The backend part was easy — a country → style-note map per language, resolved from the visitor's IP, with a manual override if they're writing to somewhere else. Maybe 2 hours of actual code.

The UI took a full afternoon, because of Chinese.

My first instinct was a selector: "Simplified / Traditional." Then I tried to imagine using it myself — if I had to write to someone in Hong Kong, would I know which one to pick? I didn't. I had to look it up. And if I, building the feature, didn't know, I was about to ship a selector that assumes knowledge most of my users don't have either.

So I flipped it: the selector shows places, not scripts — China, Taiwan, Hong Kong, Singapore — with the technical detail as a small parenthetical for the few people who do know and care. You pick by who you're writing to, not by a linguistics quiz.

Same logic made me rethink auto-detection. I was about to key it off the UI language, but the UI only exists in 3 languages while the app writes in 26+. So instead: if your IP matches a country in the variant map for whatever language you picked, assume you're writing natively and detect silently. If it doesn't match — say you're in Argentina writing in German — that's someone writing to a different place, and that's exactly when the selector should be front and center.

Deliberately didn't go further: no deeper Spanish-by-country split (Mexico's in, but most other differences are colloquial, not present in a polished message), no Arabic dialects (Modern Standard is already the right neutral choice for formal writing), no Japanese/Korean/Hindi variants (not enough regional variation in formal register to matter).

Curious if anyone else building multi-market/multi-language products has hit the same "the labels assume expertise the user doesn't have" trap — and how you fixed it.

(If you want to see it: ezwrite.app)