← Sesla Dev Log

April 30, 2026 · Gökhan Oğuz

Spotty and the Missing Pronouns

Sometimes a single confused-looking tile is the loose thread that unravels three different bugs at once. Today's thread was a Turkish word for a spotted cat, sitting in the middle of the people category.

"In Turkish people, there's a tile called 'Benekli'. What is that?"

The Mulberry symbol set ships about 3,000 SVGs with English labels, and someone — me, a year ago, in batches of fifty — translated each one into Turkish. Spotty became Benekli. It's a perfectly fine Turkish word. It just doesn't mean what the English word means in this context.

English spotty, in the people category, means a person with freckles or skin spots. Turkish Benekli, in the people category, reads as a spotted animal — a cat, a leopard, a cow. The image even shows a person, which makes it weirder. It looks less like a translation and more like the app got bored mid-thought.

The fix was one line: add hide:tr to the symbol's locale tags. The English version was already hidden for the same kind of reason, which should have been a hint a year ago.

But the question that followed was the interesting one.

"Do we have I, you, he, she, it, we, they?"

Reasonable thing to ask. AAC apps live and die by their pronouns. "I want," "you eat," "we go" — these are the bones of every sentence a non-verbal child needs to build. So I went to look.

Turkish has six: Ben, Sen, O, Biz, Siz, Onlar. I found two of them in the people category. The other four were in the numbers category, three of them tagged hide:tr, and the third — O — labeled in English as just "O", the letter.

This is what happens when symbol data accumulates over a year of porting from a third-party set without anyone reading the result top to bottom. Biz ended up in numbers because Mulberry's we symbol shares an asset filename with a numerical concept, and the import script didn't know better. O ended up in numbers because the script saw a one-letter label and assumed alphabet. Turkish O means "he, she, it." A single character carrying enormous load.

The hide:tr tags weren't malice either. They were early-stage caution: "I haven't reviewed these yet, hide them until I do." Then I never came back.

Six rows changed in symbol_data.json:

• Move ses-031, ses-032, ses-033 (Biz, Siz, Onlar) from numbers to people.
• Drop the hide:tr tags. Drop the stale image_type: missing on Siz — the SVG was always there, someone forgot to flip the flag.
• Re-tag mul-2060 from numbers to people, change its English label from "O" (the letter) to "he/she/it" (the pronoun). The Turkish digit zero already exists separately as mul-3118 labeled Sıfır.
• Renumber the six pronouns to sort_order -100 through -95 so they cluster at the front of the people grid in the canonical Turkish order children learn them in school: Ben, Sen, O, Biz, Siz, Onlar.

Bumped the seed version from 44 to 45 so existing devices re-seed on next launch. Otherwise the corrected JSON ships but nobody sees it, because the seed-once logic short-circuits.

While I was in the data, I unhid Hangisi ("which") to round out the question-word set: Ne, Ne zaman, Nerede, Nasıl, Neden, Kim, and now Hangisi. That's seven of the seven Turkish question words a five-year-old uses. They were all in the data; one was just invisible.

The custom-symbol editor was asking the wrong question

The same week I shipped the custom-symbol feature — Plus users can now add their own tiles from a photo plus a label. The editor I built asked for two labels, Turkish and English, with a verb-conjugation helper hint under each. Clean, careful, internationally-thoughtful.

A user pointed out the obvious thing. They had two profiles on one device, one Turkish and one English, and the editor was forcing them to type a translation in a language they didn't speak. To add a photo of anneannem (their grandma), they had to pause and think: "...what's the English word for grandma again? Maternal?" To capture a thought, you should not have to translate it.

I had built a multilingual data structure for a fundamentally monolingual moment. Bundled symbols are multilingual because they ship to everyone. A custom symbol is, by definition, the user capturing something private to them, on their device, in their language, right now. It is an act of recognition, not of translation.

The fix was to delete a TextField. The single label is written into the existing textTr column. Display already falls back via textEn ?? textTr, so a label entered by an English profile still renders correctly if a Turkish profile later opens the same row. Both languages get a coherent display, neither user gets asked to do work they don't want to do.

Multilingual data structures are a tax. They're worth paying when content travels across users. They're a friction when content belongs to one user.

I also took the now-shipping feature and added it to the paywall as the third bullet: Add your own symbols from photos. Tightened from older copy that said "Create your own boards & symbols" — custom boards isn't a shipped feature yet, and the App Store's section 3.1.2 is unforgiving about paywalls promising things the binary doesn't actually deliver.

What links the three

Three different fixes, one shared lesson. AAC apps have an unusually long distance between data is technically present and user can find and use it. A symbol with the wrong category, the wrong locale tag, the wrong English label, or the wrong sort_order is, from the user's perspective, missing. A label field asking for a translation the user can't provide is, from the user's perspective, a wall.

None of these were caught by the 1063 unit tests. All of them were caught by one person looking at the screen and asking a question that started with "wait — why...". That's the cheapest, most underrated form of QA I have access to, and I should run it more often.