Closed fabiorodella closed 7 years ago
BartyCrouch uses the genstrings
or extract-loc-strings
command line tools for extracting the localizations from the code files. So strictly speaking Apple itself is maintaining the extraction part of this library – where we don't have any influence. Also I imagine finding all Strings using that extension and making it work properly for all edge cases to be a lot of work.
Having that said, that extension of yours only has benefits in writing less code. Also as the comment part is gone it makes it hard to recognize the exact content of the string either for the developer (in case a key is used like 'settings.icon.title') or for the translator (in case it just says 'Settings' – the context is unknown).
Instead I suggest you to use a tool like SwiftGen to automatically convert your Strings file contents to enums. This way you not only have less code to type, but also get auto-completion and compiler-checks for the existence of a translation for free.
Then the recommended way of integrating BartyCrouch is:
– configure BartyCrouch build script once (see docs)
– configure SwiftGen build script once (see their docs) (add option -t dot-syntax-swift3
)
– make sure to place the SwiftGen build script below the BartyCrouch build script
Now each time you want to add a new localized key, you do the following:
– add that ugly NSLocalizedString("yourKey", comment: "")
thing(s) to your code
– build your project (which will trigger both BartyCrouch and SwiftGen)
– now replace those ulgy thing(s) with L10n.YourKey
I hope this makes things clear and help you keep your code nice and clean. I'm assuming that this was your goal by adding that extension.
I'm closing this issue as requested feature is out of scope of the goals of the project.
In my project I have the following String extension which I use to localize strings:
Could something like this be supported by BartyCrouch?