discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem localizing GWorkspace


From: Nicola Pero
Subject: Re: Problem localizing GWorkspace
Date: Sun, 2 Sep 2001 10:53:46 +0100 (BST)

Enrico> Now it compiles and the resources are copyed into the bundle directory.
Enrico> but it doesn't work.
Enrico> It uses only the English strings...

Argh - the problem is that NSLocalizedString (and so _()) will use
[NSBundle mainBundle] to get the translation from the string - the
main bundle will read the main xxx.app directory, and get the string
from the appropriate Localizable.strings file there.

Instead, what you want is - you want the code in your bundle to read
the translations from the Localizable.strings in your bundle.  To do
that, use NSLocalizedStringFromTableInBundle (), using as bundle the
bundle which has loaded your code (you can get it for example using
[NSBundle bundleForClass: myClass], where myClass is one class in your
bundle).  In the implementation of a method of a class in your bundle,
you can also do something like -

NSLocalizedStringFromTableInBundle 
  (@"Box Contents", nil, [NSBundle bundleForClass: isa], @"")

This should work, but I agree it's cumbersome :-) it's very long
typing and annoying to do for each string ... I wonder if there is
something the library might do to help you ... as it is going to be a
common problem - every bundle code will want to look up translations
in its own tables ... Any suggestions ?


As a private hack, you could always redefine _() at the beginning of
your bundle code so that it is something like

#undef _
#define _(X) NSLocalizedStringFromTableInBundle (X, nil, [NSBundle \
                               bundleForClass: [myClass class]], @"")

(of course use this code after including Foundation/Foundation.h)
(replacing myClass with a class in your bundle), and then you can
still use _().



reply via email to

[Prev in Thread] Current Thread [Next in Thread]