Our current localizations strings can only be accessed in app-side code, which contains our older legacy UI views. Moving forward, we want to build all of our new UI in WMFComponents, so that our codebase is a bit more modular and each module has a distinct purpose. The problem is, code within WMFComponents cannot access WMFLocalizedString. We have to pass in LocalizableStrings structs of the resolved strings from the app-side into each view in WMFComponent, resulting in enormous structs that are tedious to maintain.

This task is to move our localizations into their own distinct Swift Package. WMFComponents can name this new package as a dependency (similar to how it does with WMFData), and older legacy UI can import this new package directly.

It may be helpful to refresh ourselves on how localization currently works in the app:

• https://github.com/wikimedia/wikipedia-ios/blob/main/docs/localization.md (Translation workflow, Script specifics, and Updating the localization script sections)
• https://docs.google.com/document/d/1cr8apA5PKYwDsH9R4wqNa71YafRv5unWdvDj_wVXqjc/edit?tab=t.0

Here are some general steps for migrating:

1. Create a new local swift package for localizations in the app - https://developer.apple.com/documentation/xcode/organizing-your-code-with-local-packages
2. Create a Resources directory in the package, then move the Wikipedia > Localizations and Wikipedia > iOS Native Localizations (and all their containing files) into it, so that Resources contains these two directories.
3. Move the new Localization.swift file (lives within the WMF Framework directory) into the local package.
4. Move CommonStrings.swift file into the local package
5. Update the localizations script (located in Update Localizations > localization.swift). Any path that points to the old area (such as "\(path)/Wikipedia/iOS Native Localizations/en.lproj/Localizable.strings") should be modified to point to the new local package path ("\(path)/{local package name}/Sources/{local package name}/Resources/iOS Native Localizations/en.lproj/Localizable.strings"). You will then need to regenerate the executable and replace it in scripts directory (the file is named localization).
6. Test and see if a WMFLocalizableString can be called directly in WMFComponents (you will need to add an import statement for your new package at the top) and that it resolves into the correct localized string. Create a new WMFLocalizableString directly in WMFComponents, then build the project. Confirm that upon build, localizations build script added the new string to the strings files.
7. Test step 6 but from a legacy view in the old area of the app. Again you will need to add an import statement to import the new swift package.

Final step before we can merge:

8. There is likely a backend script somewhere that creates commits like this (https://github.com/wikimedia/wikipedia-ios/pull/5391/commits/4c937f3d76ef9aac969b207dcfb9948265b11f53) in the twn branch, then creates a PR. We should check and see if we can update this backend script to point to the new Localizations directory location (in the local package). If we can't do that, perhaps we can keep this pipeline untouched but modify the "Import localizations from TranslateWiki" GitHub Action to add a step that copies these updated files from the old location to the new one. We won't be able to confirm this flow works until we merge our changes and see how new Translatewiki PRs act (these are automatically opened Mondays and Thursdays).

Some other useful docs I found:

• https://developer.apple.com/documentation/xcode/localizing-package-resources
• https://jaanus.com/swift-string-catalogs/ (I propose we don't bother with strings catalogs yet, but this guide should also be useful with raw .strings files)

Testing Notes

Will be available in main Wikipedia TestFlight build 8.0.1 (any latest).

1. Test fresh installing on multiple different primary device languages, including languages with variants (like Chinese). Confirm app text is in the correct language. Confirm primary Wiki language automatically chosen in onboarding looks correct.
2. The edit summary view (last view in edit flow before you tap "Publish") specifically shows the wiki localizations, not the device language localizations. Confirm that still works as expected (i.e. on an EN device language, editing a German article, edit summary view should be in German).
3. Test upgrading from 8.0.0 build to 8.0.1. Confirm app text is still displayed in the same language as in 8.0.0 after upgrading.