docs: translate Japanese comments to English#57
Merged
Conversation
This was referenced Jul 8, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Translate every in-code Japanese comment and description string to English across the whole repository, so the code language matches the already-English docs (README, SECURITY.md). Comments and config descriptions only — no logic changes.
Motivation
Closes #55.
The user-facing docs are English while in-code comments were mostly Japanese. That (a) makes intent hard to read for non-Japanese contributors and (b) duplicates the language split between docs and code, raising maintenance cognitive load. Unifying on English prepares the repo for outside contribution and OSS visibility.
Changes
core/(14 files),cli/(7),extension/(34), andeditor/(8), plusbuild.zigcomments and therenovate.jsondescriptionfields.--hiddenis passed):.gitattributes,.github/workflows/ci.yml,.github/workflows/release.yml.cli/src/mcp.zig: the "truncateTree never splits a multibyte utf-8 character" test used the intentional literal"あああ". Replaced it with"€€€"— U+20AC is also exactly 3 bytes in UTF-8, so the input byte layout and every assertion (len= 50008, cut at byte 49999) are unchanged and the test still exercises a mid-character cut. Surrounding comments now reference'€'. This keeps the repo fully CJK-free without weakening the regression test.code; // commentpair whose code portion is byte-identical between the removed and added side.While translating, I corrected one apparent typo in
.gitattributes:CSRF->CRLF. The surrounding comment is about preventing automatic line-ending conversion on Windows checkout, whereCSRF(a security term) is meaningless; the intent is clearlyCRLF. Flagging it explicitly since this issue is scoped to translation.Testing
Reproduced the CI matrix locally — all green:
rg --hidden '[\x{3040}-\x{309F}\x{30A0}-\x{30FF}\x{4E00}-\x{9FFF}\x{3000}-\x{303F}\x{FF00}-\x{FFEF}]'-> 0 hitszig build lint,zig build test,zig build perf-> all pass (perf: 50000 objects in 174 ms, ceiling 600 ms)zig build wasm,node --test core/tests/*.test.mjs(7 pass),npm run size|lint|typecheck|test|build-> all pass (vitest 142 pass, 13 files)dotnet csharpier check . --no-msbuild-check-> pass (8 files)Follow-up candidates (out of scope here — translation only, not fixed):
cli/src/main.zig:494— staleTask 9reference (was already English).editor/Editor/Cli.cs:131— comment ties the absence ofSHA256SUMSto "a release before v0.2.0"; worth verifying against the actual release history.