The defaulted `LocalizedStringResource` does not work with localized resources

[nonameplum]

Hey,

It is probably not the xcstrings-tool fault, but I played around to verify how it would work for my setup, that's why I created an issue here, to hopefully find a way to fix the problem.

The issue is that when SPM package contains localized resources, either the new String Catalog or legacy *.strings, the localized string by using the default LocalizedStringResource won't be correctly resolved in the app.

I made a simple app to demonstrate the problem: LocalizationSpm.zip

I made sure to set up CFBundleAllowMixedLocalizations (as suggested on swift forums) and in Package.swift define defaultLocalization: "en".

I created a bunch of Text usage checks that give this outcome when the app is running in the German language (by configuring the App Language scheme):

This respective code in TestView.swift:

let string: String = {
    let resource = LocalizedStringResource(localizable: .error)
    let value = String(localized: resource)
    return value
}()
Text("1: ") + Text(string)
// Works
Text("2: ") + Text(String(localized: "error", bundle: .module))
Text("3: ") + Text(localizable: .error)
Text("4: ") + Text(.localizable(.error))
Text("5: ") + Text(.localizable(.error), bundle: .module)
Text("6: ") + Text("error")
// Works
Text("7: ") + Text("error", bundle: .module)
// Works
Text("8: ") + Text("error", tableName: "Localizable", bundle: .module)
Text("9: ") + Text("error", tableName: "Wrong", bundle: .module)
Text("10: ") + Text(LocalizedStringKey("error"))
Text("11: ") + Text(LocalizedStringKey(stringLiteral: "error"))
// Works
Text("12: ") + Text(LocalizedStringKey("error"), bundle: .module)
Text("13: ") + Text(
    LocalizedStringResource(
        "error", defaultValue:
        "",
        bundle: .forClass(BundleClass.self)
    )
)
Text("14: ") + Text(LocalizedStringResource(
    "error",
    defaultValue: "N/A",
    locale: .init(identifier: "de"),
    bundle: .atURL(Bundle.module.bundleURL)
))
Text("15: ") + Text(LocalizedStringResource(
    "error",
    defaultValue: "N/A",
    bundle: .atURL(Bundle.module.bundleURL)
))
// Works
Text("16: ") + Text(NSLocalizedString("error", bundle: Bundle.module, comment: ""))
// Works
Text("17: ") + Text(String(localizable: .error))
Text("18: ") + Text(.localizable(.hello("John")))
// Works
Text("19: ") + Text(String(localizable: .hello("John")))

The biggest issue is that none of those work:

Text("3: ") + Text(localizable: .error)
Text("4: ") + Text(.localizable(.error))

even this one:

Text("5: ") + Text(.localizable(.error), bundle: .module)

because internally all of those in the generated code will be resolved as LocalizedStringResource which seems to be not working in this case.

Do I set up something wrong or is this a known issue of SPM localized resources with LocalizedStringResource?

As you can see variants 2, 7, 8, 12, 16, 17, 19 works properly.

Most importantly this will work:

Text(String(localizable: .error))

This could be used as a workaround at the moment if nothing better cannot be used.

Btw.
In SwiftUI Preview e.g.:

TestView().environment(\.locale, .init(identifier: "de"))

It will work as you would expect with the given examples.

[nonameplum]

After spending more time on the issue.
The problem is two-fold:

• First of all there is no problem when you change the language in the system e.g. on the simulator to Germany. Then everything works as expected.
• If you would like to test localization using App Language in the scheme configuration, then you need to also change the App Region respectively to the App Language. Only then LocalizedStringResource work as you would expect - which is QUITE surprising.

---

Update:
Oh, but there is another problem 🫣
When the preferred language is set from the iOS system app's settings:

then were are back to the same problem as with the scheme configuration only for the language.

It would mean that the best option is still to use

Text(String(localizable: ...))

Especially, because of the inability to change the preferred language in the app without having to change the region - Locale.

Good article about the same findings: https://levelup.gitconnected.com/ios-localization-localizedstringresource-vs-localizedstringkey-vs-string-56cb519cf098

[liamnichols]

Thanks for raising this @nonameplum! I wasn't aware of the issues. Did you happen to ever get around to filing an issue in Feedback Assistant for this?