At ATmosphereConf 2026, Stanislas Signoud (Signez) presented on the challenges of translating Bluesky's UI into French. A field report from a volunteer translator. Five case studies from the front lines of internationalization (i18n).
This essay is a cognitive linguist's response to Signez. I redescribe the problems he faced on the ground using the frameworks of linguistic typology and cognitive linguistics. The aim: push the locus of the problem down from the app layer to the protocol layer.
In the same session block, Victoria Machado de Oliveira (@vicwalker.dev.br) presented on acquiring non-English-speaking users. Signez described the problem from inside French translation. Victoria touched the same problem set from outside, at the level of product design. A follow-up essay will address her talk.
1. Definitions
Zero marking — The phenomenon where English does not morphologically mark a distinction. "Post" is the same morpheme as noun and verb. Part of speech is determined solely by syntactic position.
Obligatory grammatical category — Grammatical information a speaker cannot omit. French grammatical gender and élision fall here. "Le arbre" is ungrammatical; it must be "l'arbre." English carries no such obligation.
Obligatory pragmatic category — The phenomenon where the pragmatic force of a speech act becomes unavoidable at the point of lexical selection. Observed in Japanese UI text.
The 1:1 assumption of i18n — The tacit assumption in i18n libraries that one string maps to one meaning. English polysemous zero marking becomes invisible under this assumption.
2. Propositions
P1: English zero marking is the default assumption of UI design.
The "post" problem Signez reported — noun/verb homophony collision — is not a French problem. It is a consequence of i18n systems treating English's lack of morphological distinction between parts of speech as the normal state. Crowdin's translation catalog held a single entry for "post" because English zero marking was baked into the system design.
In Jackendoff's Parallel Architecture (Jackendoff 1997 1), English "post" maps to both noun and verb paths at the level of phonological structure. French forces a split at the phonological level: "post" vs. "poster"/"postez." The 1:1 assumption of i18n encodes English phonological non-differentiation as the implicit norm.
P2: In languages with obligatory grammatical categories, the minimum unit of UI text is larger than in English. This "size" surfaces in morphology and in pragmatics alike.
The French case. The grammatical gender problem Signez reported stems from the obligatory accord: every adjective, article, and past participle attached to a noun must agree in gender. The UI text "abonné" (masculine) forces a decision about the user's gender at the point of translation. English "follower" carries no such load.
Linguistics treats grammatical gender as arbitrary. That "chapeau" (hat) is masculine and "tulipe" (tulip) is feminine has no motivation. Yet in UI text, this arbitrary category forces users to confront a gendered choice. What is arbitrary at the level of the system (langue) becomes marked at the level of use (parole).
Signez's épicène-first strategy — prioritizing words that share the same form across genders — is describable as a cognitive load minimization strategy. If obligatory gender agreement is unavoidable, selecting a lexical item that eliminates the need for agreement itself bypasses the processing cost.
The Japanese case. Bluesky's placeholder text "What's up?" is translated as 「最近どう？」("How have things been lately?"). In English, "What's up?" is near-phatic: its purpose is social contact maintenance, and its force as an information request is vanishingly weak. But 「最近どう？」 reads as an information request to Japanese speakers. The illocutionary act "tell me about your recent situation" is imposed.
The same UI text carries near-zero pragmatic force in English but generates cognitive load in Japanese. Where English can zero-mark pragmatic force, Japanese is obligated to make a pragmatic choice.
The two cases occur in different languages at different layers, but the structure is identical. A dimension English avoids through zero marking, other languages cannot avoid. French: the morphological layer (gender agreement, élision). Japanese: the pragmatic layer (illocutionary force, social distance marking).
P3: Protocol-layer language design cannot be compensated by app-layer translation.
The untranslatability of feed names that Signez identified is a problem of a different kind from P1 and P2. "Following" and "Discover" are feeds built by Bluesky PBC, yet they are absent from the translation catalog. "For You" is a third-party feed built by SpaceCowboy; translators have no authority to rename it at all. Users perceive all of these as part of the product UI.
Adding PBC-built feed names to the catalog is technically possible. SurfDude29's PR attempts exactly that. But third-party feed names cannot be translated in principle unless the feed definition carries a multilingual field.
Moderation labels already have a multilingual mechanism. Feed names do not. This asymmetry is a design choice, not a technical constraint.
The same problem extends to terms of service, community guidelines, trending topics, and help pages. What Signez described as "expecting users to follow rules written in a language they cannot read" is a direct consequence of the protocol layer being monolingual.
No matter how precise the work of app-layer translators, a non-compensable fault line remains in the non-English user experience as long as the protocol layer is designed for a single language.
3. Corollaries
C1: i18n systems are designed with the typological properties of English as their implicit baseline.
This is not a criticism that i18n is "incomplete." It is a structural description: the typological properties of the language at the design's point of origin have been fixed as the system's assumptions. Zero marking is a property of English. It is not a universal property.
C2: The translatability of feed names, labels, and terms of service is a protocol design problem.
Whether ATProto's Lexicon carries multilingual fields is a question for protocol designers, not for translators. The reach of goodwill volunteer translation at the app layer has limits. Those limits are determined at the protocol layer.
4. Open Questions
Is it feasible to introduce multilingual fields into ATProto's Lexicon definitions? If so, which record types should be prioritized?
Beyond the French morphological and Japanese pragmatic cases examined here, to which other typological properties of human languages is the zero-marking-based i18n design blind?
If the limits of app-layer translation are determined at the protocol layer, does a path exist for translators to influence protocol-layer design?
Respect to Signez for his work. The fundamental problems of protocol design are reflected in the load a volunteer translator chose to carry. His talk made that visible.