Skip to content

wiki: 全站中文化,并在 frontmatter 中声明 lang - #1482

Merged
justinchuby merged 1 commit into
mainfrom
justinchuby-wiki-chinese
Aug 19, 2026
Merged

justinchuby merged 1 commit into
mainfrom
justinchuby-wiki-chinese

Conversation

@justinchuby

Copy link
Copy Markdown
Owner

把整个 wiki 翻译成简体中文,并给每一页加上 lang frontmatter 字段。

规则

wiki/README.md 新增「语言」章节,把规则写死:

译为中文:正文、章节标题(H2 及以下)、表格内容、callout 标题文字、列表项。

保持英文:文件名、frontmatter title、页面 H1、tags、[[wikilink]] 的目标、代码块与标识符、crate 名、路径、环境变量、Obsidian callout 类型关键字。

标题保持英文是为了让链接和跨语言导航保持稳定 —— 需要中文显示时用 [[目标|显示文本]],竖线左边不动。

lang 是真的会生效的

不是装饰性字段。Quartz 在 renderPage.tsx 里读 frontmatter?.lang 直接填进 <html lang>;缺失时回落到 quartz.config.yaml 的 locale。

因此本 PR 同时把 locale 从 en-US 改为 zh-CN,让 Quartz 生成的页面(标签页、目录页、404)和它自身的界面文案(搜索、目录、最后更新)也跟随内容语言,而不是回落到英文。

顺带修正的三处不一致

  1. 三个早先就用中文写的页面,H1 是中文而 title 是英文,两者不一致。H1 已改回英文,中文名保留在 aliases 里,检索入口不丢。
  2. meta/Using this Wiki.md 里的笔记模板正文仍是英文。模板是作者真正复制的东西 —— 只改规则散文而不改模板,新笔记会一路默认回英文。已一并翻译。
  3. index.md 里的 (中文) 标注已移除。它原本用来标记「这页是例外」,而中文现在是常规。

验证

  • 仓库自带的 validate_wikilinks.py:145 条链接 / 25 篇,与翻译前完全一致 —— 零链接漂移。翻译前先建立了基线数字再对比,而不是只看翻译后能不能通过。
  • 完整 npm run wiki:build 成功,validate_site.py 校验 4159 条内部链接 / 146 个 HTML 页。
  • 逐页机械比对 HEAD:wikilink 目标、frontmatter、H1、代码块字节相同、数字集合相同、callout/标题/表格行/列表项计数相同。
  • 构建产物里实际抓 <html lang> 确认:25 篇笔记全部是 zh-CN,而不是只读源码推断。

已知限制

51 个 alias 重定向存根仍然是 lang="en-us"。这个值硬编码在 alias-redirects 插件受 lockfile 校验保护的构建产物里,改它会破坏 quartz_plugins.py verify,且下次 plugin install 就被覆盖。这些页面带 robots: noindex、refresh 立即跳转、不渲染任何内容,不值得为此破坏插件锁定校验。

如实记录,而不是宣称覆盖率 100%。

Every wiki note now carries `lang: zh-CN`, which Quartz reads in
renderPage.tsx and emits as the published page's `<html lang>`. The site
locale moves from en-US to zh-CN so generated pages (tag, folder, 404)
and Quartz's own UI strings follow the content language instead of
falling back to English.

Body prose, section headings, tables, callout titles and list items are
Simplified Chinese. Filenames, frontmatter `title`, H1 headings, tags,
wikilink targets, code blocks and identifiers stay English so links and
cross-language navigation remain stable.

wiki/README.md gains a "语言" section stating the rule, and the note
template in meta/Using this Wiki.md is updated to match so new notes
start out following it. The three pages already written in Chinese had
Chinese H1 headings that disagreed with their English `title`; those H1s
are now English and the Chinese names are kept as aliases. The "(中文)"
annotations in index.md are removed, since they marked an exception that
is now the rule.

Verified: the repo wikilink validator reports 145 links across 25 notes,
unchanged from before the translation; a full `npm run wiki:build`
succeeds and validate_site.py checks 4159 internal links across 146
pages. All 25 note pages emit lang="zh-CN".

