views:

53

answers:

1

I wrote my first program almost fifty years ago (yes, coding is still a blast, managing big projects with many programmers was not), but my Von Neumann thinking gets in the way.

I want to (a) load default values and (b) account for multiple languages more elegantly (?) than 60-plus iterations of NSLocalizedString. Can I park all of this data into what amounts to a record with fields like this: (key value stuff), (tweak-able user prompt / screen name / whatever), (tasteful default), (user-supplied value)? NSUserDefault has worked well so far; Core Data looks like overkill (?), and sql lite, well, where's Oracle when you need it?

A: 

It is certainly possible to store this information in plists and make them localizable; right-click the plist in the Groups & Files window -> get info then select 'Add Localization' at the bottom left.

Enter the country code you would like to support and xCode will go ahead and create a language specific version of the resource.

Your code doesn't need to know about any of this since your app will know it supports a language (when you make the file localized) so any plist key value requests that exist already will be mapped to the appropriate value (depending on the current language).

Same applies for your xibs etc.

Personally, I use NSLocalizedString for strings generated inside the code and plists for resources, since it is easier to get the strings I need translated to the translators this way (Can't assume they can edit a plist).

Hope this helps

davbryn
Yes, NSLocalizedString was definitely the way to go. The data storage requirements were so low that I got away with NSUserDefault.Thanks for the help!
d_CFO