CODEWITHSUNDEEP
iphoneiphone-sdk-3.0ios4localizationinternationalization
matm
matm

Reputation: 7079

Localization for iPhone apps - what's your approach?

In general I know how to do the Localization of iOS apps, the only thing is to choose between available ways and do it the right way. So I'd like to ask you about your l10n approach for your projects.

Here are my inputs:

  1. I have 15 XIB files (packed with lots of IB outlets that are not synthesized as properties, but will have to be localized).
  2. It is most likely that that my app will have 3-5 language versions, but it is possible that I will even go for 10 languages in the future.
  3. In near future I plan to add new targets that may change UI design (paid/free versions).

I see two ways I could go:

Option A: localize each nib file by making XIBs localizable and adding language versions:

  1. I fear that with 15 XIBs and 3-5 languages it will be maintenance horror that will go out of my control when I'll extend localization to ~10 languages and introduce new targets (maintenance horror is not about SCM, I'm using git btw).
  2. I'd need to keep in sync all versions of XIBs which would effect in painful change-request process.
  3. I also fear that my app bundle will grow big (currently XIBs use ~1.1 MB and translate to ~120 kB of NIB files).
  4. when I'll decide to do iPad version, the number of XIBs will grow again.

Option B: do the localization in the code by wiring up all needed outlets synthesizing them to properties and setting their labels/titles correctly:

  1. I fear that my app memory footprint will be really big. Or, considering proper mem mgmt, should I not consider this an issue?

I'd go for 2nd option as I see less cons to it and it can allow having everything in one place under control in each view controller, but I'd like to know what would be your choice? Which way works better for you?

EDIT: I know that that ibtool could simplify the process in Plan A, but I'm still not convinced for it.

Upvotes: 9

Views: 798

Answers (2)

matm
matm

Reputation: 7079

Well, I was expecting a little more feedback from SO users, but that's fine as after some research I've made my own decision to abandon option B and go for a modified version of option A.

I've heavily used ideas from a Compile-time approach by Philippe Casgrain. In general it uses ibtool to automatically localize nibs when building. Philippe's approach keeps maintenance reasonably sane for now. All other strings that I use in the code are handled using NSLocalizedString approach which was quite easy to implement in my case (just used genstrings tool). The only issue that can potentially hit me in the future is adding new targets with different/modified UI layouts.

It's hard to say whether it was the best choice. Time will tell, so some day I'll update the question and share with you how the decision worked out for me. Maybe someone will benefit from it in the feature ;)

Upvotes: 1

Kerni
Kerni

Reputation: 15339

I am using Option B in all of my projects, since this also makes it easy for me to distribute the string files to the localizers. Testing is of course needed after that to make sure the strings fit into place. Also some projects do not use XIB files, so the process is always the same, no matter if XIB files are used or not. There is no memory issue with that option at all in my experience.

Upvotes: 3

Related Questions