Repository navigation
macos-localizations: CFBundleLocalizations and lproj staging - #277
Merged
Merged
Conversation
…aged apps Apps whose in-app strings follow the user language shipped a mixed-language UI on non-English systems: every system-provided string (About/Hide/Quit, standard alerts, SwiftUI navigation tooltips) rendered in the development region's language because the generated Info.plist declared CFBundleDevelopmentRegion=en and no localizations — so CFBundleCopyBundleLocalizations could never resolve zh-Hans or any other language. Apps worked around it with post-packaging plutil injection plus manual re-signing (pdfgist scripts/localize-app.sh). A (macos-localizations "zh-Hans" "en") declaration in rivet.rktd (BCP 47 identifiers, validated at load, deduplicated) now flows into write-macos-info! as CFBundleLocalizations and stages marker Contents/Resources/<lang>.lproj/InfoPlist.strings files before sign-macos! runs — injection happens pre-signing, no re-sign needed. Projects without the declaration build a byte-identical bundle to before. docs/configuration.md documents the key and what it does.
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.
Closes #264.
What
Apps whose in-app strings follow the user language shipped a mixed-language UI on non-English systems: the generated Info.plist declared
CFBundleDevelopmentRegion=enwith no localization declaration, so AppKit rendered every system-provided string (About / Hide / Quit / Close / Enter Full Screen, standard alerts, SwiftUINavigationSplitViewsidebar tooltips) in the development region's language while the in-app strings followed the user. Apps worked around it with post-packaging plutil injection plus manual re-signing (pdfgistscripts/localize-app.sh).A
(macos-localizations "zh-Hans" "en")declaration inrivet.rktd:write-macos-info!emitsCFBundleLocalizationswhen the key is presentContents/Resources/<lang>.lproj/InfoPlist.stringsfilessign-macos!— no re-sign neededLanguage tags are validated as BCP 47 at project load (invalid tags name the expected shape); the plist writer stays permissive so validation lives at the declaration boundary where the human writes it.
Docs
docs/configuration.mdgains a "macOS bundle localizations" section next to resources and i18n.Tests
rivet/tests/resources.rkt: no key → noCFBundleLocalizationsin the plist (byte-identical behavior); declared key → exact array in the plist; malformed tag fails atload-projectwith the BCP 47 message.macos-installer.rkt(real DMG packaging) andproject.rktsuites stay green: 117 tests across the three files.