Discussed this more with cross-functional teams and not using keys a no-go. This will not work if you want to share localization efforts across platforms beyond Apple which is more of a real-world scenario especially in enterprise settings. For example, Android requires localization keys to not have dots and other kinds of characters, also we found many 3rd party localization services had a character limit on key length. And when looking at very long localization entries, using the value as the key just doesn't make sense. I think sticking with my first intuition in using localization keys is the right way despite all the Apple sessions and samples showing otherwise.
Also, just to share I was able to achieve isolating localization configurations by extending Text views to initialize from other Text views. This way, I can offload the localization configurations off the view by creating a bunch of static Text views and let the rest of the app pick them off the shelf.
First I create the simple but awkward Text extension:
public extension Text {
/// Creates a text view from another text view for isolating localization entries.
init(_ text: Text) {
self = text
}
}
Then create the static Text views with all localization configurations:
extension Text {
static let notificationTitle = Text(
"Notifications",
tableName: "NotificationSettings",
comment: "The section title for notifications group on the settings screen"
)
static let snoozeTime = Text(
"Snooze time",
tableName: "NotificationSettings",
comment: "The title of the snooze time in the notifications section of the settings screen"
)
static let snoozeHelp = Text(
"The number of minutes to remind you again later for action, like the functionality of an alarm clock.",
tableName: "NotificationSettings",
comment: "This is the comment for this localized entry"
)
}
Then elsewhere in a view, I can do this:
struct ContentView: View {
var body: some View {
VStack {
Text(.snoozeTime)
Text(.snoozeHelp)
}
.navigationTitle(.notificationTitle)
}
}
This still lets the localization to be exported properly since the static Text views aren't dynamically generated from variables. I still wish the localization configurations weren't in the Text view itself but in the LocalizedStringKey or a new type such as LocalizedString, since this is the way that String(localized:table:bundle:locale:comments:) works and would just need a SwiftUI counterpart to it.
