Fix literal-brace failures with explicit message syntax - #7
Conversation
Signed-off-by: Tom Main <tom@execufunction.com>
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: 29a7cfedae
ℹ️ 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".
| default: | ||
| output = transformLiteral(input) |
There was a problem hiding this comment.
Transform literal braces under explicit non-ICU syntax
When message_syntax is plain—or i18next with a single-brace expression—this branch still calls transformPreserving, whose syntax-independent regex protects {identifier}, %{identifier}, and {{...}}. Consequently, pseudolocalizing a plain value such as Read {draft} leaves draft untranslated even though the new syntax contract defines those braces as literal text; similarly, i18next incorrectly preserves single-brace prose. Make protected-span selection syntax-aware so only runtime placeholders for the resolved grammar are excluded from transformation.
Useful? React with 👍 / 👎.
Problem and behavior
The published CLI treats ExecuFunction's literal
{.sift,.claude,.codex,.agents}documentation text as ICU, producing the same source error for every target locale. Addmessage_syntax: auto | i18next | icu | plainwith global defaults and bundle overrides. Source units carry their resolved grammar through validation, provider/TM checks, adoption, pseudo generation, and review approval. Explicit ICU remains strict; parsing failures never fall back to plain text.The i18next profile preserves double-brace variables, nested paths, escaping/formatting modifiers, and plural-key families. HTML code contents are protected alongside existing Markdown code checks. Invalid source findings are reported once per bundle with affected locales, and dry-run reports planned work as “Would translate”.
Compatibility
autoremains the default. Fluent resources retain their own grammar. Custom i18next delimiters and nesting expressions are outside this profile. Syntax now participates in policy identity, and the prompt contract advances to v3: existing records become policy-stale and require refresh or validated adoption, followed by explicit review. Documentation includes the ExecuFunction web bundle mapping and distinguishes it from the temporary marketing catalogs. No ExecuFunction files or published npm versions are changed.Validation
go test ./... -race -covermode=atomicpassed; coverage 75.0% (required 60%). Build, vet, lint, npm wrapper tests, and package version checks passed.exfcommands. Those catalog findings need separate review; this PR does not change them.