Switch terminonology from "handle" to "username" #65

Closed
opened 2026-07-29 17:21:13 +00:00 by Grandiras · 2 comments
Owner

Also open an issue on ATProto.NET. We want to canonicalize this.

Also open an issue on ATProto.NET. We want to canonicalize this.
Collaborator

🤖 On it — follow along in the action run; the reply will link the full session transcript.

📜 Live transcript — updating every ~5 minutes while the task runs.

🤖 On it — follow along in [the action run](https://git.grandiras.net/Grandiras/claude-bot/actions/runs/161); the reply will link the full session transcript. 📜 [Live transcript](https://git.grandiras.net/Grandiras/claude-bot/src/branch/claude-logs/transcripts/Grandiras/Ponente/issue-65/run-161.md) — updating every ~5 minutes while the task runs.
Collaborator

Pushed. Here's the summary.

Switched every string a member reads from handle to username (German: Benutzername), and left the protocol's word everywhere it isn't copy. Branch: claude/issue-65.

The split I drew, mirroring the app's existing Atmosphere / AT Protocol convention one layer down: "handle" is a word the protocol taught, and the field it names is the one every other site calls a username — a first-time visitor has to learn our vocabulary before the sign-in form makes sense, and learns nothing usable once they have. So the copy changes and nothing under it does. Member.Handle, HandleResolver, HandleExamples, the handle form field and query string, the #atproto-handle / #signup-handle / #request-handle ids and the SDK's HandleLabel parameter all keep the protocol's word — renaming them would put a second name on the wire and break step with ATProtoNet for nothing.

What changed

  • LocaleService — every affected string in both locales: sign-in (label, intro, hint, all three error messages, subtitle), signup (label, missing-field and taken/invalid errors), /request (label + hint), the existing-account note, admin members (add, placeholder, table column, lookup errors) and the admin request-resolution error.
  • Translation keys follow the copy — login.username.hint, signup.error.username.taken, admin.members.username and the rest — because a key is read beside the string it names. All Razor call sites updated; I verified by extraction that every literal L.T key in the tree still resolves against the table.
  • Mailer — the admin notification's Handle: column is now Username: (padding kept in step with the other labels).
  • README.md for the two sentences describing what a person types; the PDS/DNS sections keep PDS_HANDLE_DOMAIN and "handle domain" as configuration and protocol names.
  • CLAUDE.md records the rule and the boundary, so the next change knows which side it's on.

A guard against drift, since the issue asks to canonicalize: TranslationTests.No_copy_calls_an_account_name_a_handle fails the build on \bhandles?\b in any translation in either locale. The word boundaries are load-bearing — they keep English "unhandled" and German "Behandle" (in cal.subscribe.secret) out of it.

Upstream: filed as ATProto.NET#80, the counterpart to #32. LoginForm 0.5.0 still defaults to the label "Handle" and the hint "Your Atmosphere account handle" — which is why Login.razor passes HandleLabel at all. The issue asks for the defaults only and explicitly rules out renaming HandleLabel, the handle query parameter or anything else on the wire.

Verified: dotnet build Ponente.sln clean (one pre-existing nullability warning in Calendar.razor, untouched) and dotnet test Ponente.sln green at 154/154 — including en/de key parity, which is what proves the key renames landed in both locales. I also confirmed the new guard actually bites by temporarily setting the login label back to "Handle" and watching it fail with Copy still says "handle": en/login.username.label, then reverting. I could not run the Playwright suite: this CI container has no podman or docker, so there's no stack to test against. The only e2e change needed was i18n.spec.js's German sign-in error assertion (now "Das sieht nicht nach einem Benutzernamen aus"); I grepped the rest of tests/e2e/ and no other spec asserts on this copy — the ids and class names they use (#request-handle, .board-user-handle) are deliberately unchanged.

One follow-up I couldn't do here: the Lunacy canvas still shows "Handle" on the Login and Admin → Members frames, and the MCP tools aren't available in CI.


⏱ 8m 33s · 96 turns · tokens: 119.1k in / 32.8k out (+6396.4k cache-read)
📜 Full session transcript
→ Opened PR: #66

Pushed. Here's the summary. Switched every string a member reads from **handle** to **username** (German: *Benutzername*), and left the protocol's word everywhere it isn't copy. Branch: **`claude/issue-65`**. **The split I drew**, mirroring the app's existing Atmosphere / AT Protocol convention one layer down: "handle" is a word the protocol taught, and the field it names is the one every other site calls a username — a first-time visitor has to learn our vocabulary before the sign-in form makes sense, and learns nothing usable once they have. So the copy changes and nothing under it does. `Member.Handle`, `HandleResolver`, `HandleExamples`, the `handle` form field and query string, the `#atproto-handle` / `#signup-handle` / `#request-handle` ids and the SDK's `HandleLabel` parameter all keep the protocol's word — renaming them would put a second name on the wire and break step with `ATProtoNet` for nothing. **What changed** - `LocaleService` — every affected string in **both** locales: sign-in (label, intro, hint, all three error messages, subtitle), signup (label, missing-field and taken/invalid errors), `/request` (label + hint), the existing-account note, admin members (add, placeholder, table column, lookup errors) and the admin request-resolution error. - Translation **keys** follow the copy — `login.username.hint`, `signup.error.username.taken`, `admin.members.username` and the rest — because a key is read beside the string it names. All Razor call sites updated; I verified by extraction that every literal `L.T` key in the tree still resolves against the table. - `Mailer` — the admin notification's `Handle:` column is now `Username:` (padding kept in step with the other labels). - `README.md` for the two sentences describing what a person types; the PDS/DNS sections keep `PDS_HANDLE_DOMAIN` and "handle domain" as configuration and protocol names. - `CLAUDE.md` records the rule and the boundary, so the next change knows which side it's on. **A guard against drift**, since the issue asks to canonicalize: `TranslationTests.No_copy_calls_an_account_name_a_handle` fails the build on `\bhandles?\b` in any translation in either locale. The word boundaries are load-bearing — they keep English "unhandled" and German "Behandle" (in `cal.subscribe.secret`) out of it. **Upstream**: filed as [ATProto.NET#80](https://git.grandiras.net/Grandiras/ATProto.NET/issues/80), the counterpart to #32. `LoginForm` 0.5.0 still defaults to the label "Handle" and the hint "Your Atmosphere account handle" — which is why `Login.razor` passes `HandleLabel` at all. The issue asks for the defaults only and explicitly rules out renaming `HandleLabel`, the `handle` query parameter or anything else on the wire. **Verified**: `dotnet build Ponente.sln` clean (one pre-existing nullability warning in `Calendar.razor`, untouched) and `dotnet test Ponente.sln` green at 154/154 — including en/de key parity, which is what proves the key renames landed in both locales. I also confirmed the new guard actually bites by temporarily setting the login label back to "Handle" and watching it fail with `Copy still says "handle": en/login.username.label`, then reverting. I could **not** run the Playwright suite: this CI container has no podman or docker, so there's no stack to test against. The only e2e change needed was `i18n.spec.js`'s German sign-in error assertion (now *"Das sieht nicht nach einem Benutzernamen aus"*); I grepped the rest of `tests/e2e/` and no other spec asserts on this copy — the ids and class names they use (`#request-handle`, `.board-user-handle`) are deliberately unchanged. One follow-up I couldn't do here: the Lunacy canvas still shows "Handle" on the Login and Admin → Members frames, and the MCP tools aren't available in CI. --- ⏱ 8m 33s · 96 turns · tokens: 119.1k in / 32.8k out (+6396.4k cache-read) 📜 [Full session transcript](https://git.grandiras.net/Grandiras/claude-bot/src/branch/claude-logs/transcripts/Grandiras/Ponente/issue-65/run-161.md) → Opened PR: https://git.grandiras.net/Grandiras/Ponente/pulls/66
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Grandiras/Ponente#65
No description provided.