[Tooling] Migrate iOS13 Widgets to use App strings

[AliSoftware]

This is part of project ref paaHJt-2Ib-p2 & paaHJt-2J8-p2

This PR is a follow-up of #17570 and migrates the 3 iOS13-styte widgets (the legacy ones that since got kinda obsoleted by our more modern WordPressStatsWidgets migrated in #17570 but are still relevant to people who didn't update yet)

What went into this PR

• I moved the AppLocalizedString.swift file to a more appropriate, shared directory as it is now used by multiple targets (not just the WordPressStatsWidgets from when this was introduced back in Merge 18.7.0.1 (beta 2) into develop #17562)
• I then added it to all the WordPress*Widget targets, as well as to the main WordPress and Jetpack app targets (since some files using this from next step were included in both the *Widget and the app targets).
• I went over every file(†) which were used by those WordPress*Widget targets (i.e. were part of their Compile Sources Build Phase) and for each replaced every use of NSLocalizedString with AppLocalizedString, to ensure they always look up strings from the app's bundle, even in the context of an App Extension / Widget
• Removed all the *.lproj/Localizable.strings files from the various *Widget targets

---

(†) To ensure I didn't miss any of the files included in those targets' Build Phase, including the files that were not located under WordPress/WordPress*Widget/** but also files that lived in WordPress/Classes/** as they were shared by the app too, I wrote some scripts as below:

files_in_targets.rb

#!/usr/bin/env ruby

require 'xcodeproj'

def die!(error)
  puts error
  exit 1
end

def list(array)
  array.map { |x| " - #{x}" }.join("\n")
end

die! 'Name of a target is required as first parameter.' if ARGV.count == 0
targets_to_check = ARGV

project = Xcodeproj::Project.open('WordPress/WordPress.xcodeproj')
targets = targets_to_check.map do |name|
  project.targets.find { |t| t.name == name } \
    or die! "Can't find target #{name}. Available targets are:\n#{list(project.targets.map(&:name))}."
end

phases = targets.map do |t|
  t.build_phases.find { |p| p.is_a?(Xcodeproj::Project::Object::PBXSourcesBuildPhase) } \
    or die! "The target #{target} does not seem to have a Sources Build Phase."
end

files = phases.flat_map { |p| p.files_references.map(&:real_path) }.sort.uniq

# puts "Files compiled as part of targets #{targets_to_check.inspect}:"
# puts list(files.map(&:to_s))
print files.join("\0")

Running the script

I then ran the above script to list all the files that were in any of the Widget targets, and pipe it to ag via xargs to search for any use of NSLocalizedString. I then replaced all the relevant occurrences found by AppLocalizedString instead, and this is what was left at the end of this PR (aka only occurrences in comments), showing that everything from Widgets should be migrated.

$ ruby ./files_in_target.rb WordPressStatsWidgets WordPressTodayWidget WordPressThisWeekWidget WordPressAllTimeWidget | xargs -0 ag 'NSLocalizedString'

/Users/olivier/Documents/Dev/apps/WordPress-iOS/WordPress/Classes/Utility/AppLocalizedString.swift
28:/// and its value to have been provided via a call to `NSLocalizedString` or `AppLocalizedString`.
32:/// at that point of the code, via a call to `NSLocalizedString`, `AppLocalizedString` or similar upstream in the code.
37:/// Use this function instead of `NSLocalizedString` to reference localized strings **from the app bundle** – especially
40:/// You should use this `AppLocalizedString` method in place of `NSLocalizedString` especially when calling it

/Users/olivier/Documents/Dev/apps/WordPress-iOS/WordPress/Classes/ViewRelated/Stats/Extensions/Double+Stats.swift
45:                    // Note: using `AppLocalizedString` here (instead of `NSLocalizedString`) to ensure that strings

How to Test

The steps to test are pretty similar to the ones from #17570:

1. Select one of the iOS13 widget scheme (WordPressTodayWidget, WordPressThisWeekWidget, WordPressAllTimeWidget)
2. Select "Clean Build Folder" in Xcode (to ensure there's no .strings resources cached in previous build folders)
3. Edit the Scheme, and under Run > Options tab, choose an App Language and App Region in the dropdown you want to test this in
4. Open the iOS simulator you plan to test that PR in, or your test device, and delete any instance of WordPress installed in it (to ensure any cached precompiled resources installed would not remain and muddy the test)
5. Optionally, change the device language in that simulator to the locale to test (Settings app > General > Language).
   • In theory this is redundant with the setting you just set in the Xcode Scheme under Run > Options, but in practice I've seen cases where the Language in Scheme settings was not always taken into account for widgets themselves? 🤷 So better safe than sorry.
6. Back to Xcode, Build and Run the iOS13 Widget scheme you previously chose.
   • The simulator should end up launching on the leftmost page of the Springboard where iOS13-style widgets live, and you should have the 3 iOS13 widgets displayed there.
   • If not, it might be worth retrying a ⌘R (and pray). I've had many hit-and-miss there (debugging iOS13 Widgets is not a great Xcode experience), YMMV. Insulting Xcode doesn't seem to improve the results, but switching to another model of simulator might (e.g. iPhone 11 Pro iOS 13.5 often led me in "Unable to load widget" error, but then switching to iPhone 11 Pro iOS 15 finally worked… 🤷 ).
   • It might also help (?) to clean, then ⌘R once (which might land in an empty Springboard page without the widgets), then open the newly installed WordPress app once and maybe even log in and go to the Stats screen in the app, then go back to Xcode and start a ⌘R again…
7. Check that the various strings – especially the "Visitors", "Views", "Comments", "Likes" keys which were previously already translated in most locales – appear in the language you are testing in.
   • Also check that the dates on the "This Week" widget are formatted according to your Region settings
   • It could happen that some strings don't have a translation in all locales; in that case it might be worth checking that it's falling back to English as expected. Though in practice now that translations are all pulled from the app bundle's .strings – which contains way more translations than the previous .strings files that this PR deleted from the widget target – it is more likely that we'll have more translation coverage for free, so I expect that all of "Views" ,"Visitors", "Posts", "Best views ever", "Likes", "Comments" and "Today" have translations in all our Mag16 (while e.g. "Best views ever" was not part of the widget target's .strings file before and thus likely did not show up as localized in most locales prior to this PR, but now does)

Note on Widgets' titles

Note that the names/titles of the 3 iOS13 widgets (which appear in each widget's "title bar") won't be translated. This is because if I'm not mistaken, those titles come from each widget target's Info.plist and its CFBundleDisplayName key, so to have those translated we'd need to provide a localized title via an InfoPlist.strings file for each.

Given those targets are legacy (obsoleted by the new iOS14+'s WordPressStatsWidgets), I didn't feel it worth it to put in place a complicated logic to handle the case for those titles – which would require a fastlane action to redispatch the translated strings from GlotPress into those .strings files on download, action which I only plan to work on later in the project anyway. So I decided to keep the status quo here and consider that not having those legacy widget's titles localized was acceptable given their obsolescence.

Regression Notes

1. Potential unintended areas of impact

Localization of iOS13 widgets

2. What I did to test those areas of impact (or what existing automated tests I relied on)

Tested in simulator in a couple of locales

3. What automated tests I added (or what prevented me from doing so)

N/A

---

PR submission checklist:

• I have completed the Regression Notes.
• I have considered adding unit tests for my changes.
• I have considered adding accessibility improvements for my changes.
• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

[peril-wordpress-mobile]

You can trigger an installable build for these changes by visiting CircleCI here.

[peril-wordpress-mobile]

You can trigger optional UI/connected tests for these changes by visiting CircleCI here.

[mokagio]

Posting the code-only review before starting the manual testing, which might take a while and end up being interrupted by dinner time 😅

So far, looks great. I'm not a fan of sharing files between targets, but I think this is the best solution in the current state of the codebase and likely to remain viable and effective for a while 👍

[mokagio]

I'm not having any luck loading the widgets... I tried different Simulators and two different schemes (Today and ThisWeek) and iOS 13.x vs 15 versions.

I just don't see them in the list or the Widgets springboard page. E.g.:

Anything I might be missing? Suggestions?

---

As I was writing this comment, macOS informed me SpringBoard crashed 🤦

[AliSoftware]

I'm not having any luck loading the widgets... I tried different Simulators and two different schemes (Today and ThisWeek) and iOS 13.x vs 15 versions.

As I was writing this comment, macOS informed me SpringBoard crashed 🤦

Welcome to my world 😒

Last resort I tried was rebooting the Mac. Another alternative worth trying is… testing on device?

[AliSoftware]

Anything I might be missing? Suggestions?

Other tricks I tried: once the scheme for the widget got launched, try to go to the other pages of the Springboard to locate the WordPress app itself (which got installed alongside the widgets), launch it at least once, and then go back to Xcode and retry a ⌘R (without a clean beforehand this time!).

Last alternative: test on device (or reboot Mac and sacrifice a goat before retrying)

I'm re-adding @wordpress-mobile/owl-team as reviewers (instead of just you) in case others 🦉 have more luck testing in their own Xcode and Simulators… 🤞 (even those those issues matches my poor and very random experience with Xcode and debugging Widgets 😒 but let's hope one of you will be able to finally have Xcode on their side at least once…)

[mokagio]

I was finally able to get this to run, on an iPad Pro 12.9" 4th Generation with iOS 13.4 Simulator 😓

But... I don't get the localized strings. I tried Italian, Spanish, and French.

Italian	Spanish	French

At this point, though, I'm not too confident in Xcode and the Simulator accuracy...

I thought about shipping an installable build but I don't have a device with iOS 13 at hand. 🤔 I say let's just merge it and see how we go.

[AliSoftware]

Debugging TodayWidget while my simulator is in French, and this is indeed super strange:

(lldb) po Bundle.app
NSBundle </Users/olivier/Library/Developer/CoreSimulator/Devices/9BC9C23C-FCFA-41B5-9BBC-5B19D47F3D52/data/Containers/Bundle/Application/6C9EC4A4-87D1-4CFE-BF97-766CB28E00BF/WordPress.app> (not yet loaded)

(lldb) po Bundle.app.preferredLocalizations
▿ 1 element
  - 0 : "en"

(lldb) po Locale.preferredLanguages
▿ 2 elements
  - 0 : "fr-FR"
  - 1 : "en-FR"

(lldb) po Bundle.app.localizedString(forKey: "Views", value: "Nope", table: nil)
"Views"

(lldb) expr let $fr = NSDictionary(contentsOf: Bundle.app.url(forResource: "Localizable", withExtension: "strings", subdirectory: nil, localization: "fr")!)!
(lldb) po $fr["Views"]
▿ Optional<Any>
  - some : Vues

(lldb) po LocalizedText.views
"Views"

(lldb) po LocalizedText.likes
"Likes"

(lldb) po $fr["Likes"]
▿ Optional<Any>
  - some : J’aime

Screenshot of Debugging Session on WordPressTodayWidget extension target

---

So… I'm just hoping it's because of Xcode and the simulator not being great for that and that it would work as expected on a real device 🤞

[AliSoftware]

I say let's just merge it and see how we go.

Yeah I agree 👍
Especially given those are legacy anyway and superseded by the StatsWidget, and that Xcode seems to behave equally badly when trying to test those Widgets in various locales before the changes in this PR too.

@mokagio Can I get an official ✅ on the PR so it can be merged? 🙇

[mokagio]

Explicit approval based on conversation above 👍