In part two of this series, we looked at how to implement localization of an iOS app using storyboards. Today we’ll continue with that app, and examine how to localize text that is generated programmatically. We’ll also clean up the project a bit, to bring some organization to the localized data files.
This post is the second part of an ongoing series on localization of iOS apps. Please read part one here, if you missed it.
While this post on the MacRumors Forum is a good tutorial for bringing Localization (L10n) to your iOS app, it’s a little sparse in detail, has some updates that change the process, and assumes a few steps. A couple of bugs have also been discovered that need to be worked around to successfully initiate localization in a new iOS app in Xcode.
Today I’ll attempt to clarify some of these steps, and dig into the minutiae that are important to a successful development and deployment cycle. What follows is an example of creating an app from scratch and adding localization features. Read More…
With the increased globalization of the economy, there is an obvious need to create mobile apps that handle multiple languages in a clean and extensible manner. This is known as localization (L10n) in the software development community, and various platforms deal with it in their own unique ways. We will look at how iOS manages L10n here, and the decisions that have to be made in order to stay on top of a dynamic situation.
There are several resources on iOS L10n available, both in official publications by Apple, and some articles and blog posts written by members of the development community:
- Apple provides a home page for Internationalization (I18n), with links to several additional detailed sources, including WWDC videos.
- There is an excellent tutorial on the MacRumors iPhone/iPad Programming Forum that goes into great detail on both how to convert your app to handle L10n and managing the app on an ongoing basis.
- For apps being developed to target iOS 5, using pre-Xcode 4.5, Ray Wenderlich’s blog provides a good starting point with this blog post.
This article will take a high-level look at what needs to be done to fully localize an app. Three follow-up articles will look at the nuts-and-bolts details of how to accomplish this through building an Xcode iOS app from scratch. We’ll look at creating an app with storyboards, and the process of configuring the project to localize these storyboards. Next, we’ll cover how to handle localization programmatically, if you find you have to manipulate text before displaying it. Finally, we’ll wrap the series up with a look at how to communicate with a web service and identify the language of the data you are expecting to download.
For the last couple months, I’ve been working on a new mobile application for an AIS client. It is an iPad app, targeted for iOS 6. Although I am quite well-versed in many of the iOS standard libraries, there is always “further east” to go, and I’ve really stretched my wings with this project and explored some interesting UI features. One thing in particular that I dug really deeply into is Interface Builder and its new integration into Xcode 4.x. I’ll discuss more of that in a later post, as I explored some interesting features (and limitations).
What I’d like to discuss now is the use of static libraries in Xcode for a couple different reasons. First, I have several classes that I think will be helpful to the developer community (both here at AIS and beyond), and I will be building static libraries to share with any of my colleagues who want to use them in their iOS projects. Second, being able to import static libraries into an existing Xcode project can be a little involved, and I want to outline the process in a way that proves to be repeatable. And of course, the best way of learning is to teach, so I’m looking to solidify my understanding of the process by putting it out there for any of you to try it and punch holes in my logic. Read More…
This isn’t your normal pairing. Mac developers aren’t exactly flocking to the Microsoft stack and the Microsoft development tools haven’t exactly catered to the predominantly OSS community working on Macs. In recent years, though, that has changed. ASP.Net is now OSS, first class Azure tools ship for the Mac, even the Nodejs for Azure tutorials feature Chrome on a Mac. It’s a brave new world out there!
Starting with this post and continuing over the next few months, I’m going to be sharing some of our experiences building iOS/XCode apps on TFSPreview using the cross-platform (yes, they used Java – who are these guys?!) git-tf plugin.