Joseph Duffy
Joseph Duffy

Reputation: 4826

iOS App Localisation Best Practices And Placeholders

We're currently at the stage of looking at localising our app in to multiple languages now that the general concepts of the app have been decided. This is something I want to ensure is done correct from the start to lower the risk of headaches in the future.

The app targets iOS 7 and above, uses storyboards, and is written in Swift.

Storyboards

When working with a storyboard (or a xib), what's the best way to mark a UI element as "not to be translated"? For example, I have a placeholder string for a user's display name (Display Name), which will be replaced by a users display name at run time. This display name will not be localised, but neither should the string "Display Name". Is there a method of not having a UI element's value automatically put in to the strings file? If not, is going in to that file and manually removing strings I don't want localising a sustainable option?

Strings In Code

I'm using the Swift function NSLocalizedString with the key and comment parameters. Some places I've seen say to set the key to be a unique id based on the context (e.g., intro.login-button-text), while others seem to just put the full string in the default language (e.g., Login). I like the idea of the unique ids for the key, but would this not go against the idea of the "base" language?

Exporting

Xcode 6's "Export For Localization" option seems very useful for getting the correct format of file to be sent to translators. However, as mentioned previously, placeholder text does not need to be translated. Should these placeholders be removed from the exported xliff or the strings file prior to export?

Upvotes: 2

Views: 2199

Answers (1)

Sjoerd Perfors
Sjoerd Perfors

Reputation: 2317

Looking for the the same questions myself. Hope this will help you and others. Also I would recommend to have some kind of tool to organize the xliff/string files

Storyboards:

I've seen developers putting non translating texts in storyboard with extra parentheses. i.e. {Display name}.

By using this you can see by the translation itself if it needs to be translated or not. We use oneskyapp.com and can select to hide those translations and they will be hidden for each import of that key.

Strings in Code

By following this thread they suggest to use keywords. Best practice for key values in translation files

Exporting

I cannot find a way to have some translations automatically removed when exporting. Off course you can put the views which has dynamic fields in different XIB/storyboards and decide not to translate those.

Again a tool like onskyapp.com can help you with this.

Formats

As of context with the field is important and a translation can be different when it is followed by i.e. a users name I would go for "%1$@ is online!"

Upvotes: 2

Related Questions