feat: utilise string localisations

[russellwheatley]

PR contains string localization implementation.

A couple of things to note;

• There are no strings as far as I can see for verifying email so I left VerifyEmailView as it is, until the below question is resolved.
• I haven't touched the Facebook, Phone or Google provider Swift package until the question below has been resolved.

Questions

1. Should we keep all strings within the core package? If they need to be within their own Swift package (e.g. Facebook strings in Facebook Swift package), then this would require some refactoring to the internal implementation so we can make use of each packages Bundle.module which contains the strings.
2. Should we add strings to the string catalog for missing strings such as verifying email?

[morganchen12]

Should we want to keep all strings within the core package? If they need to be within their own Swift package (e.g. Facebook strings in Facebook Swift package), then this would require some refactoring to the internal implementation so we can make use of each packages Bundle.module which contains the strings.

Though it's a big of an abstraction-break I think we should given the localization bundle override is in the core package and strings themselves aren't stateful and have no dependencies. Overall I expect the strings required for 3P auth providers to be minimal since those dependencies (GoogleSignIn etc) also do their own localization.

Should we add strings to the string catalog for missing strings such as verifying email?

Yes, if you can add placeholders that'd be great. I'll fill them in with internal l10n resources async and they shouldn't be a blocker for this project. In the meantime Xcode will display whatever you use as a placeholder.

[peterfriese]

Is there a reason why we're not using SwiftUI's built-in string localisation?

See:

• Localize your SwiftUI app - WWDC21 - Videos - Apple Developer
• Preparing views for localization | Apple Developer Documentation
• Localizing and varying text with a string catalog | Apple Developer Documentation

[russellwheatley]

@peterfriese - The reason why I kept computed properties instead of using string literals (I think this is what you mean by built-in string localization) is for two reasons:

1. It allows us to document the strings inline, and makes it pretty clear which strings are localised.
2. It allows us to control the bundle passed into configuration used for localized strings: https://github.com/firebase/FirebaseUI-iOS/blob/string-localisation/FirebaseSwiftUI/FirebaseAuthSwiftUI/Sources/Utils/StringUtils.swift#L19-L27

Happy to update if you prefer an alternative.

[peterfriese]

@peterfriese - The reason why I kept computed properties instead of using string literals (I think this is what you mean by built-in string localization) is for two reasons:

1. It allows us to document the strings inline, and makes it pretty clear which strings are localised.

This should be covered by the comment parameter (see https://developer.apple.com/documentation/swiftui/preparing-views-for-localization#Add-comments-to-text-views):

Text("Explore",
     comment: "The title of the tab bar item that navigates to the Explore screen.")

2. It allows us to control the bundle passed into configuration used for localized strings: https://github.com/firebase/FirebaseUI-iOS/blob/string-localisation/FirebaseSwiftUI/FirebaseAuthSwiftUI/Sources/Utils/StringUtils.swift#L19-L27

In which situations would this be used?

[russellwheatley]

@peterfriese - There is a customStringsBundle in configuration that allows the user to customize strings which is specified in the design doc.

I'm not sure how we control the bundle if we use string literals. Also - we have to specify the module bundle like so to retrieve the value from the string catalog:

Text("VerifyItsYou", bundle: Bundle.module)

If we do this:

Text("VerifyItsYou")

It'll render VerifyItsYou as a fallback presumably because it is looking in the app bundle for the key/value.

[peterfriese]

If we do this:

Text("VerifyItsYou")

It'll render VerifyItsYou as a fallback presumably because it is looking in the app bundle for the key/value.

You would use the actual English phrase in the UI, so you wouldn't run into this issue. See https://developer.apple.com/documentation/swiftui/preparing-views-for-localization and https://developer.apple.com/documentation/Xcode/localizing-and-varying-text-with-a-string-catalog

[russellwheatley]

@peterfriese - Yes, you would get the English translation but you wouldn't get any other translation if we didn't specify Bundle.module.