Skip to content

feat(views): localize generated-view chrome via the manifest anchor language#169

Merged
takashi-matsuyama merged 3 commits into
mainfrom
feat/view-i18n
Jul 13, 2026
Merged

feat(views): localize generated-view chrome via the manifest anchor language#169
takashi-matsuyama merged 3 commits into
mainfrom
feat/view-i18n

Conversation

@takashi-matsuyama

Copy link
Copy Markdown
Member

Summary

The generated views (handoff.md / orientation.md / decisions.md / basou report generate) hardcoded Japanese section headings and verdict prose — contradicting the English-first OSS positioning (the mismatch surfaced concretely while drafting the English tutorial that walks readers through basou handoff generate). This PR localizes the tool-generated chrome per workspace, driven by the manifest declaration:

The workspace speaks the anchor's language. The view language resolves from the repos[] entry whose path is .:

  • anchor language: ja → Japanese chrome (byte-identical to the previous output)
  • en / en+ja / undeclared / no roster → English (the new default; en+ja renders one chrome and English is the shared floor)

User data (decision titles, notes, labels, file paths) always passes through verbatim. There is deliberately no env-var or CLI-flag override: handoff.md / decisions.md are committed team artifacts, so their language is a project declaration, not a caller preference.

Changes

  • New packages/core/src/lib/view-strings.ts — the single locale table (ViewLanguage, viewStrings(), resolveViewLanguage(), tolerant resolveViewLanguageFromPaths()), exported from @basou/core.
  • All four renderers now select strings from the table and resolve the language themselves (mirroring the orientation renderer's tolerant source_roots manifest read), with an optional language input override for tests/programmatic callers — every call site (CLI commands, SDK, view server, codex context channel) follows automatically with zero wiring.
  • E-5 allowlist (scripts/check-language.mjs) shrinks from the four renderer files to the one strings module; renderer sources are now English-only, structurally separating "user data language" from "tool chrome language".
  • Tests: renderer tests now assert the English default; new manifest-driven ja tests per renderer (incl. en+ja → en and the explicit-override seam); new view-strings.test.ts unit-tests the resolution rules.
  • Docs: docs/spec/generated-markdown.md gains §10.0 (view-language rule) and the templates now show the real English chrome. CHANGELOG documents the default flip under Unreleased.

Behavior change

Rendered prose only (explicitly outside the compatibility.md freeze): a workspace with no declared anchor language previously rendered Japanese headings and now renders English. Keeping Japanese = declare language: ja on the anchor entry.

Verification

  • pnpm typecheck / pnpm build / pnpm lint / pnpm lint:lang green
  • core 1324 / cli 984 / sdk 18 tests green
  • Live: basou refresh against a language: ja fleet workspace keeps the exact Japanese chrome (headings byte-identical); a fresh basou init workspace renders the English chrome end-to-end (incl. the codex channel carrying the localized orientation body)

🤖 Generated with Claude Code

…anguage

The generated views (handoff.md / orientation.md / decisions.md / report)
hardcoded Japanese section headings and verdict prose, contradicting the
English-first OSS surface. The chrome is now localized per workspace: the
view language follows the manifest anchor repo's declared `language`
("the workspace speaks the anchor's language").

- New single locale table `@basou/core` `lib/view-strings.ts` with
  `ViewLanguage`, `viewStrings()`, `resolveViewLanguage()` (anchor
  `path: "."`; `ja` -> ja, `en`/`en+ja`/undeclared/no roster -> en) and a
  tolerant `resolveViewLanguageFromPaths()` (missing manifest -> en).
- All four renderers resolve the language themselves (mirroring the
  orientation renderer's tolerant source_roots read), with an optional
  `language` input override for tests/programmatic callers. Every call
  site (CLI, SDK, view server, codex channel) follows automatically.
- The ja table is byte-identical to the previous renderer output, so a
  workspace declaring `language: ja` renders exactly what it did before.
  No env-var or CLI-flag override: committed team artifacts speak the
  project's declared language, not the caller's.
- E-5 language-lint allowlist shrinks from the four renderers to the one
  strings module; renderer sources are now English-only.
- docs: generated-markdown.md section 10.0 documents the view-language rule and
  the templates now show the real English chrome.

BREAKING-ish (rendered prose only, outside the compat contract): a
workspace with no declared anchor language now renders English headings.
takashi-matsuyama and others added 2 commits July 13, 2026 19:32
These suites passed locally against a stale core dist (built before the
i18n change) and only failed once CI rebuilt: the SDK report test and the
CLI orient/decisions/report tests still asserted the Japanese chrome.
Align them with the English default. Task-description fixtures and preset
output assertions keep their Japanese: that is user data / a declared-
language surface, not view chrome.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
… text)

- A1: rename the planned-tasks loop variable that shadowed the strings table
- A2: add a full-body golden test locking the ja orientation chrome bytes
- A3: correct the check-language allowlist rationale for preset.ts (it is
  unconditionally Japanese today, not tied to the declared language)
- A4: update test names and comments to reference the en chrome now rendered
  by default (deliberate ja view-language assertions untouched)
- A5: document the silent English fallback for a missing/unreadable manifest

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@takashi-matsuyama
takashi-matsuyama merged commit d0be4e2 into main Jul 13, 2026
7 checks passed
@takashi-matsuyama
takashi-matsuyama deleted the feat/view-i18n branch July 13, 2026 14:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant