Created
March 12, 2019 19:15
-
-
Save Gernot/3ad5396053fc26b29b9cac4ae45f59ef to your computer and use it in GitHub Desktop.
A proposal to have much nicer, backwards compatible localizable strings in Swift
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
/* Here is what I want to write, and what Xcode sees. */ | |
struct Loc { | |
struct someDomain { | |
/// Here is some description of what this string is doing. It's readable in the AutoComplete Description! | |
static let myStringName = "Woah, woah, this is the actual content of the String!" | |
} | |
} | |
/* And now some Parser/Code Generator comes in and generates this out of it*/ | |
/* This is what the localization tools and the compiler see, when the App actually gets compiled */ | |
struct Loc { | |
struct someDomain { | |
static let myStringName = NSLocalizedString( | |
"SomeDomain.MyStringName", | |
value:"Woah, woah, this is the actual content of the String!", | |
comment: "Here is some description of what this string is doing. It's readable in the AutoComplete Description!") | |
} | |
} | |
/* Is this possible? Does this exist? Does anybody what to build this with me? */ | |
as we create the R files at each build we can be sure that there is a string behind R.string.localizable.myStringName
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
That would be no different from how it works now. The localization tools se the NSLocalizedStrings, do the import/export dance, etc.
I don't know why you mean with "compile time safety", but this approach guarantees that there is always a
String
behind the symbol, and in the worst case, if the translation isn't available, the string is the original content in the base language, and never ever the localization key.