2

I have my app running nicely and it uses local notifications.

I have decided to internationalize the app now and have everything working just fine except notifications which were set on a language before changing the language on the device.

I populate the messages in the notification from an array which contains localized strings, so I figured that when the user changes the language of the device the string in the notification would also change but I was wrong.

How best to tackle this issue? Should my NSString text also be NSLocalizationString ?

My notification code:

UILocalNotification *localNotif = [[UILocalNotification alloc] init];
if (localNotif == nil)
return;
localNotif.fireDate = [alertTimes objectAtIndex:i];
localNotif.timeZone = [NSTimeZone defaultTimeZone];

NSString *text = [alertText objectAtIndex:i];

// Notification details
localNotif.alertBody = text;
// Set the action button
localNotif.alertAction = @"View";

localNotif.soundName = UILocalNotificationDefaultSoundName;
localNotif.applicationIconBadgeNumber = 1;

// Specify custom data for the notification
NSDictionary *infoDict = [NSDictionary dictionaryWithObject:@"someValue" forKey:@"someKey"];
localNotif.userInfo = infoDict;

// Schedule the notification
[[UIApplication sharedApplication] scheduleLocalNotification:localNotif];
[localNotif release];
Moshe
  • 57,511
  • 78
  • 272
  • 425
zambono
  • 1,397
  • 1
  • 17
  • 26
  • I would like to add that all strings are localizing except local notifications which were created in the previous language. If i send a new notification it will be in the new language, but the old notifications which haven't triggered yet would be in the old. This is a problem most users won't encounter since people don't change their language that often, but those who update to the localize version will. – zambono Jan 06 '11 at 15:03

3 Answers3

1

Should my NSString text also be NSLocalizationString?

Yes, I would do that.

Replace [alertTimes objectAtIndex:i] with NSLocalizedString(@"alertTimes",[alertTimes objectAtIndex:i]). I am assuming that you storing strings in the alertTimes array that match your localized string.

Moshe
  • 57,511
  • 78
  • 272
  • 425
  • 1
    just to clarify the correct way of localizing text would be NSString *text = [NSString stringWithFormat:NSLocalizedString(@"alertTimes",@"%@"),[alertTimes objectAtIndex:i]]; but alas that is not the issue. all strings are localizing except local notifications which were created in the previous language. if i send a new notification it will be in the new language, but the old notifications which haven't occurred yet would be in the old. This is a problem most users won't encounter since people don't change their language that often, but those who update to the localize version will. – zambono Jan 06 '11 at 15:00
  • Yes, it seems that there is not much you can do to change that. I would suggest checking the locale on launch and recreating notifications that were created in the previous locale. – Moshe Jan 06 '11 at 15:21
  • yes that would be the workaround, I figured there might be a procedure in place. – zambono Jan 06 '11 at 16:03
1

Always use localizedUserNotificationString(forKey:arguments:) when localizing local notifications.

The "gotcha" with localization is that the static string from NSLocalizedString would not work well because there is the possibility where the user might switch a language after notification had been scheduled. It would result in the wrong language get displayed in a notification alert.

For example, a notification is scheduled in en-US with English copy string been set, before the notification gets triggered the user switched the language to jp since a static string was generated using NSLocalizedString there is no way it can be changed before notification get triggered.

localizedUserNotificationString(forKey: arguments:) should be used to localize string text for a notification content, https://developer.apple.com/documentation/foundation/nsstring/1649585-localizedusernotificationstring. Where a localized string value is created dynamically from a localized string resource when the notification is about to be displayed.

XY L
  • 25,431
  • 14
  • 84
  • 143
0

Just came across the same issue and found that Apple Docs for UNMutableNotificationContent say to use the NSString. localizedUserNotificationString(forKey:arguments:) function, which defers loading the localized string till the notification shows up. That way the string will be properly localized even if the user changes languages between scheduling the notification and the notification being delivered.

"The strings you display in a notification alert should be localized for the current user. Although you can use the NSLocalizedString macros to load strings from your app’s resource files, a better option is to specify your string using the localizedUserNotificationString(forKey:arguments:) method of NSString. The localizedUserNotificationString(forKey:arguments:) method delays the loading of the localized string until the notification is delivered. Thus, if the user changes language settings before a notification is delivered, the alert text is updated to the user’s current language instead of the language that was set when the notification was scheduled."`

Ben Patch
  • 1,213
  • 1
  • 9
  • 12
  • This seems to rise another issue after iOS 13 and the introduction of per-app Preferred Language. The current behavior of `NSString.localizedUserNotificationString(forKey:argument:)` localizes based on the device language, NOT the app's preferred language. I assumed that since the notification is part of the app content, it should be localized based on the app's preferred language, not the device language. – alobaili Jan 12 '21 at 10:55