Skip to content

Move native localizations into Swift Package#5611

Open
tonisevener wants to merge 35 commits intomainfrom
localizations-spm-final
Open

Move native localizations into Swift Package#5611
tonisevener wants to merge 35 commits intomainfrom
localizations-spm-final

Conversation

@tonisevener
Copy link
Copy Markdown
Collaborator

@tonisevener tonisevener commented Dec 23, 2025

Phabricator: https://phabricator.wikimedia.org/T402664

Also fixes https://phabricator.wikimedia.org/T358108 as a side-effect.

Notes

The main goal of this PR is for WMFComponents files to reference WMFLocalizedString directly, so that we no longer need to create and maintain massive LocalizedString structs during feature development.

This PR creates a new Swift package, called WMFLocalizations. This package outputs two products, one called WMFNativeLocalizations, which will hold our native translation strings files, CommonStrings, and WMFLocalizedString. The WMFComponents package now sets WMFNativeLocalizations as a dependency.

This new package will also (eventually) output another product called WMFTranslateWikiLocalizations. I intend to have our current Translatewiki localizations (which currently live in the generically named Wikipedia > Localizations directory) go directly into WMFTranslateWikiLocalizations instead, but we need to update the backend scripts to commit to this new directory location first. So you will see a WMFTranslateWikiLocalizations directory in the package as well with some empty dummy files to keep the compiler from complaining.

One more tricky bit is that our translated Infoplist strings, which contain the translated app name, cannot live in a package, so I kept those on the app-side under a new directory called "InfoPlist Native Localizations". This allows the app name to continue to use the translated string. These Infoplist files are currently not updated when Translatewiki strings are imported - this flow remains broken for now (see related task). To fix it, we will need to ensure our localization import script updates these Infoplist files in this directory.

This also removes some Fastlane logic from our localizations script. We aren't using Fastlane for deployment anymore so we don't need to write to those unused metadata files.

I added some test commits at the end to test out the new flow.

1523e75 - We can now reference WMFLocalizedString in a WMFComponents view model. This adds a test string to WMFDeveloperSettingsViewModel.
ad1a11c - Upon app build, the string is exported in the same old locations for Translatewiki to consume (updates the Wikipedia > Localizations directory)
209ca39 - This simulates the type of commit we get from Translatewiki PRs.
4c35a33 - These changes occurred after I ran the import localizations script, which automatically happens when Translatewiki PRs are created via a Github Action.
4ccb42b - Here I printed out the string. On a device with French as the primary language, it printed out the French string.

Test Steps

  1. See my test steps above for how I tested WMFComponents.
  2. Regression test a device with a non-EN language in iOS Settings. Confirm app is still localized properly.

Please merge via the squash & merge button, in case something breaks and we need to easily revert.

@l-olson1214 l-olson1214 self-requested a review January 5, 2026 19:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant