Alternatives to genstrings for swift projects
My usual genstrings script works well for Objective-C projects. So, when I moved to swift in my new projects, my first attempt was a little patch for find call:
find . -name "*.swift" -o -name "*.m" | xargs genstrings -o Base.lproj
This patch works, but then, suddenly, I faced this bug in genstrings which results in this error message:
Bad entry in file ./File.swift (line = 10): Argument is not a literal string.
genstings cannot parse NSLocalizedString calls with more than 2 parameters, like this: NSLocalizedString("Some String", value: "Some Value", comment: "Some Comment") (objective с equivalent is NSLocalizedStringWithDefaultValue).
Okie. Now what? You have 2 options:
Use NSLocalizedString with just 2 parameters
Use the alternatives
So. The first option is definitely not for me. I like a short dot-separated keys, that allows me to group related strings together + get rid of stupid copying of long sentences both to key and the value. There are non-apple alternatives, like swift_genstrings, genstrings2 or even DTLocalizableStringScanner. But I usually try to use as much apple-provided tools as possible.
I came across to another localization helper tool: xliff export/import. This feature was introduced in xcode6, so it’s not that new as one might think. And yes, it can be automated too!
Few experimenting resulted in two scripts for export and import of xliff files. At first sight this might look not that handy as the genstrings script. First you call export script, then edit the file manually and then call import script. But in other hand, this solution gives some benefits over genstrings solution:
You don’t use base Localizable.strings file at all. Why use it, if those strings are already present in the source code? You can keep the translations only.
Export actually grabs all of your existing traslated strings and put them into xliff file, so you will need to edit just a new/changed strings. You would do it later in strings file anyway.
All the xibs and storyboards strings goes into that single file too. No need in extra scripts that syncs new strings from IB with all the strings files. Hurrah!
xliff file is kinda standard for translators, so, in case when you work with external translators team - you won’t need to explain all the rules of translating strings file correctly. You just give them an xliff file and they will return it to you with correct translations.
Note: before running those scripts, perform export manually from the IDE once - couldn’t find out yet why it doesn’t work if the export operation were not performed there.