fix: keep custom language keys in the resolved translations - #14773
Merged
Conversation
translationsForLang rebuilt the language table from an allow-list, and formatLanguage ran it after merging the user's language object over the defaults, so a key Quarto does not ship was accepted by the schema, merged, and then discarded before templates saw it. Reading it back through $quarto.language.<key>$ gave an empty string with no warning. Copy non-object values through as well. Locale variations are objects and stay out, so the variation loop below keeps merging them itself. Closes quarto-dev#14772
Collaborator
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
mcanouil
marked this pull request as ready for review
August 13, 2026 20:25
cderv
approved these changes
Sep 7, 2026
cderv
left a comment
cderv
left a comment
Member
There was a problem hiding this comment.
Let's merge this. I'll probably do quick adaptation related to this too, on schema and others.
Thank you !
readLanguageTranslations's per-key gate only accepted keys already in kLanguageDefaultsKeys or nested objects (locale sub-blocks), so a custom scalar key shipped in a `_<file>-<lang>.yml` locale-variation file was silently dropped before formatLanguage ever saw it. Mirrors the non-object pass-through already used in translationsForLang. quarto-dev#14772
typeof null === "object" in JS, so a custom key with an explicit null
value (language: { custom-key: null }, or custom-key: with no value in
YAML) failed the non-object pass-through check in both
translationsForLang and readLanguageTranslations, silently dropping it
again for this one value type.
quarto-dev#14772
…te search PR quarto-dev#14773's body claims custom callout-/crossref-/environment- prefixed keys reach Lua filter params, and search- keys reach website search options, because both consumers select by prefix over the whole format.language table. The only test added by that PR exercised the Typst $quarto.language.*$ template-variable channel; these two channels had no coverage. Exports languageFilterParams so it's directly testable. quarto-dev#14772
Pre-existing drift: over half of the keys in _language.yml / kLanguageDefaultsKeys were absent from the format-language schema's properties list, so VSCode autocomplete never offered them. The schema intentionally has no closed: true, so custom/extension keys under language: still pass through to templates. Regenerated JSON schema, Zod types, and editor tooling via dev-call build-artifacts.
dev-call build-artifacts seeds its schema registry from the on-disk yaml-intelligence-resources.json before regenerating it. Since setSchemaDefinition only registers a schema id once, that stale seed (read before this run's edits landed) won the race and all-schema-definitions.json kept the old 62-property format-language entry even though json-schemas.json and the generated types were already correct. Running build-artifacts again, once the seed file itself reflects the schema change, produces the correct 122-property entry. Diff otherwise only reorders _internalId counters.
The two new language tests each built a partial Format via `as unknown as Format`, duplicating a third ad-hoc variant already in cleanup.test.ts, and one built a hand-rolled TempContext stub. Both subsystems already have real production factories that satisfy the actual types without casting: createFormat() (src/format/formats-shared.ts) and createTempContext() (src/core/temp.ts, already used by two other unit tests). Added tests/unit/format-utils.ts with createMockFormat() wrapping the former, switched both tests to the latter directly, and documented both in the testing conventions' mock-context table.
…ture
llm-docs/localization-architecture.md described translationsForLang and
readLanguageTranslations as filtering strictly to kLanguageDefaultsKeys
plus the crossref-*-{title,prefix} patterns, contradicting the
scalar/null passthrough these commits add for custom and extension
keys. Updated the resolution description, the "adding a new localized
string" table, and added a pitfalls bullet documenting the flat,
unnamespaced design decision (quarto-dev#14772/quarto-dev#14773).
The channel-2d table entry cited kLanguageDefaultsKeys/crossref patterns as a requirement for reaching format.language, when the scalar/null pass-through applies regardless of whether a key is Quarto-defined. Reframed step 3 as a convention for officially-shipped keys, not a runtime gate, and corrected the cited line ranges to the actual pass-through conditions (language.ts:174-180 and :119-123, not the surrounding comments).
Those keys were previously unlisted in the schema's open object, so any value including null passed through. Adding explicit `string:` entries made them reject null, even though the resolver (readLanguageTranslations, translationsForLang) treats null as a valid pass-through/clear value for every kLanguageDefaultsKeys entry.
… fix build-artifacts didn't pick up the definitions.yml change in all-schema-definitions.json (and its embedded copies in vs-code.mjs / web-worker.js) on the first run after bf92eed — a known build-artifacts regeneration flakiness tracked separately. Running it again produced the correct output; committing the now-consistent artifacts.
Merge of main left two ## Formats headings in changelog-1.11.md with All Formats split into its own section. Combine into one heading with All Formats first, per changelog conventions.
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
3 participants
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.
Closes #14772.
translationsForLangrebuilt the language table from an allow-list and ran after the user'slanguageobject was merged over the defaults, so a key Quarto does not ship was accepted by the schema, merged, then discarded before templates saw it.translationsForLangnow also copies non-object values it does not recognise; locale variations are objects, so they stay out and the variation loop below keeps merging them itself.callout-,crossref-orenvironment-now also reach Lua filter params, andsearch-keys reach website search options, because both consumers select by prefix over the whole table._language.ymlwithout a matching entry inkLanguageDefaultsKeysis no longer dropped as a built-in default.kLanguageDefaultsKeysfrom_language.ymlat build time, so the YAML file, the constants array and the schema cannot drift.The test renders one Typst document through a
typst-show.typpartial and reads back four keys: the custom key, an override of a built-in key, an untouched built-in key, and a key supplied through a locale variation.