Add the language catalogue and localize feature text - #24
Merged
Conversation
First half of localization. Ships the loader, an en-US catalogue, and resolution for everything driven by Features.json. The GUI chrome in the XAML files is not covered yet. Config/Languages/<code>/Features.json and Categories.json hold the text. Structure and function names follow upstream PR 764 so the two can be reconciled later without renaming, with WinSwift file naming. Resolution order is the active language, then its en-US fallback, then the value already in Features.json. A partial translation therefore falls back key by key rather than rejecting the whole language, and a feature added without a catalogue entry still shows English. Resolve-LanguageFolder matches exactly first, then any region sharing the language, so es-MX picks up es-ES. Rather than change each of the ten call sites that read $feature.Label and friends, Update-FeatureTextFromLanguage overlays the translated values onto the loaded features once, right after Features.json is parsed. CLI, GUI and XAML bindings all pick it up and no call site can be missed. Category is deliberately not overlaid. It is both a display string and the key features are grouped by, so translating it in place would break grouping. Get-WinSwiftCategoryText resolves it for display instead, and gets wired up with the chrome. The en-US catalogue was generated from Features.json rather than typed, and a test asserts the two match exactly, so drift fails the build. Two fixes found while wiring this: - LoadJsonFile was dot-sourced after the feature load that now needs it. Moved both it and the language loader above that block. - Initialize-Environment still declared 3.3.0, a third version location missed in the 3.4.0 bump. It feeds $script:AppVersion, so every run summary since the release has reported the wrong version. It now derives from WINSWIFT_VERSION instead of repeating it.
Merged
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
1 participant
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.
First half of localization for v3.5.0. Ships the loader, an en-US catalogue, and resolution for everything driven by
Features.json. The GUI chrome in the XAML files is not covered yet; that is the second PR.Layout
Config/Languages/<code>/Features.jsonandCategories.json. Structure and function names follow upstream PR 764 (Resolve-LanguageFolder,Import-LanguageContent,Import-LanguageFile) so the two can be reconciled later without renaming, with WinSwift file naming.Resolution
Active language, then its en-US fallback, then the value already in
Features.json. So a partial translation falls back key by key rather than the whole language being rejected, and a feature added without a catalogue entry still shows English instead of an empty control.Resolve-LanguageFoldermatches exactly first, then any region sharing the language, soes-MXpicks upes-ES.One integration point, not ten
Ten call sites read
$feature.Label,$feature.ApplyTextand friends across the CLI, the GUI and the XAML bindings. Rather than edit each,Update-FeatureTextFromLanguageoverlays translated values onto the loaded features once, immediately afterFeatures.jsonis parsed. Everything downstream picks it up and no call site can be missed.Categoryis deliberately not overlaid: it is both a display string and the key features are grouped by, so translating it in place would break grouping.Get-WinSwiftCategoryTextresolves it for display and gets wired up with the chrome.Two fixes found while wiring it
LoadJsonFilewas dot-sourced at line 320, after the feature load at 228 that now calls it. Moved both it and the language loader above that block.Initialize-Environment.ps1still declared3.3.0- a third version location missed in the 3.4.0 bump, alongside the.VERSIONcomment andWINSWIFT_VERSION. It feeds$script:AppVersion, so every run summary since the release has reported 3.3.0. It now derives from the constant rather than repeating it.Verification
The en-US catalogue was generated from
Features.json, not typed, and a test asserts the two match exactly so drift fails the build. 112 features, 479 strings, 12 categories.Exercised the loader against the real shipped catalogue: loads, resolves labels and categories, falls back for unknown languages, overlay replaces stale text, and every catalogue feature resolves a non-empty Label. Unit tests cover per-key fallback and the no-catalogue path using a two-language fixture.
Static validation passes (112 files, up from 110), standalone rebuilt and parse-checked.
build.ps1already bundlesConfig/, so the catalogue ships in the standalone with no build change.Not verified: the GUI has not been launched. Nothing here changes GUI code paths, only the text those paths read.