t ATmosphereConf 2026, Victoria Machado de Oliveira (@vicwalker.dev.br) presented on how to attract non-English-speaking users. Her talk was structured around three pillars: onboarding, communication, and translation. A practitioner's field report.
This essay is a case report — a cognitive linguist's rediagnosis of her findings. In a previous essay, "The Grammar Your UI Doesn't Know It Speaks", I responded to Stanislas Signoud's (@signez.fr) talk and described the multilingual problem from inside translation. This essay takes Victoria's talk and describes the same problem from outside — at the level of product design.
If the Signez essay was a theory paper, this one is a clinical report. The format changed because the material changed. Signez dug into structure as a translator. Victoria laid out cases as a practitioner. She pointed. I dig.
Introduction
In the previous essay, I advanced the following propositions:
P1: English zero marking is the default assumption of UI design.
P2: In languages with obligatory grammatical categories, the minimum unit of UI text is larger than in English.
C1: i18n systems are designed with the typological properties of English as their implicit baseline.
The Signez essay demonstrated these through French morphology and Japanese pragmatics. Victoria's talk reports the same pathology from a different angle. Her cases come from the front lines of i18n practice, without a theoretical framework. That is where this essay enters.
Three cases.
Case 1: tweet → tuíte → tuiteiros — The Morphological Life of Loanwords
Presentation
Victoria reported that English "tweet" became "tuíte" in Brazil, and that users became known as "tuiteiros." She offered this as an example of what machine translation cannot capture. Her diagnosis stopped there.
Findings
This is a problem of phonological adaptation and morphological productivity.
When "tweet" enters Portuguese, the phonological system reshapes it into "tuíte." Standard borrowing. What matters is what happens next. "Tuíte" was fully integrated into Portuguese morphology. It received the agentive suffix "-eiro" and produced "tuiteiro." The loanword entered the productive morphology of the host language.
This is a variation of P2. English "tweet" is a zero-marked word: noun and verb at once. Portuguese does not accept this zero marking. The moment the word is borrowed, morphological obligations arise: verbalization (tuitar), agentive nominalization (tuiteiro/tuiteira), pluralization (tuiteiros). One word cannot remain one word.
An i18n translation catalog can register a translation for "tweet." It cannot register "tuiteiros." That word was generated spontaneously by a language community. It exists in a layer that i18n systems were never designed to reach: the morphological creativity of living speech communities.
Differential Diagnosis
This case is easily misdiagnosed as "insufficient machine translation accuracy." Victoria reported it along those lines. But the problem is not accuracy. No amount of accuracy improvement will predict derivatives that a speech community has not yet coined. The pathology lies in the structure of translation catalogs themselves: they are not designed to capture this kind of morphological creativity.
Case 2: "US Central" — Solar Time as a Deictic Expression
Presentation
Victoria stated that "US Central" means nothing in Brazil. Use UTC. Practically correct. The audience accepted it.
Findings
"US Central" is a deictic expression. It takes the speaker's location — the central United States — as an implicit reference point and indicates time relative to that point. For speakers who do not share the reference point, the reference fails. "Three hours from here" is zero information if you do not know where "here" is.
UTC is "safe" because it eliminates deixis. It depends on neither the sun's position nor the speaker's position. The structure here is isomorphic with P1. The English-language UI defaults a specific viewpoint — American geographic divisions — through zero marking. "Central" does not mark what it is central to, because for English speakers that is self-evident. Speakers for whom it is not self-evident are outside the design's field of vision.
Victoria's prescription — "use UTC" — does solve the notation layer. UTC as an absolute coordinate eliminates deictic dependency. A correct prescription for notation.
But fixing notation does not fix experience. I followed ATmosphereConf 2026 remotely for four days and learned this in my body. UTC was printed on the program. The sessions in Vancouver still began at 2 AM in Japan. The body sleeps. The internationalization of notation and the internationalization of experience are different layers.
Differential Diagnosis
This case is typically prescribed as "insufficient timezone notation standardization." Victoria prescribed it that way. For the notation layer, she is correct. UTC is the right answer. But closing the problem at notation makes the deeper structure invisible: deictic expressions embedded in UI design — another manifestation of P1.
Case 3: "Caring Is the Most Important Part" — The Cognitive Limits of Goodwill
Presentation
During the Q&A after Victoria's talk, the room converged on a consensus. Signez stated: "You don't have to do it perfectly at first. You just have to care. If you care, it's cool." The livestream chat echoed the sentiment: "caring is the most important part." This was the room's conclusion.
Findings
Caring is not unimportant. But if caring solved the problem, the problem would already be solved. Well-intentioned developers have worked on i18n for years. Bluesky's translation runs on volunteer goodwill. Signez himself is the embodiment of that goodwill. It is still broken.
The problem is not in the will. It is in the cognition.
For English speakers, the typological properties of their own language are invisible. This is the practical consequence of C1. Zero marking means the absence of marking. What is absent is not perceived. To recognize that English has zero marking, an English speaker must encounter a language with obligatory categories. But i18n designers are, in most cases, English-native developers. The person at the origin of the design cannot see the problem.
Consider what caring can do. A caring developer maintains translation catalogs. Accepts translator feedback. Deploys Crowdin or Tolgee. All of these are app-layer treatments. As long as the protocol layer remains monolingual — as long as feed names do not exist in the translation catalog — caring's reach stops at the app layer. Goodwill does not cross architecture.
A Brazilian developer at Victoria's talk reported on number formatting: what he intended as a tiny library became a massive rabbit hole. Comma-period reversal, negative number notation, two-digit grouping. A developer with goodwill and technical skill was still overwhelmed by the diversity of number formats. When the problem originates in a cognitive blind spot, caring is a necessary condition. It is not a sufficient one.
Differential Diagnosis
"Insufficient caring" is the most common misdiagnosis. It is dangerous because the prescription targets individual attitude change. "Care more." "Be mindful of diversity." Correct, but ineffective. When the pathology lies in cognitive structure rather than individual attitude, the prescription must be architectural change.
Discussion
The three cases manifest at different layers. The underlying pathology is shared. C1 from the previous essay — i18n systems are designed with English typological properties as implicit baseline — appears as: the structure of translation catalogs (Case 1), deictic dependency in time notation (Case 2), and cognitive blindness in design (Case 3).
Victoria's talk has value as case collection. Every problem she listed would draw a nod from any i18n practitioner. But when a practitioner's report closes as "tips and guidelines," the structural pathology is concealed. "Use UTC." "Don't rely on machine translation." "Caring is what matters." All correct. All app-layer prescriptions. Until protocol-layer design changes, the same cases will recur.
The Signez essay built theory. The Victoria essay tested it clinically. What the two essays together demonstrate: the multilingual problem of UI is not a problem of translator skill or product manager goodwill. It is a problem of protocol design.
Conclusion
One open question to add.
The previous essay asked: "Does a path exist for translators to influence protocol-layer design?" During the Q&A after Victoria's talk, a participant from Japan asked: "Where can we go after we go home?" Victoria answered: "We can start by organizing on Bluesky." The self-organization of translator communities is beginning.
But self-organization alone is not enough. What is needed is an institutional path for translator knowledge to reach protocol design. Whether ATProto's Lexicon definitions gain multilingual fields is not a translator's decision. It is a protocol designer's decision. Without a mechanism for translators to participate in that decision, caring remains confined to the app layer.
Respect to Victoria for her work. Cases brought back from the field by practitioners are the best material for testing a theorist's propositions.