Plug-in localization
Normally when developing a Cocoa application you use the NSLocalizedString
macro for any text that is presented in the UI. When you're ready to add support for a second language, it's easy to run the genstrings tool and produce a file full of strings ready to pass to your localizer.
Localizing Sandvox plug-ins is pretty similar, but with one crucial difference. NSLocalizedString
assumes all strings are located inside the main bundle. When developing a plug-in, this is most definitely not the case.
So, as a convenience we provide the similar SVLocalizedString
macro for UI strings. For example:
- (NSString *)placeholderString { return SVLocalizedString(@"Please set me up using the Inspector", @"placeholder"); }
It's as simple as that! When you're ready to add another language, run the genstrings tool against your plug-in source:
genstrings -s SVLocalizedString /path/to/plugin
Site-Localized Strings
Sometimes your plug-in may be generating text as part of its HTML for publishing, rather than UI. If so SVLocalizedString
would use the wrong language. Instead, you have to jump through an extra hoop:
[[NSBundle bundleForClass:[self class]] localizedStringForString:@"My String" language:[[context page] language] fallback:SVLocalizedString(@"My String", "test");
The string will be presented in the best possible language. By having SVLocalizedString
in there as the fallback, genstrings
is alerted to the need for localising the string.
HTML Template
It's also possible to access localized strings from HTML Templates:
[['This is a string in the user's language]] [["This is a string in the site's language]]
You'll need to prompt genstrings to spot such strings though. We've found it's best to do so by adding fake declarations to your plug-in's .m file like so:
// SVLocalizedString(@"This is a string in the user's language", "test"); // SVLocalizedString(@"This is a string in the site's language", "test");