Localization
Posted May 29th, 2004 @ 02:19pm by Erik J. Barzeski
Localization: something that's both incredibly easy and incredibly frustrating.
Incredibly easy: wrap all UI-bound strings in NSLocalizedString(), provide a .strings file, and localize your NIBs
Incredibly frustrating: coordinating all of the incredibly easy steps above
I've yet to find a good software package to help with the localization project. Sure, there's Polyglot and PowerGlot. We've also got nibtool, strings, and genstrings.
PulpFiction has nearly 300 UI strings in code alone, not counting those in nibs (menus, buttons, etc.). We have about 20 NIBs. We've got a few hundred connections. I'd consider this an average number of strings for an application of its size.
I'd pay $500 for a tool that made this whole process simpler: extracting strings from my nibs, putting them in, coordinating localizations, scanning the code for additions or changes, and so on. The tool doesn't exist. PowerGlot has a few good points, but I don't do Carbon development and I don't want to pay $3000 for a worldwide license. You can "roll your own" solution with the various other tools out there… but it's just messy.
Until someone fills the niche, I guess we'll do the best we can with what we've got.
Donate Life
Posted 29 May 2004 at 3:05pm #
You may have a look at our Localization Suite any comments or suggestions are welcome.
David
Posted 31 Oct 2004 at 11:39pm #
Uh.. sometimes localization may not be easy.
For example, mlnet core gives you some strings which can be English, Korean, Japanese, and so on. To display the screen with some GUI frontend, it should be possible to determine what encoding a retrieved string, ie. search result, file names being downloaded, and so on, has.
However it seems to me that there is no such way to determine it.
Then..................
How to do it? Even the Unicode web site, http://www.unicode.org, mentions that there is no way to determine if a given string is written in Chinese, Korean, or Japanese.