allaire
allaire

Reputation: 6045

iOS app i18n, use key style like Rails?

I was looking for new strategies to manage the localization of my future apps, since my past experiences with localization with objective-c was bad :/

Lately, I've been doing a lot of Rails development, and they use a strategy a bit different. Instead of having the default language directly in the code like in iOS, i.e:

NSLocalizedString(@"Hello World!", @"Welcome sentence on load screen");

Rails use a strategy where a "key" is used in the code, and the default language also has is file with all the translations, i.e:

In code:

<%= t "hello_world" %>

In translation file:

hello_word = "Hello World!"

I was wondering if any of you used a similar strategy but for iOS development? In my opinion it makes much more sense to use as strategy like rails, since the key is general and won't be updated as much as the default language...

But if I do that, I won't be able to use something like that for the nib translations I suppose...

Thoughts?

Upvotes: 0

Views: 156

Answers (1)

Cliff Ribaudo
Cliff Ribaudo

Reputation: 9039

OK... so now your getting into the realm of religion. Lots of people have opinions both ways, but Apple's recommended solution is to put the default language into the Key field. Then it is self commenting to a certain degree and fairly easy to read inline. It also seems to work pretty well with Apples command line tools for extracting language files for translation.

I have used both and find that a mix of both works best for me. When it is something like button text that is used frequently or is short, then the actual text works pretty well. When it is something more obscure or very long like a Message that will show up in a UIAlert or something, I generally use a simpler key that tells me what it is.

Upvotes: 1

Related Questions