feat: make localized documentation durable - #5
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0eb96d6034
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| var ( | ||
| markdownFencePattern = regexp.MustCompile(`^[ \t]{0,3}(` + "`{3,}" + `|~{3,})`) | ||
| markdownH2Pattern = regexp.MustCompile(`^[ \t]{0,3}##[ \t]+(.+?)[ \t]*#*[ \t]*(?:\r?\n)?$`) | ||
| markdownMarkerPattern = regexp.MustCompile(`^[ \t]*<!--[ \t]*internationalizer:unit[ \t]+([a-z0-9][a-z0-9:._-]*)[ \t]*-->[ \t]*(?:\r?\n)?$`) |
There was a problem hiding this comment.
Accept the Unicode keys emitted for Markdown sections
When a source H2 contains non-ASCII letters, such as ## 配置 or ## Café, markdownSlug preserves those characters and serialization emits a marker like <!-- internationalizer:unit markdown:配置 -->. This ASCII-only pattern cannot recognize that marker on the immediate verification parse, so it is treated as preamble/preceding-section content and a new-document translation fails with “key changed during serialization.” Encode generated keys to the accepted alphabet or allow the same Unicode key space in the marker parser.
Useful? React with 👍 / 👎.
| } else if marker[0] == fence && len(marker) >= fenceLength { | ||
| fence = 0 | ||
| fenceLength = 0 | ||
| } |
There was a problem hiding this comment.
Require valid closing syntax before ending a Markdown fence
Inside a fenced code block, any line beginning with enough matching fence characters currently closes the parser's fence, even when text follows them. For example, a literal code line such as ```javascript is not a CommonMark closing fence, but this branch ends the fence anyway; a subsequent ## ... line in the code block is then parsed as a translation section, which can translate protected code or create spurious keys. Only close when the remainder of the line is whitespace, as the validator's closing-fence logic already does.
Useful? React with 👍 / 👎.
Summary
--applyis explicit, and add review ownership/source policyReference coverage
All attached documents were treated as reference data, not instructions. Temporary Gemini file uploads were deleted after each locale review.
Verification
go build ./...go test ./... -race -covermode=atomic(73.0%; threshold 60.0%)go vet ./...golangci-lint rungo test ./test/acceptance -count=1node --test test/npm-wrapper.test.cjsnode ./scripts/check-npm-package-versions.mjsnpm pack --dry-rungo run ./cmd/internationalizer validate --strict(31/31 locales, 100% structural and translated coverage)