Remove Stale Localizations and Standardize Keys with Underscores

[jdisho]

Problem

• Leveral localizations are outdated, generating Xcode warnings. Have a look at Localizable.strings
• Inconsistent localization key naming: some keys lack underscores, making them more error prone when referenced in code.

Solution

• Remove stale localizations from Localizable.strings to clear Xcode warnings and improve maintainability.
• Convert existing localization keys to underscore format (e.g., 'USER_SETTINGS' instead of 'User Settings')

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct and Contributing Guidelines

[PSchmiedmayer]

We have generally moved to use the non uppercase/underscore variants in the Spezi Packages & Apps to make the localization catalogues easier to understand.

I would only aim to use them in exceptions where we have longer strings that continuously change such as prompts in LLMonFHIR or larger multiline text.

[jdisho]

Interesting, and good to know 👍

I mean, string literals can be error-prone during runtime. The same applies to the uppercase ones with underscores, though in this case, mistakes might be more noticeable.

[jdisho]

Perhaps it’s worth considering auto-generating these localized strings in code?

[PSchmiedmayer]

I am not sure if I completely understood the comment, but as far as I see we should use Localization Catalogues and use an automatic extraction of strings anyways. Normally Xcode should warn us if a string is stale and should automatically extract new stings if we use LocalizedStringResource or the relevant SwiftUI initializers.

[jdisho]

I'm concerned about typos that might go unnoticed. Instead of using string literals as localizable keys, we can auto-generate (with a script or a something like this) these localizations as stored properties within an enum. WDYT?

Going from this:

private var openAISettings: some View {
    Section("SETTINGS_OPENAI") {
        NavigationLink(value: SettingsDestinations.openAIKey) {
            Text("SETTINGS_OPENAI_KEY")
        }
        ...
    }
}

To this:

private var openAISettings: some View {
    Section(.settings.openai) {
        NavigationLink(value: SettingsDestinations.openAIKey) {
            Text(.settings.openaiKey)
        }
        ...
    }
}

[PSchmiedmayer]

Apple seems to have moved the other direction with their automatic extraction in xcstrings catalogues where the code is driving the localizations and warnings are emitted in the localization catalogue.

Nevertheless, I like the idea of using some more type-safe elements. I think they are working on xcstrings catalogues which would be a requirement before we can use it here (SwiftGen/SwiftGen#1124). We might need to wait for this & then adopt it here and in other apps in the future if it still is a valuable addition.