1

I was wondering if I could define a dictionary of key/value pairs to use as my language localization strings at run time in an ios app. The current method of changing language localization setting depends on an appropriate strings file being defined in the bundle when the app is initially built.

So instead of saying something like

NSLocalizedStringFromTableInBundle(@"Greeting", nil, localeBundle, nil);

Say something like

NSDictionary *myDictionary = [NSDictionary dictionaryWithObjectsAndKeys:@"Hello", @"Greeting"];
NSLocalizedStringFromTableInBundle(@"Greeting", nil, myDictionary, nil);
teddy777
  • 661
  • 8
  • 20
  • Why don't you just build up your dictionary and use it? – lupz Apr 03 '14 at 12:22
  • I have my dictionary - I want some way of globally setting the app to use it. – teddy777 Apr 03 '14 at 12:26
  • To clarify my dictionary is an unknown at compile time - I request it via a rest call on app load. This is where I want to then set my localized strings – teddy777 Apr 03 '14 at 12:33

1 Answers1

1

Haeder

#define MyLocalizedString(key, dict) \
  [LocalizationUtils localizedStringWithKey:(key) fromDict:(dict)]

@interface LocalizationUtils : NSObject

+ (NSString *) localizedStringWithKey:(NSString *)key fromDict:(NSDictionary *)dict;

@end

Implementation

+ (NSString *) localizedStringWithKey:(NSString *)key fromDict:(NSDictionary *)dict
{
   NSString *localizedString;
   if (!dict) {
       // use NSLocalizedString or sth as a fallback.
       // ...
   }

   // get your string from dict

   return localizedString;
}
lupz
  • 3,620
  • 2
  • 27
  • 43
  • Thanks for the quick reply - give me a sec while I implement this! – teddy777 Apr 03 '14 at 13:32
  • So yes this does in effect allow me to use my dictionary defined key/values however I was hoping for a more "global" solution, that would mean using `NSLocalizedString` as usual but somehow 'tricking' the application to use my dictionary as its strings table. This method would mean modifying every use of `NSLocalizedString` to `MyLocalizedString` – teddy777 Apr 03 '14 at 14:07
  • What's the problem with replacing the calls? Special functionality -> special calls. The other way you could try to redefine the original macro or replace the original implementation of `[NSBundle localizedStringForKey:value:table:]` through a category. But I would not suggest that. – lupz Apr 03 '14 at 14:59
  • Haha I was just looking at subclassing NSBundle to try and do it 'globally'. So yes I think I agree with you - wrapping my own function that then falls back to the default string values does seem a reasonable solution. I did come across [this](http://stackoverflow.com/questions/6075158/can-strings-resource-files-be-added-at-runtime) SO question and answer that says largely the same things as you've said. Thanks for the help. – teddy777 Apr 03 '14 at 15:08
  • Overriding the standard NSBundle method you can also intercept storyboard's strings, without the need to set an outlet to every single localisable interface element. Can be useful. – MacTeo Jul 29 '15 at 15:18
  • @teddy777 Probably better to define a macro like this:#define MyLocalizedString(key, comment) \ [Utility localizedStringForKey:(key) withComment:(comment)] Then you can write a method in some Utility class that returns the string from the dictionary. Macro is defined in .pch file – tentmaking Jul 02 '16 at 14:35