Repository navigation
wiki: 全站中文化,并在 frontmatter 中声明 lang - #1482
Merged
Merged
Conversation
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
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 Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ 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
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
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.
把整个 wiki 翻译成简体中文,并给每一页加上
langfrontmatter 字段。规则
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)和它自身的界面文案(搜索、目录、最后更新)也跟随内容语言,而不是回落到英文。顺带修正的三处不一致
title是英文,两者不一致。H1 已改回英文,中文名保留在aliases里,检索入口不丢。meta/Using this Wiki.md里的笔记模板正文仍是英文。模板是作者真正复制的东西 —— 只改规则散文而不改模板,新笔记会一路默认回英文。已一并翻译。index.md里的(中文)标注已移除。它原本用来标记「这页是例外」,而中文现在是常规。验证
validate_wikilinks.py:145 条链接 / 25 篇,与翻译前完全一致 —— 零链接漂移。翻译前先建立了基线数字再对比,而不是只看翻译后能不能通过。npm run wiki:build成功,validate_site.py校验 4159 条内部链接 / 146 个 HTML 页。<html lang>确认:25 篇笔记全部是zh-CN,而不是只读源码推断。已知限制
51 个 alias 重定向存根仍然是
lang="en-us"。这个值硬编码在alias-redirects插件受 lockfile 校验保护的构建产物里,改它会破坏quartz_plugins.py verify,且下次plugin install就被覆盖。这些页面带robots: noindex、refresh立即跳转、不渲染任何内容,不值得为此破坏插件锁定校验。如实记录,而不是宣称覆盖率 100%。