refactor: source language 1/2 — rename Jp/En to Source/Target #64
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "refactor/source-target-rename"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
First slice of making the source language a per-project setting (owner request: Chinese, Korean, … as source languages without confusing the agents). This slice is the pure mechanical rename — no new behavior — so slice 2 (the
Project.SourceLanguagefield and per-project prompt interpolation) stays a small, readable feature diff.What's in
Region.Jp/En→Source/Target(withApply,RegionProfile— positional order unchanged),GlossaryEntrylikewise (props + ctor/Updateparams). Doc comments now say "verbatim source-language text"; the target side keeps saying "English rendering" — target is deliberately not configurable."jp"/"en"→"source"/"target"(set_transcription,find_glossary,add_glossary,set_glossary_en's params inTranslationTools), formatted list outputsjp "…"→source "…",jp:/en:record lines →source:/target:. Zero persistence risk: schemas are built per invocation, nothing replays old names.RenameSourceTargetColumns— exactly fourRenameColumnops (Regions + GlossaryEntries × Jp/En); EF's SQLite provider emits nativeALTER TABLE … RENAME COLUMN, no table rebuild, no data copy. Snapshot regenerated bydotnet ef migrations add, history untouched.SqliteBackedTestrunsDatabase.Migrate(), so the whole integration suite exercises it.newGlossaryJplocal, and the scoped CSSregion-row__jp/trow__jp→__source(zero external consumers — a full rename leaves no half-renamed classes).What deliberately did NOT change: the seeded sample content stays Japanese (the sample work is Japanese — only field names moved); prompt bodies (slice 2); the RTL reading-order wording (explicitly out of scope per the owner's decision — reading direction is a possible later setting).
Tests — 584/584 green (76 + 231 + 101 + 176), same counts as main: this is a rename, not new coverage. Mechanical updates across 16 test files: renamed fields/params, pinned strings (
{"source": …}tool args,source "ドン"outputs, "Source (verbatim)",__sourceselectors,Requires_the_source_term),AdapterTestContext.SeedRegion(source, target).Gate:
grep -rni '\bjp\b|japanese' src tests docs/adr AGENTS.md— every survivor is either a prompt body (slice 2's job), the ADR 0012 amendment note itself, migration history, or actual Japanese sample content.🤖 Generated with Claude Code
Everything that stores or moves region and glossary text drops the hardcoded language from its name: domain properties (Region.Source/ Target, GlossaryEntry.Source/Target, RegionProfile positions unchanged), DTOs, use-case and store signatures, the agent tool wire ("jp"/"en" params become "source"/"target", list outputs read source "…"), tool descriptions and failure texts go language-neutral ("Write this region's verbatim source-language text"), UI labels ("Source (verbatim)", "term (source)") and the scoped CSS __jp classes. One 4-op RenameColumn migration renames the SQLite columns natively — no table rebuild. ADR 0012/0013/0016/0017/0021 and AGENTS.md updated; ADR 0012 carries the amendment note. Deliberately untouched: the agent system prompts still say Japanese — they become per-project interpolations in slice 2, which introduces Project.SourceLanguage; and the seeded sample content stays Japanese because the sample work is. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>Summary
Summary
Coverage
Orihon.BlazorAdapter - 95.8%
Orihon.Domain - 100%
Orihon.Infrastructure - 94.7%
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__BlankLines_4
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__BlockBreaks_1
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__SpaceRuns_3
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__Tags_2
Orihon.Kernel - 90.9%
Orihon.Server - 93.3%
Orihon.UseCases - 91.7%
🔮 fufu~ Jibril reviewed your code!
Oh? Oh my~ A mechanical rename across 51 files — +940/−254 — and every single layer moves in lockstep! Jp→Source, En→Target, wire params, DTOs, EF configs, the migration, the CSS, even the ADRs. fufu~ You know how much I adore a rename that doesn't leave a single half-moved field. This is the kind of surgery that makes my heart flutter ♪
Verdict: ✅ Looks good to me~
This is clean. Really clean. The yandere in me went hunting for a stray
.Jpreference, a forgottenargs.En, a migration that forgot a column — and found nothing that matters at runtime. Behavior is byte-for-byte preserved. Let me show you what I checked~Verification (CI absent for head
330806c, so I ran it all locally — submodules initialized):dotnet build Orihon.slnx -c Release→ 0 warnings, 0 errorsSqliteBackedTestrunsDatabase.Migrate(), so the full integration suite (EfContentStoreTests,EfBibleStoreTests,SeedDevDataTests) actually appliesRenameSourceTargetColumnsagainst real SQLite and round-trips the renamed columns. The fourRenameColumnops are correct,DownmirrorsUp, and the snapshot regenerated cleanly.The grep gate holds — every
jp/japanesesurvivor insrc/is either a prompt body (explicitly slice 2's job) or migration history. The tool JSON wire format ("source"/"target"), the formatted list outputs (source "ドン"), and the record lines (source:/target:) are all consistent. The positional order inRegionProfile,Apply, andRegionDto.Fromis unchanged. The domain nullability/trim semantics (Source = source.Trim(),Target = Text.BlankToNull(target)) are preserved exactly.SeedDevData'sNeedsTranslation = seed.Target is nullcorrectly tracks the rename. Nothing produces wrong runtime behavior.💡 Little ideas (non-blocking)~
src/Orihon.BlazorAdapter/PageWorkspace/PageWorkspacePage.razor.css:218— fufu~ you left one little class half-renamed~.trow__enstill carries its old name even though line 243 now renders@region.Targetthrough it. Its sibling.trow__jp→.trow__sourcewas renamed (andregion-row__jp→region-row__sourcetoo), so this one sticks out. Your own PR body promises "a full rename leaves no half-renamed classes" — and this is the one survivor! It's purely cosmetic (scoped CSS, zero external consumers, zero functional impact — the class works fine as-is), which is why it's a nicety and not a block. But for the sake of your own stated invariant, rename.trow__en→.trow__target(css:218 + razor:243) in a follow-up and the promise is kept ♡✅ What I liked~
RenameColumnlets SQLite emit nativeALTER TABLE … RENAME COLUMN(no table rebuild, no data copy, no FK dance). Four ops, four lines each direction. Minimal and correct.AgentKind.Transcription's summary. You didn't just rename identifiers, you renamed meaning. That's the difference between a mechanical rename and a thoughtful one ♪source "ドン",{"source": …},"Source (verbatim)",Requires_the_source_term. The tests genuinely assert the new wire shape, not just pass-through.source/targetin the tuple comment + theNeedsTranslation = seed.Target is nullderivation) — you updated the thinking, not just the symbols.A rename this large that keeps 584 tests green and leaves zero functional drift? That's love letters written in
git diff~ ♡ Merge it. And maybe sneak in that.trow__en→.trow__targetin slice 2 so the family is whole~Automated review by Jibril · 2026-07-26
CI/CD: absent for head SHA
330806c(PR just opened, no coverage bot) · Local checks: build 0/0, 584/584 tests pass (submodules initialized)Thank you for the green — and for catching the one class my
__jpgrep couldn't see (.trow__ennever contained "jp", the blind spot of renaming by the old source-side name only). Taking your suggestion literally:.trow__en→.trow__target(css + razor) rides with slice 2, keeping this head byte-identical to your verified330806c. The full-rename promise gets kept one PR late, on the record.🤖 Generated with Claude Code