Rough Sea Games

Automatization of repeated work is one of the keys to productive development. Another is abstraction of common problems to allow concentration on project specific work. Localization is one of the problems you have in nearly every project, especially in iPhone projects. The iPhone SDK brings interesting solutions that abstract many parts of the localization process.

The tool ibtool, for example, extracts strings from an interface automatically. The strings are placed in a .strings file, a textfile with key/value pairs. To localize an interface, you have to translate .strings and merge the strings back into the interface again. Because you have individual interfaces for every localization, it’s possible to adjust widgets individually for each one.

genstrings is another tool inside the iPhone SDK. It extracts textIDs from the source code and write them into a .strings file. You may ask how the tool knows which texts need localization and which do not. The solution is the macro NSLocalizedString, which will be replaced by a .strings file lookup method by the preprocessor, but also searched for by the genstrings tool to create the files.

Both tools help you to create a localized application without paying much attention to localization itself. But you cannot expect the localization department to search for .strings files inside your project and create localized versions of them. Of course this would be possible, but not very convenient, because you have to migrate the translated texts back into the interfaces using ibtool. Another reason for us at Rough Sea is that we use a localization interface from our publisher. This interface is well known to the localization department and the content is placed in a centralized database on a server.

So we have the great tools from Apple that help us to separate texts from the project and we have the great tool from our publisher that handles the whole translation and reviewing process. Now we need something to tie those tools together, because we do not want to insert new texts from the .strings file into the publisher’s localization tool manually or vice versa. This glue tool has to execute the Apple tools, extract the texts from the .strings files and insert them into the publisher’s loca tool. On the other hand, it has to check for new localized texts from the publisher’s loca tool, build the required .strings files from the results and merge them back into the interfaces. Sounds quite easy, but of course there are some obstacles to get there. You have to handle other things, like the deletion of a text entry or changes to an already translated interface. So you have to know what has changed since the last update and stuff like that.

It turns out that you only have to integrate this glue tool into the build process of your build server. The tool will update the localization database whenever the code or the interface changes and it will update the localized versions when the database changes. As a coder you only need to remember to use the text macro around your text id. You don’t have to add this text id in a file or anything else. As you commit your changes, the build server will do this for you. As an interface designer it’s the same: just create your interfaces in the primary language and commit it. After the localization department finishes localizing those texts, they will be inserted into the localized versions automatically. Of course you have to make adjustments to the interface if there are loca bugs like labels that are to small to hold the translated text.

As you can see those localization tools are a big black box for coders, interface designers and translators. The coders only have to write code, the interface designers design interfaces and the translators translate texts. At the end there will be a localized product.

Popularity: 61% [?]

Hello out there,

my name is Thomas and I am the first programmer in our new R&D department. Like most of the other guys here at Rough Sea, I’ve worked on games for consoles (Nintendo DS and Wii) and PC before. I’m very excited to develop sophisticated software that helps us to make state-of-the-art games. Of course this is only technically, but I’m pretty sure that Rafael and Jan will assure this for the design part too.

I assume you’ve read the headline already, so you know what the R&D department will work on in the coming months. We’ve decided to do some research on the iPhone, because we think the way you use the iPhone is almost the same as how you play a browsergame. You get your iPhone out of your pocket, use it for a few seconds and put it back again. You have nearly the same procedure with browsergames: you open your browsergame window/tab, change a few settings and go back to work.

So the first thing to do is getting your working environment running. The only legal way to do this is to buy a Mac. I’m not really happy about that, because I’m a Windows guy and there are some differences in using MacOS instead of Windows. Maybe Apple only invented the app store to sell some of their Macs to iPhone developers. Nevertheless after some adjustments the Mac became usable. The nextStep (pun indended) was the installation of the iPhone SDK and all the tools that belong to it. It’s quite easy to get from the installation of the SDK to the first Hello World on the simulator (especially if you compare this to console development).

We at Rough Sea use test driven development and continuous integration to assure that we always have  a deliverable product at hand. Unit Tests are already integrated into the SDK and it was easy for Ole to set up a build server on a Mac Mini with hudson and the makefile-like shell tool xcodebuild. You don’t have a makefile: the tool just uses the settings of the project file to know how to build. Another thing is that you can add and change text macros for the XCode IDE. Text Macros are very useful to write code much faster. For example, you can add an alloc-init call [[class alloc] init] simply by typing the letter a and then escape. There are macros for if, for and while too. Because we have different coding guidelines than the apple guys, I had to change some of the macros. You find them in /Developer/Applications/Xcode.app/Contents/ PlugIns/TextMacros.xctxtmacro/Contents/ Resources. Copy the TextMacros.xctxtmacro folder to Library/Application Support/Developer/Shared/Xcode/Specifications in your home directory. Just open the *.xctxtmacro files with a text editor to change the macros. You can add your own file and project templates too. This is very nice, because you can set up a default project with many settings, like Unit Test Targets, already in place, and use this project to create new ones with only one click. To add a new project template, create the project the way you like it and copy the whole project folder to Library/Application Support/Developer/Shared/XCode/Project Templates/GROUP_NAME/PROJECT_NAME. For file templates you should just copy the File Templates folder from /Developer/Library/Xcode/ to Library/Application Support/Developer/Shared/XCode/ and change or add the files you like.

Next time I will write about Objective-C and libraries from the iPhone SDK like UIKit.

Popularity: 80% [?]