UI Translation Is Not Localization

Translating interface strings is not localizing an experience. The distinction matters.

At ATmosphereConf 2026, two talks address this directly. Stanislas Signoud presents "Blousques," a case study on translating Bluesky's UI into French. Victoria Machado hosts a panel: "How to have more non-English speaking users." Both talks acknowledge a problem. The deeper issue goes further.

The deeper issue: non-English users do not fail because they cannot read the buttons. They fail because the entire experience — feed discovery, content recommendations, scroll rhythm, onboarding flow — assumes English as the default cognitive environment. Changing button labels does not fix this. The experience itself needs localization.

I write from Japan. Japanese is the second-largest language community on Bluesky. We are not a niche. We are the first major test case for whether ATProto can serve a non-English population at scale.

This article is a specification request. Not a complaint. A spec.

The langs Metadata Problem

A concrete example. Bluesky's official account posted Japanese-language content with the langs metadata field set to en. Not once. Repeatedly.

The consequence: Bluesky's translation feature checks the langs field to decide whether to show a translation button. An English-speaking user whose interface language is en sees a post tagged en. The app concludes: no translation needed. The button never appears. The English-speaking user sees Japanese text with no way to translate it. The reply section fills with confusion. "What does this say?" "Is this a test post?"

The language mismatch detection exists. Bluesky's client can warn a poster when the detected language of their text does not match the langs metadata. The problem: this warning fires intermittently. Sometimes it appears. Sometimes it does not.

Intermittent feedback is worse than no feedback. James Reason's Swiss cheese model explains why. Each defense layer — client default settings, automatic language detection, manual review, post-publication preview — has holes. When a warning fires every time, the user builds a habit of checking. When it fires sometimes, the user builds a different habit: "It warned me last time, so if there is no warning this time, I must be fine." The absence of a warning becomes false confirmation. Every hole aligns. The mistagged post reaches the world.

This is not a user error. This is a system design failure. The detection exists but cannot be trusted. An unreliable warning is structurally more dangerous than no warning at all.

The Discover Feed Failure

Custom feeds are Bluesky's strongest differentiation from X. The ability to subscribe to algorithmic feeds built by anyone — not just the platform — is the feature that justifies ATProto's complexity. This is what the protocol makes possible that centralized platforms cannot replicate.

For non-English users, this feature is broken at the entrance.

Set your Bluesky interface to Japanese. Open the Discover feed. The recommended custom feeds are almost entirely English. The trending topics are English. The suggested Starter Packs are English. The single most compelling reason to choose Bluesky over X is invisible to the second-largest language community on the platform.

Users migrating from X expect algorithmic personalization. X's "For You" feed creates a feedback loop: use the app, and the recommendations improve. Users habituate to this. On Bluesky, the Discover feed's algorithm is not publicly documented. What is documented is user behavior: Japanese users report trying to tune Discover through follows, mutes, and blocks, finding the results unresponsive, and concluding the platform does not work for them. Whether this is an algorithm problem or an onboarding problem is secondary. The experience fails.

The language dimension compounds this. A reading speed gap quantifies the cognitive cost.

Brysbaert's 2019 meta-analysis of 190 studies (18,573 participants) established that native English speakers read nonfiction at an average of 238 words per minute. L2 English readers routinely fall to 100–150 wpm. Hirai (1999) found that Japanese university students — with six years of formal English education — read English below 100 wpm.

The gap is not marginal. It is a 40–60% reduction in processing speed.

A feed's experience is not built post by post. It is built in the scroll. The rhythm of scanning, pausing, moving on. When an English post appears in a Japanese user's feed, that rhythm breaks. The cognitive cost is not "I cannot read this." The cost is: "This slowed me down enough to break the flow." One post in a foreign language is a speed bump. Five posts are a wall.

Alex Benzer announced in Bluesky's 2026 roadmap that a dedicated team is being assembled to manage the Discover feed. Topic tags are being explored. This is the specification request for that team: Discover must be localized by language community. Not translated. Localized.

Diffusion Structure Is Cultural

Feed localization is not only about language filtering. The way information spreads differs across language communities.

An informal diffusion experiment in the Japanese Bluesky community revealed a pattern: conversational posts — replies, opinions, context-dependent statements — circulate within closed clusters. They propagate through a small number of hubs but remain within the social graph of mutual recognition. Participants in a six-step reply chain could still identify who had forwarded the post to them.

Contrast this with content-only posts — animal photos, news links, utility information. These spread across cluster boundaries without friction. They require no context. They carry no identity. They survive decontextualization.

Two diffusion structures coexist on the same platform. One is closed, context-preserving, and conversation-sustaining. The other is open, context-free, and engagement-optimized.

The English-language For You feed optimizes for the second structure. Engagement signals — likes, reposts, reply counts — favor content that survives decontextualization. This is not wrong for English-language culture, where public discourse norms tolerate wider broadcast. But Japanese-language culture on Bluesky has developed around the first structure. The closed cluster is not a limitation. It is the feature. Psychological safety comes from knowing who sees your posts. The platform's value, for Japanese users, is that it does not behave like X.

A For You algorithm tuned on English engagement patterns, applied to Japanese-language content, does not merely fail to help. It actively degrades the experience it is meant to serve.

Feed generators need cultural parameters. Not just language filters, but variables that reflect how a community actually uses the platform: the weight of follow-graph proximity, the threshold for cross-cluster promotion, the role of reply context in ranking. These are not linguistic variables. They are cultural ones.

The Missing Showcase

ATProto's ecosystem is visible — in English.

Boris Mann's "Beyond Microblogging" talk (2025) mapped the landscape: Tangled, Smoke Signal, Grain, Streamplace, WhiteWind, Leaflet, Roomy. TechCrunch published "Beyond Bluesky" (June 2025), listing consumer-facing ATProto apps. Mike Masnick's Techdirt essay (January 2026) called ATProto "the enshittification killswitch" and catalogued dozens of projects. The ATProto team supported npmx.dev with a $6,000 grant after 123 contributors built an npm browser with ATProto social features in 40 days.

In Japanese, the picture is sparse. Individual developers have written API tutorials on platforms like Zenn and Qiita. A few bloggers have mentioned ATProto apps in passing. But no equivalent of Boris Mann's ecosystem tour, TechCrunch's consumer app roundup, or Masnick's manifesto exists in Japanese. No comprehensive, non-developer-accessible showcase of what the protocol makes possible beyond microblogging. No introduction to atmospheric websites or custom Lexicons written for a Japanese-speaking audience that is not already technical.

This is not a translation problem. The English showcase articles are not waiting to be translated. The Japanese ecosystem has its own shape — WhiteWind was built by a Japanese developer, TOKIMEKI is a Japanese third-party client, the Japanese Bluesky community has a mature feed culture that predates most English-language feed experimentation. A Japanese showcase would look different from an English one because the ecosystem is different.

The absence matters for the "show, then ask" strategy. PBC's grant pattern — demonstrated by the npmx case — is reactive, not proactive. They do not fund proposals. They fund momentum. "We saw it happen — fast, in public, with real engineering rigor — and we wanted to back it." To trigger that pattern from a non-English community, the work must be visible. Visibility requires a showcase. The showcase does not exist.

There is a harder version of this problem. Japanese developers have built and maintained custom feeds, tools, and community infrastructure on their own time and their own money. Some have shut down useful services when the cost became unsustainable. The grant mechanism that funded npmx was never accessible to them — not because they lacked engineering rigor, but because the process, the communication, and the visibility all operate in English. A Japanese developer running a popular custom feed out of pocket does not know how to reach PBC's grant pipeline, and PBC does not know the developer exists. The language barrier is not just a user experience problem. It is a funding pipeline problem.

Five Concrete Asks

These are specification requests, addressed to the Bluesky team assembling the Discover feed team, and to the ATProto engineers working on feed infrastructure.

1. Fix langs inference reliability.

The language mismatch warning exists but fires intermittently. Make it deterministic. Either run server-side language detection on every post and reject metadata mismatches, or force a confirmation step in every client when the detected language differs from the langs field. Intermittent detection is worse than no detection. Choose one: always detect, or always confirm. The current middle ground is the worst option.

2. Localize the Discover experience by language community.

Tie feed recommendations, topic tags, and Starter Pack suggestions to the user's interface language setting. A Japanese-language user must see Japanese custom feeds in Discover. Not English feeds with Japanese labels. Japanese feeds, built by Japanese feed creators, surfaced by default. The onboarding experience for the second-largest language community should not require the user to already know what they are looking for.

3. Expose cultural parameters in the Feed Generator API.

Give feed generators access to variables beyond content signals: follow-graph proximity weight, cross-cluster promotion threshold, reply-context depth, language-community clustering. Let feed builders tune for cultural patterns, not just engagement metrics. The Japanese community's closed-cluster diffusion pattern is a feature, not a bug. Feed generators need the tools to preserve it.

4. Fund Localization Engineers, not just Country Managers.

Translation and experience design are different skills. A Country Manager manages relationships. A Localization Engineer designs experiences. The langs metadata problem, the Discover feed failure, the cultural parameter gap — these are engineering problems, not communication problems. PBC should fund technical localization roles in major non-English language communities. The position does not need to be inside PBC. It needs PBC's budget.

5. Make the grant pipeline accessible across languages.

PBC's ecosystem support works — for English-speaking developers who are visible to PBC. Non-English developers building critical community infrastructure cannot access the same pipeline. The fix is not complicated: accept grant applications in multiple languages, actively scout non-English ecosystems for projects worth funding, and publish grant criteria in the languages of the communities PBC wants to support. If the second-largest language community on the platform cannot reach the funding mechanism, the mechanism is broken.

Show, Then Ask

This article is a specification, not a grievance. We want ATProto to succeed in every language, and that requires honest reporting from the communities living with its current gaps.

The Japanese Bluesky community already has what most non-English communities lack: a mature third-party client culture, widespread custom feed adoption, and community-driven moderation practices. The infrastructure for experience localization exists in practice. It lacks protocol-level support.

The npmx pattern applies. Build in public. Demonstrate engineering rigor. Make the work visible. PBC's grant mechanism responds to momentum, not proposals. The Japanese community has been building. Now we are telling you what we need to build better.

ATProto's promise is not "English-first, others later." It is "anyone, anywhere." The five asks above are what "anywhere" actually requires.

This article addresses questions shared with the ATmosphereConf 2026 panel “How to have more non-English speaking users” and the talk “Blousques: Case Study on the Challenges in Translating Bluesky’s UI.”