Well, generally speaking, localization involves a few tasks:
1. Ensuring all text exposed to potential users of the system can be
expressed in multiple languages. In a unix environment, this typically
involves the use of the gettext library, although you can approach this
task in a variety of ways. This task is deceptively difficult, in that
you have to make special considerations for formatted text (e.g. "You have
opted to insert %s into %s.") has to be rewritten so alternative forms of
grammar can be used (e.g. "You have opted to insert %1 into %2.",
replacing %1 and %2 with the correct strings.. this example shows how you
might do this with MFC's CString class's Printf() statement, but gettext
is likely doing something far more elegant).
2. Ensuring all text can be expressed using unicode character sets, so
Japanese and Chinese users can continue to work with the product. In some
ways, this can be trickier than #1 above, in that you have to handle this
not only for the text generated by your own program, but text that comes
in from other sources.
3. Ensuring that all graphics used in your product use either regional
symbols based on the current region, or a graphic set that is generic
enough (and inoffensive) to all regions. This can be difficult, to
impossible, in some cases. Fortunately, our graphics are limited to
WebCit, and customers can replace the icons if they want, but we might
want to consider making it possible for end users to select their
preferred set of icons.
I could delve into #1 more, but I presume most of the programmers here
know about how involved it gets.
For whatever it's worth, I've had to localize the product I work on
several times, and we're still trying to deal with #2 in places.
