Developing a multilingual app for a clinical setting poses unique challenges. One of the most significant obstacles? The inability to switch languages within the app itself. This article explores why this feature is essential and how Apple’s current tools fall short.
The Standard Approach to Localization
Apple’s ecosystem makes it relatively easy to localize apps by creating localized versions of an app’s resources. The latest tool, String Catalogs, offers many benefits, including straightforward import and export of strings, making it a breeze to manage localized content. String Catalogs have deep integration with Xcode and Swift UI, making localization a seamless process. Here's an example:
struct ContentView: View {
var body: some View {
// Localization "just works"! with String Catalogs
// if you're OK with the system language.
//
// If the user changes the system language, the app will
// automatically switch to the appropriate localized string.
Text("Hello, World")
}
}The Challenge in Clinical Settings
In my experience developing apps for clinical settings, the standard localization approach doesn't cut it. For example, I've built applications where doctors configure an iPad in English and then pass it to patients who need to take tests in their native language. Changing the language in the global Settings app alters the entire system's language, which isn’t practical for the doctor who needs the interface in English. Also, it forces the application to restart, which disrupts the workflow.
This is where in-app language switching becomes crucial. In these real-world scenarios, the ability to switch languages within the app is not just a nice-to-have feature—it's essential to ensure the doctor and the patient can use the app effectively.
Apple's Stance on In-App Language Switching
Apple’s stance on in-app language switching is clear: it’s not supported. The system-wide language setting is the primary way to change the language in iOS and ipadOS apps.
In the video Creating Great Localized Experiences with Xcode 11", Apple says:
First, do not attempt to set the application language manually in code. Our APIs do a lot of work to ensure users get the right language and font fall backs.
If you do need to add the option within your app to switch languages, we recommend you Launch into Settings where users can go in and switch the language of your app.
Next, when the user does change the language of your app, your app will be relaunched in the target language.
There's also a thread on the Apple Developer Forums where an engineer reiterates that changing an app's localization on the fly isn't supported.
Current Workaround for Developers
To navigate this challenge, developers must drop String Catalogs altogether and use the old style of localization: strings and stringsdict files.
While this approach works, it's far from ideal. It requires more manual work and doesn't leverage the benefits of String Catalogs. Here's an example of how you can fetch localized strings using this method:
func localizedString(forKey key: String, language: String) -> String {
// Get the path for the specified language bundle
guard let path = Bundle.main.path(forResource: language, ofType: "lproj"),
let bundle = Bundle(path: path) else {
return key // Return the key as a fallback
}
// Get the localized string from the bundle
return NSLocalizedString(key, tableName: nil, bundle: bundle, value: "", comment: "")
}
// Example usage
let helloInEnglish = localizedString(forKey: "Hello, world", language: "en")
let helloInSpanish = localizedString(forKey: "Hello, world", language: "es")
Impact on Developers
Not being able to override the app's language poses challenges for developers. The Swift String Catalog offers many benefits, such as simplifying the management of localized strings and streamlining the development process. It allows for easier import and export of strings, making localization more efficient and less error-prone.
However, we can’t fully leverage these advantages without support for in-app language switching. By addressing this gap, Apple could enhance the utility of String Catalogs and make the development process even smoother for those who need this functionality.
Suggestions for Apple
To resolve this issue, I propose that Apple add support for specifying the language when fetching strings from a String Catalog. Having a way to specify the language through a SwiftUI environment variable would also be a great addition.
While this might seem like a niche issue, it would greatly benefit developers who need this functionality.
Allowing developers to control the language within their apps would enhance the user experience, especially in scenarios where different users require different languages.
Conclusion
In conclusion, although Apple’s localization tools are robust, they fall short in scenarios where in-app language switching is essential. By allowing developers to specify the language dynamically, Apple can significantly enhance the flexibility and user-friendliness of applications built on their platform.