In our previous post we characterized content for localization. Our current post is aimed at emphasize the approach towards the first category of localized content: static content.
One thing to clear before proceeding: Apple documentation, or for that matter, any application API provider specify no distinction made between static content and dynamic content as far as localization is concerned. It’s app developers’ responsibility to categorize the content he owns, where to fit it into his data model, and how to bring it to the end user. It’s just an approach to look at the data we deal with, and based on the day-to-day problems that developers face, API providers bestows us with nuts and bolts that we can work with to develop our great apps in affordable and extendible way.
All disclaimer in place, now lets just rush to localize static elements of our great international app.
Let’s follow our old example of online bookstore database. We had 3 items to present:
Book title – Localizable – Dynamic (remember we are dealing with translated books)
Book Author – non Localizable
Publisher – non Localizable
Now let’s imagine our great bookstore app has having at least 2 screens:
Screen 1: Book List (localized list of books – book titles will appear in respective language)
Screen 2: Book details (localized details of a selected book from screen 1 – book details like title will appear in respective language while publisher and author names will remain as it is)
Have a look at how both look: Screen 1 shows French translated versions of 3 of the most popular novels all time. When any one of them is tapped, Screen 2 follows to show us Book title, Publisher and Author details. Fair and Simple master-detail app.
- Screen 1 & 2
Now, where is the place which is perfect candidate for statically localizeable content?
Let me give you a hint. It’s in all-pink Screen 2.
Found it? Yes? Good, you seem to have followed my earlier post quite religiously.
No? Well, have a thorough look at screen 2 above, see the labels in brown color on the left-hand side.
On screen 2, the entries ‘titre’ (Title), éditeur (Publisher) and auteur (Author) are the statically localized strings. As discussed in our previous post, entity titles such as this are perfect candidate for static localization. They appear in apps, not on per item basis, but per entity basis. Since we had 3 entities – book title, publisher and author – we got 3 localized (french) strings to present them on our detail view (Screen 2).
Now, quick work. Those of you who came here for quick look into the code snippet, Ctrl + C, and sneak out, here comes your part:
1) There is a file that stores statically localized strings for each language. This file is called InfoPlist.strings. For english app (default locale), it resides under <Project Root>\en.lproj\ folder. If you are also offering french version fo you app, one more copy of InfoPlist.strings would reside under <Project Root>\fr.lproj\ folder.
2) The file for French locale looks like:
3) Here is how you access localized string values from this file:
NSString *bookTitle = NSLocalizedString(@"Title", @"Book Title Key");
For french locale app, the above code will fetch ‘titre’ string from <Project Root>\fr.lproj\InfoPlist.strings file and dump it (well, “copy”, if you say so) into bookTitle. bookTitle can later be used to display in the UI in the topmost left label. Other strings for publisher and author are pulled up likewise.
Pretty simple, right? All you need is key-value pairs ready for all elements that you identify as entities. Implementing localization is never complex; identifying your data model and entities really is. Work on that part thoroughly, and you have won the localization war.
In our next and final tutorial in series, we will deal with localization for dynamic content.
Till then, keep translating! (quite huge chunk of that is required for that part, you gotta believe me here.)