Skip to content

Localization scripts: use shared PROJECTS list, pin an iOS destination - #489

Closed
ps2 wants to merge 1 commit into
next-devfrom
fix/localization-script-projects
Closed

ps2 wants to merge 1 commit into
next-devfrom
fix/localization-script-projects

Conversation

@ps2

@ps2 ps2 commented Sep 5, 2026

Copy link
Copy Markdown
Contributor

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.sh carried its own copy of PROJECTS, separate from the maintained list in Scripts/define_common.sh that ten other scripts already source. The copy had drifted badly:

  • Still names OmniBLE and OmniKit — neither has been a submodule since OmnipodKit replaced them
  • Missing OmnipodKit, EversenseKit, MedtrumKit entirely

The script runs under set -e, so cd OmniBLE aborts 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.sh rather than duplicating, so the list has one home and can't drift again.

Explicit iOS destination

All four localization scripts invoked xcodebuild with no -destination, unlike .circleci/config.yml and AGENTS.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

  • All four scripts pass zsh -n
  • The sourced PROJECTS list expands to the 18 correct entries
  • LoopWorkspace builds with the new flag under Xcode 26.6 and the Xcode 27.0 beta (27A5237l): ** BUILD SUCCEEDED **, exit 0

What this does not fix

A translator reported MACOSX_DEPLOYMENT_TARGET is set to 10.15 errors against five LoopKit targets under Xcode 27 beta 6. I could not reproduce that, on either lineage, with their exact destination-less command:

Branch Xcode 27.0 beta result
next-dev ** BUILD SUCCEEDED **, zero MACOSX errors
dev ** BUILD SUCCEEDED **, zero MACOSX errors

LoopKit.xcodeproj has never set MACOSX_DEPLOYMENT_TARGET on any branch (git log -S confirms), and under Xcode 26 those targets resolve it to 26.5 from the SDK. Note also that CGMBLEKit and LibreTransmitter do hardcode 10.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

MixpanelService and LibreLoop both 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, dev carries the identical stale script and needs the same fix.

…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

ps2 commented Sep 5, 2026

Copy link
Copy Markdown
Contributor Author

Superseded by #490, which makes the same change against dev — the branch the translator was actually building. The four scripts are byte-identical between the two lineages, so #490 can be cherry-picked here once it lands.

Closing to avoid two open PRs for one change; reopen if you'd rather land next-dev first.

@ps2 ps2 closed this Sep 5, 2026
@ps2
ps2 deleted the fix/localization-script-projects branch October 6, 2026 15:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant