Move native localizations into Swift Package#5611
Open
tonisevener wants to merge 35 commits intomainfrom
Open
Conversation
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.
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
Please merge via the squash & merge button, in case something breaks and we need to easily revert.