Localize the public pages — Spanish first #47

Open
opened 2026-09-02 01:18:23 +00:00 by paulhitt · 1 comment
paulhitt commented 2026-09-02 01:18:23 +00:00 (Migrated from gitlab.com)

Ask: localize the public pages.

The case is already made by the geo-gate

Sign-up is open in the United States, Mexico, Guatemala, El Salvador, Honduras, Peru and
Bolivia
— six of those seven are Spanish-speaking. The product deliberately serves a
mostly Spanish-speaking audience and every public page is English-only, including the one
that says where it is available.

/get currently explains the geo restriction in English to people who are being told they
can sign up. That is the sharpest version of the gap.

What makes this harder than a normal translation job

⚠️ The copy is the product's voice, and it is unusually careful. Pages avoid protocol
names, refuse to overclaim, and several sentences exist because a previous wording was
wrong — "not open yet" instead of "in review", "we would rather say that than round it up",
the whole /metadata table. A translator working from strings alone will flatten exactly
the parts that took the most thought.

⚠️ Some sentences are legal-adjacent. Security claims carry FTC §5 exposure in the US;
a translation that overclaims in Spanish is the same problem in another language, and
harder for us to notice.

⚠️ /spec should NOT be translated. It is the cross-platform contract implementers
build against, it is generated from flamenet-e2e/docs/SPEC.md, and a translated copy
would drift from the original silently — which for a protocol spec is worse than being
English-only.

Shape worth considering

  1. Spanish first, and only Spanish, until it is genuinely good. Two half-done languages
    are worse than one done well.
  2. Pages in priority order: /get (people are installing), the landing page, /comparison,
    /privacy and /metadata (the promises), then the rest.
  3. Language chosen explicitly, remembered, and never guessed from the connection.
    Inferring from an address means a VPN changes somebody's language, and the geo-gate
    already reads the connection for something else — conflating the two would make a
    privacy tool feel like it is watching.
  4. A missing translation must fall back to English rather than to an empty page.

⚠️ Related but separate: the apps are English-only too. Worth its own ticket — the copy
there includes error messages, and a refusal somebody cannot read is a refusal they cannot
act on.

Related: #44 (keeping the features page simple), #45 (page accuracy sweep).

**Ask:** localize the public pages. ## The case is already made by the geo-gate Sign-up is open in the **United States, Mexico, Guatemala, El Salvador, Honduras, Peru and Bolivia** — six of those seven are Spanish-speaking. The product deliberately serves a mostly Spanish-speaking audience and every public page is English-only, including the one that says where it is available. `/get` currently explains the geo restriction in English to people who are being told they *can* sign up. That is the sharpest version of the gap. ## What makes this harder than a normal translation job ⚠️ **The copy is the product's voice, and it is unusually careful.** Pages avoid protocol names, refuse to overclaim, and several sentences exist because a previous wording was wrong — "not open yet" instead of "in review", "we would rather say that than round it up", the whole `/metadata` table. A translator working from strings alone will flatten exactly the parts that took the most thought. ⚠️ **Some sentences are legal-adjacent.** Security claims carry FTC §5 exposure in the US; a translation that overclaims in Spanish is the same problem in another language, and harder for us to notice. ⚠️ **`/spec` should NOT be translated.** It is the cross-platform contract implementers build against, it is generated from `flamenet-e2e/docs/SPEC.md`, and a translated copy would drift from the original silently — which for a protocol spec is worse than being English-only. ## Shape worth considering 1. **Spanish first**, and only Spanish, until it is genuinely good. Two half-done languages are worse than one done well. 2. Pages in priority order: `/get` (people are installing), the landing page, `/comparison`, `/privacy` and `/metadata` (the promises), then the rest. 3. **Language chosen explicitly, remembered, and never guessed from the connection.** Inferring from an address means a VPN changes somebody's language, and the geo-gate already reads the connection for something else — conflating the two would make a privacy tool feel like it is watching. 4. A missing translation must fall back to English rather than to an empty page. ⚠️ Related but separate: **the apps are English-only too.** Worth its own ticket — the copy there includes error messages, and a refusal somebody cannot read is a refusal they cannot act on. Related: #44 (keeping the features page simple), #45 (page accuracy sweep).
paulhitt commented 2026-09-02 01:19:07 +00:00 (Migrated from gitlab.com)

mentioned in issue #48

mentioned in issue #48
Sign in to join this conversation.