Repository navigation
Conversation
…ation import_localizations.sh carried its own copy of PROJECTS that had drifted badly from the maintained list in define_common.sh, which ten other scripts already source. The stale copy still named OmniBLE and OmniKit, neither of which has been a submodule since OmnipodKit replaced them, and it was missing OmnipodKit, EversenseKit and MedtrumKit entirely. Since the script runs under `set -e`, `cd OmniBLE` aborted it outright -- and had it continued, translations for the three missing repos would never have been imported. Source define_common.sh instead of duplicating, so the list has one home. The maintained list also carries the correct upstream targets for pull requests (loopandlearn:OmnipodKit, bastiaanv:EversenseKit, jbr7rr:MedtrumKit) rather than the LoopKit forks. Also pass -destination 'generic/platform=iOS' to the build, export and import invocations in all four localization scripts. They previously specified no destination, unlike .circleci/config.yml and AGENTS.md, which left xcodebuild free to resolve destinations across platforms; a translator hit macOS deployment target validation errors under the Xcode 27 beta. The explicit iOS destination cannot resolve to macOS. Verified: all four scripts pass `zsh -n`, the sourced PROJECTS list expands correctly, and the workspace builds with the new destination flag under both Xcode 26.6 and the Xcode 27.0 beta.
ps2
marked this pull request as ready for review
September 5, 2026 00:50
Contributor
Author
|
Superseded by #490, which makes the same change against Closing to avoid two open PRs for one change; reopen if you'd rather land |
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
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.
Opened as a draft so CODEOWNERS isn't pinged — mark ready when you want reviewers.
Found while looking into a translator's Xcode 27 beta failure. It does not explain that failure (see the last section), but it's a real bug on its own.
The stale duplicate list
Scripts/import_localizations.shcarried its own copy ofPROJECTS, separate from the maintained list inScripts/define_common.shthat ten other scripts alreadysource. The copy had drifted badly:OmniBLEandOmniKit— neither has been a submodule sinceOmnipodKitreplaced themOmnipodKit,EversenseKit,MedtrumKitentirelyThe script runs under
set -e, socd OmniBLEaborts it outright. Had it continued, translations for the three missing repos would never have been imported.The maintained list also targets the correct upstream repos for the PRs it opens —
loopandlearn:OmnipodKit,bastiaanv:EversenseKit,jbr7rr:MedtrumKit— rather than the LoopKit forks the stale copy would have used.Fix: source
define_common.shrather than duplicating, so the list has one home and can't drift again.Explicit iOS destination
All four localization scripts invoked
xcodebuildwith no-destination, unlike.circleci/config.ymlandAGENTS.md, which both pass one. That leaves xcodebuild free to resolve destinations across platforms.Added
-destination 'generic/platform=iOS'to the build, export and import invocations. It cannot resolve to macOS, and doesn't depend on a particular simulator existing on the machine.Verification
zsh -nPROJECTSlist expands to the 18 correct entries27A5237l):** BUILD SUCCEEDED **, exit 0What this does not fix
A translator reported
MACOSX_DEPLOYMENT_TARGET is set to 10.15errors against five LoopKit targets under Xcode 27 beta 6. I could not reproduce that, on either lineage, with their exact destination-less command:next-dev** BUILD SUCCEEDED **, zero MACOSX errorsdev** BUILD SUCCEEDED **, zero MACOSX errorsLoopKit.xcodeprojhas never setMACOSX_DEPLOYMENT_TARGETon any branch (git log -Sconfirms), and under Xcode 26 those targets resolve it to26.5from the SDK. Note also thatCGMBLEKitandLibreTransmitterdo hardcode10.15, and were present in both builds that succeeded — so that value alone isn't fatal to Xcode 27.The destination flag here is defensible hygiene and may well sidestep it, but I have no evidence it's the cause, and this PR shouldn't be treated as closing that report.
Not addressed
MixpanelServiceandLibreLoopboth contain localizable resources but appear in no PROJECTS list. Adding them would change where translation PRs get opened, so I left it alone — worth a separate decision.Also,
devcarries the identical stale script and needs the same fix.