Localization is not working for pt about nsdate-timeago

[kevinlawler]

Could this be a pt versus pt_BR issue maybe?

[phelipemaia]

I don't know. What would you suggest @kevinlawler?

[phelipemaia]

Should I need to set anything else?

[Cellane]

Hmm, the bundled localization isn't applied for me either, actually, although in my case it's the Czech localization that should be loaded. Since I'm not really experienced when it comes to the NSBundle class and bundles in general, I tried pretty much everything that seemed even slightly relevant to the issue to me, including changing the “Localization native development region” property in the Info.plist file, changing the device's system language (tried in both Simulator and on real device), toying with the NSDateTimeAgoLocalizedStrings(key) macro, but with no result.

Is there some step I'm missing? From my little “research” it almost seems that this line of code (line 11 in NSDate+TimeAgo.m isn't doing what it's supposed to do:

[NSBundle bundleWithPath:[[[NSBundle mainBundle] resourcePath] stringByAppendingPathComponent:@"NSDateTimeAgo.bundle"]]

Toying with the Simulator showed that the NSDateTimeAgo.bundle copies successfully to the application bundle, but it just doesn't get loaded.

Oh, and last thing to mention, I'm of course using CocoaPods to install NSDate+TimeAgo.

[kevinlawler]

@phelipemaia @MiLoSo

When localizations were moved inside the NSDateTimeAgo bundle (instead of being loose in the app bundle) they were no longer included in projects by default. The upside of this was that if you didn't want a localization supported, it wouldn't be triggered by this library. The downside was that if you wanted time values translated for locales by default, translation was no longer triggered simply by adding NSDate+TimeAgo to your project. It may be possible to get the best of both worlds here. That work has not been done yet.

In the meantime, you can likely solve your problem by manually enabling localization for your preferred language. I believe there are several ways to do this. One way is by going to Project -> Info -> Localizations and adding an entry for the language there. It does not matter what the contents of the entry are. This will cause, say, a cs.lproj or pt.lproj directory to be added inside both the project source folder and in the resulting .app package when the project is built. Apparently, the presence or absence of an lproj folder is what determines whether or not a localization is supported.

For testing purposes, you may also want to edit the main call in your main.m file to include the following, after the initialization of the autorelease pool, but before UIApplicationMain

[[NSUserDefaults standardUserDefaults] setObject: [NSArray arrayWithObjects:@"pt", nil] forKey:@"AppleLanguages"];
[[NSUserDefaults standardUserDefaults] synchronize];

where @"pt" is your desired language. This will cause localizable strings to appear in the designated language. The above snippet will require relaunching the app. It is of course not suitable for production release.

[trymbill]

This fixed my issue. Thanks!

[Cellane]

Ha, that worked wonderfully! Thanks a lot for the advice (and apologies for belated reply, too many things demanding my time and attention lately and I just got to trying your suggestion now).