As described in my article Safer Localization in SwiftUI, BartyCrouch can already be used for normalizing and linting localiation on SwiftUI-only applications. But the transformation from NSLocalizedString or BartyCrouch.translate doesn't support the new LocalizedStringKey type yet.
We should consider adding an option to transform BartyCrouch.translate into a literal String and adding the key to the source Localizable.strings file automatically while doing that like before. Alternatively, we could also provide the SafeLocalizedStringKey file from the article and convert into that instead. That way, whenever the key would be removed, there would be an error shown during development, providing even more safety.
A more general approach could also include rewriting the entire BartyCrouch transformation logic for more flexibility, configurability, performance and therewhile drop the dependency extractLocStrings, at least for SwiftUI-only applications.
As described in my article Safer Localization in SwiftUI, BartyCrouch can already be used for normalizing and linting localiation on SwiftUI-only applications. But the transformation from
NSLocalizedStringorBartyCrouch.translatedoesn't support the newLocalizedStringKeytype yet.We should consider adding an option to transform
BartyCrouch.translateinto a literal String and adding the key to the sourceLocalizable.stringsfile automatically while doing that like before. Alternatively, we could also provide theSafeLocalizedStringKeyfile from the article and convert into that instead. That way, whenever the key would be removed, there would be an error shown during development, providing even more safety.A more general approach could also include rewriting the entire BartyCrouch transformation logic for more flexibility, configurability, performance and therewhile drop the dependency
extractLocStrings, at least for SwiftUI-only applications.