I'm working on a Mac Cocoa project at the moment and had to deal with localization - something that has to be done but sure isn't fun.
Localization isn't that hard though when using Cocoa: Enclose your localizable strings in a call to the NSLocalizedString macro and run genstrings over your files.
When you have a string like @"I think this is a long string" somewhere in your source code and you want to localize it using NSLocalizedString, you might not want "I think this is a long string" to be the key in the strings file. What I do is this:
NSLocalizedString(@"LONG_STRING", @"I think this is a long string")and then I run genstrings over my source and end up with this in the Localizable.strings file:
/* I think this is a long string */ "LONG_STRING" = "LONG_STRING";I actually want "I think this is a long string" to be the value and not "LONG_STRING". That's why I wrote a small Python tool that takes care of this and uses the comments as the values.
pyGenstrings coverts such files to look like this:
/* I think this is a long string */ "LONG_STRING" = "I think this is a long string";That might come closer to what you want...
Download pyGenstrings here: pyGenstrings.py
Comments
Jordy said...
Saw your post on CocoaDev...what you might want to do instead is reverse your order: NSLocalizedString(@"I think this is a long string", @"LONG_STRING"). Why? If NSLocalizedString doesn't find the Localizable.strings table, it will default back to the first argument. And because you're using the second argument as a description of the string, and not the value, there is no real problem, and this comment (LONG_STRING) is what will appear in each of the localized files. Of course, if you preferred the comments to be native-language versions of the localization, that's another story. But in any case, there's no reason to bring a not-so-useful "variable name" string into it.
July 16, 2007 07:01 AM
Anonymous said...
The link to your pyGenstrings script is broken. Do you have an updated link?
December 13, 2008 05:54 AMThanks