Localize your app early

And when I say early, I mean immediately, as soon as you create your project. Trust me, just do it, take the few minutes it takes to setup localization and do it from the first word that will appear on your interface.

Regardless of your app supporting several languages at launch, doing so will not consume additional time, and these few moments will literally save you hours later on, when you actually have to translate the app.

Consistent keys

When adding a new localized key, I always group it with other keys of the same screen and use the same naming convention: snake case + name of the screen followed by a dot and followed by a description of what the key is, eg:

// EventList
"event_list.title" = "Events";
"event_list.new" = "Create Event";

There are many systems out there, find your own and stick to it.

Take shortcuts

Especially if you don’t have to, using NSLocalizedString(_:comment:) everywhere and in the proper way can be cumbersome. So unless your team and process requires it (and in most apps it will certainly not be required), you can take a small shortcut that will greatly help: build an extension to wrap the function and make the comment parameter optional.

//  String+i18n.swift

import Foundation

extension String {
    func i18n(comment: String = "") -> String {
        return NSLocalizedString(self, comment: comment)
    }
}

It’s makes it really to use by calling the i18n() method on the key.

class EventListViewController: UIViewController {

    override func viewDidLoad() {
        super.viewDidLoad()

        // i18n
        title = "event_list.title".i18n()
    }
}

Automate

You are now supporting several languages, nice, it’s time to automate! Please don’t open the string file in each language to add your keys, this is the best way to make mistakes.

Instead, for small to medium projects, you can easily create a shared document on Google Spreadsheet with a “key” column and a column for each supported language, and write a small script to download the sheet as a CSV file and generate one .string file per language.

Good habits makes your life easier

What if I’m doing a really quick and dirty test and don’t want to take the few seconds to write the localizable for it? I understand, and I do it sometimes, in this case, just make sure to:

take note that this piece of code will need localization later
be consistent so that you can retrieve all the places that need localization in one go.

I usually add a // TODO: i18n before or after the code using hard-coded text, it’s easy, and because I always use the same text in the comment, all the occurrences will show up in one project search.

Cyril Chandelier