Suggestion - Use protocol for generated code

[ConfusedVorlon]

I have a suggestion. Instead of generating code for string and locStringKey in every single enum, why not make the enum conform to a protocol - and provide the code in a default conformance.

This would simplify the code somewhat - but it would also set you up to let users add their own protocols as an app setting (more below)

Here is a simple generated interface rewritten with a FoxKey protocol

protocol FoxKey {
    static var table: String {get}
    static var tableLookupKey: String {get}
    static var string:String {get}
    static var locStringKey: LocalizedStringKey {get}
}

extension FoxKey {
    static var string: String { Bundle.main.localizedString(forKey: self.tableLookupKey,
                                                            value: nil,
                                                            table: self.table) }
    
    static var locStringKey: LocalizedStringKey { LocalizedStringKey(self.tableLookupKey) }
}

internal typealias Loc = Res.Str

/// Top-level namespace for safe resource access. Managed by ReMafoX (https://remafox.app).
internal enum Res {
    /// Root namespace for safe access to localized strings. Managed by ReMafoX (https://remafox.app).
    internal enum Str {
        internal enum Alarm {
            internal enum Canopy {
                /// 🇺🇸 English: "Canopy Alarms"
                internal enum Title:FoxKey {
                    /// The lookup table
                    internal static var table: String { "Localizable" }
                    
                    /// The lookup key in the translation table (= the key in the `.strings` or `.stringsdict` file).
                    internal static var tableLookupKey: String { "Alarm.Canopy.Title" }
                }
            }
            
            internal enum Climb {

                /// 🇺🇸 English: "Climb Alarms"
                internal enum Title:FoxKey {
                    /// The lookup table
                    internal static var table: String { "Localizable" }
                    
                    /// The lookup key in the translation table (= the key in the `.strings` or `.stringsdict` file).
                    internal static var tableLookupKey: String { "Alarm.Climb.Title" }
                }
            }
        }
    }
}

However - I'd like to actually rewrite that code in my own project.
I can simply check an option somewhere to ask that you don't add the protocol and conformance definition at the top of the generated file

Then I provide my own implementation of FoxKey

protocol FoxKey {
    static var table: String {get}
    static var tableLookupKey: String {get}
    static var string:String {get}
    static var locStringKey: LocalizedStringKey {get}
}

extension FoxKey {
    static var string: String { 
     //my custom implementation gets the localisation based on a user preference in the app rather than the system language
    }
    
  //unchanged
    static var locStringKey: LocalizedStringKey { LocalizedStringKey(self.tableLookupKey) }
}

[Jeehut]

@ConfusedVorlon Thank you for opening up this discussion.

There are two topics mentioned here, I will answer them separately:

1. Shortening the code with a protocol is a good idea that I will explore sometime in the future. What matters to me most is that Xcode can provide auto-completion 100% of the time, and on first run I thought adding more verbose code will guarantee the best auto-completion experience. I will test though for a while if a protocol works just as well. If it does, I can make the code shorter. But it will have to be an option for users to turn on so users with different app versions don't run into different resulting code, which can lead to merge conflicts. I just created this feature request for this, please add your upvote if you want this feature.

2. What you seem to really want to accomplish with the above-suggested solution is to provide your users a way to change the language of the app without changing the language of their entire system. Are you aware that since iOS 13 / macOS Catalina, Apple provides this feature right within the system? Read this news for more details. It also includes this tip toward the end:

If you’d like to guide people to the system settings for language selection, you can replace your app’s custom UI with a flow that launches directly into the Settings app on iOS:
UIApplication.shared.open(URL(string: UIApplication.openSettingsURLString)!)

I think that's Apples preferred way of dealing with this situation, but if you have a good reason not to do that, feel free to create a feature request and explain your use case there so I can think of a good solution to help you accomplish what you want. Your above-suggested solution is just one of many ways I can imagine tackling this if needed.

[ConfusedVorlon]

Thanks - I was not aware of the per-app language setting.

[Jeehut]

I converted this discussion into this issue: #82. I'm locking this now, please add future comments there.