Localization in Cocoa

I've dealt with the localization aspects of cocoa, and bundles for a while
now, and am wondering how other people are dealing with them.
The solution presented to us is just request all strings through
NSLocalizedString, add a comment, then when you are ready to create a
localizable.strings file, you just run genstrings to create it. Sounds
simple and basic enough, but I see, and have dealt with a few flaws in this
design. Am I the only one?

-First of all I don't like having full strings in my code. I prefer to just
have variable lookups or defines to access specific strings.
-Second, what happens if you have a full string in your code, and its
missing from the .strings file? You now have a string which looks fine in
your local language, but once its localized, you will find all of these
string which have not changed. There is no warning, or any pre determined
idea that this will happen.
Also there is the situation where you have 2 basic strings, which may differ
by grammar, or by sentence structure, but mean the same thing. Genstrings
will add these seperatly and create great fun for the people translating
your redundant sentences.

What I have done to solve these problems is that I use the NSLocaliedString
code, but I pass is a constant as my string, and then in my .strings file
have the constant refer to the full string. This will eliminate all long
strings in the code, enable you to have easily defined strings, and make is
easier to recognized missed strings in your code. This means that you have
to manage your .strings file manually, but that is the way we use to do it,
and it seems a lot easier, and less hassle this way. To me anyways.

Does anyone else have any tips, or suggestions.
Am I the only person who thinks this solution needs a little additional work
just to finish it off?

TRJ

Tim R Johnson wrote:
> I've dealt with the localization aspects of cocoa, and bundles for a
> while now, and am wondering how other people are dealing with them.
> The solution presented to us is just request all strings through
> NSLocalizedString, add a comment, then when you are ready to create a
> localizable.strings file, you just run genstrings to create it. Sounds
> simple and basic enough, but I see, and have dealt with a few flaws in
> this design. Am I the only one?

nope! i think it's hideous. i also think it's pretty dumb that you
have to create a separate set of .nibs for each localization. if you've
got a bunch of them, the slightest change is going to become a
maintenance nightmare. the cocoa localization scheme is easy to use for
small programs, but gets harder and harder as projects become more
complex.

this subject has come up before here, but no one has any solutions. how
could they? you'd have to go against the grain of apple's way of doing
things and reinvent quite a few wheels. that hasn't stopped a few
people from trying ...

cross-platform gui toolkits are up against this same problem, but in a
slightly different way. consider wxWidgets, for example (formerly known
as wxWindows). their aim is to let you compile one codebase for
multiple platforms, including the mac and ms-windows. obviously,
interface builder and macosx's localization scheme are off limits to
them. i only briefly examined wxWidgets before deciding that it wasn't
for me, but i'm pretty sure they store window definitions in XML files,
and there are various interface-builder-like cross-platform tools you
can use to lay out your windows. they get around the multiple .nib
problem by using one XML window file for every language, but forcing
every control and view to grow and shrink as necessary to accommodate
however much text it holds. apple should have done something like that
as well.