If we target our application in more wide range than our country, it is good to localize application to be understandable by users. Very good habit is localize application in your native language and at least in English.

Making localizations in iOS application can be little tricky.

UI internationalization

We have exact the same file, where we can change properties on UI components like labels, buttons, etc.

One plus of this approach is that, we can define entirely different UI for different countries.

Base internationalization

/* Class = "UIBarButtonItem"; title = "Add"; ObjectID = "aFc-bV-NJn"; */"aFc-bV-NJn.title" = "Add";/* Class = "UINavigationItem"; title = "Presentation"; ObjectID = "cZ7-QZ-PGj"; */"cZ7-QZ-PGj.title" = "Presentation";

It reduce application size. We haven’t cloned our UI times languages we support, but this files are very hard to read/understand and even harder to maintain. xCode do not support life update strings file when we add new UILabel.

Using code to localize UI

My solution

My class hierarchy connected with UI looks like:
* Label: UILabel
** AccentLabel: Label
** SecondaryLabel: Label
* Button: UIButton
* TextField: UITextField
… and so on.

in each class on top in hierarchy i have @IBInspectable property. For Label class is is defined as:

@IBInspectable
public var localizable: Bool = false {
didSet {
guard localizable else { return }
guard let text = text else { return }
self.text = NSLocalizedString(text, tableName: "UIStrings", comment: text)
}
}

When this property is set either form Interface Builder or code didSet observer is called. When new value is set to true and label have some text, I’m looking for that key in UIStrings.strings file, which is localized in main bundle of my application.

In Interface Builder in Identity Inspector I set class for label as:

And in Property Inspector i set inspectable attribute to on as fallow:

This action add User Defined Attribute:

This attribute will be resolved after class will be loaded into memory and text defined in text property will be translated if there is key in strings file.

My POC (Prove of concept) application UI looks like:

Which is resolved as:

English and Polish UI

You can sneak into my POC on github.com: LicalizationPOC

Pros:

  • Lack of multiple xib/storyboard files describing same piece of UI
  • Always updated and synchronized localization with UI
  • Human readable — You don’t have to jumping between tabs in IB to find object identifier and match it with row in strings file.
  • Lack of gradation. Interface localizations are in one string file. They aren’t split into lots of interface files.
  • Easy maintainable. If you like localize label, all you have to do is set one switch in Interface Builder.
  • Easy extendable. If you add new scene, all you have to do is set one switch in Interface Builder. ;-).
  • You can use readable strings (English/Polish/Germany) words while you use it in strings file.

Of course your have to keep your UIStrings.strings file up to date.

Cons:

  • You have to set class in Identity Inspector.

iOS Developer