Currently, the App is localized "the manual way" using only the feature set what Xcode offers. But as I already once explained in this blog post, using dynamic String references is error prone and distracting from the actual development task. Therefore I suggest adding exactly the workflow I described in the blog post.
For contributors this basically will mean that they need two command line tools installed on their machine (I will make sure that they are all automatically installed with a single command and document that in the README). Then:
// Instead of this:
title = NSLocalizedString("welcome", comment: "")
// They can write this:
title = BartyCrouch.translate(key: "welcome", translations: [.english: "Welcome!"])
The latter will be automatically replaced by an appropriate and compiler checked L10n command which replaces NSLocalizedString. It may sound odd at first sight, but reading the article or using it once will make it immediately understandable.
Currently, the App is localized "the manual way" using only the feature set what Xcode offers. But as I already once explained in this blog post, using dynamic String references is error prone and distracting from the actual development task. Therefore I suggest adding exactly the workflow I described in the blog post.
For contributors this basically will mean that they need two command line tools installed on their machine (I will make sure that they are all automatically installed with a single command and document that in the README). Then:
The latter will be automatically replaced by an appropriate and compiler checked
L10n
command which replacesNSLocalizedString
. It may sound odd at first sight, but reading the article or using it once will make it immediately understandable.