Known limitation: 51 alias redirect stubs still emit lang="en-us",
hardcoded in the alias-redirects plugin's locked build output. They are
noindex'd instant-refresh stubs that render no content, and patching
them would break plugin lockfile verification.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: c80f8522-983c-47f7-8241-2155a823aabe
@justinchuby
justinchuby merged commit 0782ab1 into main Aug 19, 2026
3 checks passed
@justinchuby
justinchuby deleted the justinchuby-wiki-chinese branch August 19, 2026 17:04
justinchuby added a commit that referenced this pull request Aug 19, 2026
## Why

CI's Rust quality lane (`cargo fmt --all -- --check`) runs on Linux and
is fine.
The **local** gate that is supposed to catch rustfmt drift *before* it
lands is
non-functional on Windows — which is where this repo's agent workflow
runs, from
git worktrees. The quality lane on `main` has been repaired for rustfmt
drift
four times (#1260, #1320, #1393, #1400). *That the broken local gate is
the cause
of those four repairs is a plausible inference, not something I measured
— I only
verified that the local gate does not work.* This PR makes the local
gate
runnable on Windows. It does **not** claim to prevent future drift.

## Defects (each verified on this Windows box)

Environment: `rustfmt 1.9.0-stable`, `cargo 1.97.1`, Git-for-Windows
bash 5.3,
`git config core.autocrlf = true`, workspace = **54 members / 972
tracked `.rs`
files**, mixed-edition (**52 on edition 2024, 2 on 2021**).

1. **Shell scripts check out as CRLF.** `.gitattributes` only pinned
`schema/inference_metadata.schema.json`; `*.sh` and the extension-less
`scripts/hooks/*` were unprotected, so all 14 tracked `.sh` files + the
hook
   showed `w/crlf`. Running one under bash printed
   `scripts/install-hooks.sh: line 10: $'\r': command not found` and
   `set: pipefail: invalid option name` — unrunnable.

2. **`install-hooks.sh` cannot work in a worktree.** It used
`HOOKS_DST="$REPO_ROOT/.git/hooks"` and bailed if that dir was missing.
In a
worktree `.git` is a **file**, so it always errored "are you in a git
repo?".

3. **`cargo fmt --all` fails on Windows regardless.** `cargo fmt --all
-- --check`
exits **1** with `The filename or extension is too long. (os error
206)`:
cargo-fmt passes every path to one `rustfmt`, overflowing the Windows
~32 KB
   command-line limit. Linux CI is unaffected (`ARG_MAX` ~2 MB). The old
   `pre-commit` ran this with **`2>/dev/null`** and then told the user
   `Fix: cargo fmt --all` — a command that also fails with os error 206.
   *(This fails loudly with exit 1 — there is no false-green here.)*

4. **No hook was installed** in this checkout — a consequence of 1+2.

**Mixed-edition trap (why the fix uses `cargo fmt -p`, not raw
`rustfmt`):** with
the wrong edition, `rustfmt` mis-parses 2024-only syntax (e.g. `let`
chains:
`error: let chains are only allowed in Rust 2024 or later`) **and
fails**. Only
cargo knows each package's declared edition, so driving the check per
package is
the only correct approach. *(An earlier claim of a silent exit-0 false
green was
traced to a measurement artifact — `rustfmt … | Select-Object -First N`
truncates
the pipeline and drops the native exit code — and has been withdrawn;
the failure
is exit 1.)*

## Changes

- **`.gitattributes`** — pin `*.sh` and `scripts/hooks/*` to `eol=lf`
(comment
explains a CRLF bash script is unexecutable) and renormalize. All 15
files now
  report `i/lf w/lf attr/text eol=lf`.
- **`scripts/install-hooks.sh`** — resolve the hooks dir via
`git rev-parse --git-common-dir` (the shared gitdir used by the main
checkout
and every linked worktree), resolving a relative result to absolute.
Keeps
  `--dry` and the "does not clobber foreign hooks" property.
- **`scripts/hooks/pre-commit`** — map the staged `.rs` files to their
owning
workspace packages and run `cargo fmt -p <pkg> -- --check` only for
those.
  Now **mirrors CI's scope exactly**:
  - Files whose crate is **not a workspace member** (e.g. the root-level
`bench-*` crates) are **skipped with a warning**, because `cargo fmt
--all`
does not cover them either. Blocking on a non-member would recreate the
os-error-206 failure shape (`cargo fmt -p <non-member>` → "not a member
of
the workspace") and wall people off behind drift they never introduced.
    Membership is taken from `cargo metadata --no-deps` (matched on
`manifest_path`, which is unambiguous — bare `"name"` keys also appear
on
    every dependency).
- If `cargo metadata` itself fails, the hook **fails open** (warns, lets
the
    commit through) — a format gate must not lock you out of the repo.
- Stops suppressing stderr; the printed fix is `cargo fmt -p <pkg>`
(works on
    Windows).
- **`wiki/development/Testing and Verification.md`** — state plainly
that
  `cargo fmt --all` does not work on Windows here; give the per-package
  alternative and `bash scripts/install-hooks.sh`.

## Verification (measured on this box)

- **`install-hooks.sh --dry`** succeeds from the **worktree** and
(relative-`.git`
  branch) from a **normal checkout**, both resolving to the same shared
`…/onnx-genai/.git/hooks`. Run under **Git-for-Windows bash**, which
actually
executes hooks. *Note:* WSL bash cannot run git in a Windows-created
worktree at
all — the `.git` pointer holds a `C:/…` path WSL's git can't resolve;
that is a
WSL/Windows limitation affecting every git command there, not this
script.
- **End-to-end, against the committed hook:**
- staged a mis-formatted **member** `.rs` → commit **blocked** (exit 1),
diff
shown, fix `cargo fmt -p onnx-runtime-cpuinfo` printed; ran it → commit
    **passed**.
- staged only a **non-member** (`bench-seqmajor`) `.rs` → commit
**passed** with
the "not a workspace member … CI's cargo fmt --all does not cover them
    either" skip warning.
- staged a mis-formatted **member** *and* a **non-member** together →
commit
**blocked**, and the block came **only** from the member; the non-member
was
    skipped and the printed fix command works.
- simulated `cargo metadata` failure (stub returning 101) → hook
**exited 0**
    with the fail-open warning.
  - All test artifacts discarded; nothing committed.
- **`main` is clean** by the new check: looping `cargo fmt -p <name> --
--check`
  over all 54 members → **checked 54, failed 0, ignored 0**.
- **Hook wall time** on a realistic single-package staged change: **~1–2
s** (the
  hook only checks the staged packages, not all 54).
- **Full-member confirmation timing** (this is the `main`-clean sweep,
not the
per-commit hook cost): two consecutive runs **26.1 s** then **25.2 s**,
consistent with an independent 23.1 s measurement. An earlier one-off
87.5 s
reading was a non-reproducible first-run outlier and is not
representative.

## Not touched

- `.github/workflows/ci.yml` — CI is not broken; this is a local-gate
fix.
- Anything under `.squad/`.



## Rebase (onto latest main)

Rebased from base `4b1cabb8` onto `origin/main` at `1557a355` (which had
advanced through #1482, #1173, #1420, #1487). The **only** conflict was
in
`wiki/development/Testing and Verification.md`: #1482 translated the
whole wiki
to Chinese (`lang: zh-CN`), so my originally-English Windows-formatting
section
collided with the now-Chinese baseline. Resolved by **following the new
Chinese
baseline** — the added formatting/pre-commit documentation is written in
Chinese
to match the surrounding prose, and none of #1482's translation was
reverted.
Per project rules, code, commit messages and this PR title/body stay in
English;
only that wiki body follows its file's language.

Checked that #1487's `docs/benchmarks/windows-cuda-runbook.md` neither
overlaps nor conflicts with the wiki formatting note (the runbook covers
CUDA
benchmarking and contains no formatting/hook content), so no cross-link
was
needed.

After the rebase, re-ran the three end-to-end scenarios
(member-block→fix→pass,
non-member-only→pass+skip-warning, mixed→blocked-only-by-member) and the
`main`-clean sweep (**checked 54, failed 0**) — all still correct. Test
artifacts cleaned; working tree clean.

Co-authored-by: justinchuby <223556219+Copilot@users.noreply.github.com>
@codecov

codecov Bot commented Aug 20, 2026 •

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.64%. Comparing base (4a9f4ec) to head (81c19e4).
⚠️ Report is 66 commits behind head on main.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #1482      +/-   ##
==========================================
+ Coverage   82.10%   82.64%   +0.54%     
==========================================
  Files          12       12              
  Lines        5471     5475       +4     
  Branches     5471     5475       +4     
==========================================
+ Hits         4492     4525      +33     
+ Misses        780      757      -23     
+ Partials      199      193       -6     
Flag Coverage Δ
cli-ort-linux 82.60% <ø> (?)
cli-ort-windows 82.10% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
see 3 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

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