6.3 KiB
Requirements Document
Introduction
This specification covers the developer-facing internationalization of backend/ Python source: translating Chinese docstrings and inline comments to English so that English-speaking maintainers can read and review the code without translation overhead. The change is mechanical — no behavior, no public strings, no symbol names are modified. It is one of several i18n tickets (#2, #3, #4, #5, #6, #7); this spec covers ticket #7 only.
Boundary Context
- In scope: Translation of Chinese-language characters that appear in Python docstrings (module/class/function) and inline
#comments underbackend/. Removal of comments that merely restate the code. Preservation ofTODO:/FIXME:markers and embedded ticket references. - Out of scope: Chinese characters inside string literals (prompt templates,
logger.{info,warning,error}arguments, API response bodies, error messages returned to clients) — these are tracked separately by issues #2/#3/#4/#5/#6. No refactoring, reformatting, renaming, or behavior changes. - Adjacent expectations: Spec
i18n-externalize-backend-logs(issue #6) and the prompt-translation specs handle string-literal Chinese; this spec must leave those untouched so the other tickets remain mergeable.
Requirements
Requirement 1: Translation Coverage of In-Scope Files
Objective: As a maintainer, I want every Chinese docstring and inline comment in the in-scope backend files translated to English, so that I can read and review the code without translation tools.
Acceptance Criteria
- The Backend Codebase shall contain no Chinese characters (Unicode range U+4E00–U+9FFF) inside Python docstrings under
backend/app/__init__.py,backend/app/config.py,backend/app/models/,backend/app/services/,backend/app/api/,backend/app/utils/,backend/run.py, andbackend/scripts/. - The Backend Codebase shall contain no Chinese characters inside Python
#inline comments under the same paths. - When
grep -rln '[一-鿿]' backend/ --include='*.py'is run after this change, the Backend Codebase shall return only files whose remaining Chinese is contained within string literals owned by issues #2/#3/#4/#5/#6. - When a docstring is translated, the Translator shall preserve Google-style docstring shape (
Args:,Returns:,Raises:,Yields:sections) perdev-guidelines.md.
Requirement 2: Preservation of Code Behavior
Objective: As a maintainer, I want the translation to be comments-and-docstrings-only, so that runtime behavior is provably unchanged.
Acceptance Criteria
- The Translator shall not modify any executable Python statement (assignments, function calls, control flow, decorators, imports).
- The Translator shall not modify any Python string literal (single-, double-, triple-quoted, f-string, raw, byte) regardless of whether it contains Chinese characters.
- The Translator shall not rename any symbol (variable, function, class, module, parameter).
- When
uv run python -m pytest backend/scripts/test_profile_format.pyis run after the change, the Backend Codebase shall exit with status 0. - If a diff line touches any non-comment, non-docstring code, the Translator shall reject that diff hunk and revise.
Requirement 3: Comment Quality Hygiene
Objective: As a maintainer, I want translated comments to add value, so that the codebase remains easy to read after the migration.
Acceptance Criteria
- When a Chinese comment merely restates the immediately following code (e.g.
# 初始化客户端aboveclient = Client()), the Translator shall delete the comment rather than translate it. - When a Chinese comment captures non-obvious why (constraints, workarounds, invariants), the Translator shall translate it to a faithful English equivalent.
- The Translator shall preserve any
TODO:/FIXME:marker and any embedded ticket reference (e.g.#1234,PROJ-456) verbatim within the translated comment. - The Translator shall not introduce new comments that did not exist (or had no Chinese equivalent) in the original source.
Requirement 4: Style and Format Compliance
Objective: As a maintainer, I want the translated output to comply with project style rules, so that no follow-up cleanup PR is needed.
Acceptance Criteria
- The Translator shall keep all translated docstrings and comments at or below 120 characters per line.
- The Translator shall not introduce trailing whitespace on any line.
- The Translator shall preserve the original indentation (tabs/spaces) of every comment and docstring.
- The Translator shall use double quotes for any docstring it rewrites, matching the existing Python convention in the file.
- Where a file already uses 4-space indentation, the Translator shall preserve that indentation.
Requirement 5: Discovery and Verification Workflow
Objective: As a reviewer, I want a reproducible discovery and verification workflow, so that I can confirm coverage and absence of regressions in CI or locally.
Acceptance Criteria
- The Translator shall enumerate candidate files using
grep -rln '[一-鿿]' backend/ --include='*.py'before beginning work. - The Translator shall re-run the same
grepafter each batch and confirm the residual hits are limited to string-literal Chinese owned by adjacent tickets (#2/#3/#4/#5/#6). - When the residual
grephits include any non-string-literal Chinese, the Translator shall classify those hits as in-scope and continue translation until they are gone. - The Translator shall verify that
git diff --statonly reports changes inside the in-scope file paths listed in Requirement 1.
Requirement 6: Tracking and Branching
Objective: As a release manager, I want the work tracked against ticket #7 on a dedicated branch, so that the PR remains scoped and traceable.
Acceptance Criteria
- The Translator shall produce changes on a branch named
docs/i18n-7-translate-backend-comments. - The Translator shall reference issue
salestech-group/MiroFish#7in commit messages or PR description. - When committing, the Translator shall use Conventional Commits with type
docsand scopei18n(e.g.docs(i18n): translate chinese docstrings/comments in backend/<area>). - The Translator shall not include unrelated changes (e.g. dependency bumps, config changes, refactors) in the resulting PR.