Re: [Discuss-gnustep] Localization

[richard]

On Thu, 21 Sep 2000 19:36:33 +0200 (CEST), n.pero@mi.flashnet.it wrote:
> In gettext (used by GNOME, KDE, and most of GNU stuff) a programmer simply
> does:
>
> char *myString = _("Hello World");
>
> instead of
>
> char *myString = "Hello World";
>
> that's all you need to make your app localized ("_" is something - macro
> or function - which expands the string to the version in the current
> locale), a part from calling the gettext initialization at the beginning
> of your app.  I don't remember how this works with not-ASCII charsets.

How about this -

#define _(X)    \
[[NSBundle mainBundle] localizedStringForKey: @#X value: nil table: nil]

or perhaps this would be better -

static inline NSString *_(NSString *key)
{
  return [[NSBundle mainBundle] localizedStringForKey: key
                                                value: nil
                                                table: nil];
}


In the first case you would write _(MyKey), in the second _(@"MyKey")

The first gets you the shortest possible notation, but the second is more 
versatile.

Either would be handily declared in one of the header files (eg NSObject.h)

> Actually, if I have to say it all :), and scandalize everyone with a
> modest proposal, why don't we hack NSConstantString to automatically and
> silently translate every constant string into the current locale.

Not scandalized, and since it's not meant seriously, I won't point out why
it's not a good idea :-)

>  the best would be if we could use _() without
> conflicting with gettext's use of it (sort of overloading it), but I don't
> think it's possible.

I think that putting a macro or static inline function in a header file
should avoid conflict in most circumstances.

I think igorr@crosswinds.net is using NSLocalizedString() for this - so it
seems quite obvious that a wrapper round the NSBundle method is convenient -
and I agree we should extend the OpenStep API to add a standard one for use in
GNUstep (unless Apple have already done this, in which case we might want to
use their extension).

> And then to translate everything into Russian, you just write the
> Localizable.strings file and put everything into Russian.lproj and that's
> it (we still need a better guess of the languages from the environment in
> NSUserDefault but I'll take care of that as soon as I have the time - the
> biggest work is that we probably need a big table translating the ISO
> codes used in gettext to the GNUstep language names).

I suppose that's a good idea if we want to run in a Gnome environment.

> You can also add it to a binary distribution of the program and since you
> don't need to precompile the Localizable.string file, it could even be
> simpler to translate than GNOME stuff where everything has to be
> precompiled into binary form for gettext to read it.  Of course, GNOME
> reads it faster, but I don't think (don't actually know) if it is worth
> the extra efforts it requires to the translators, who are not programmers
> and are often confused by the precompiling process.

The strings files are actually read pretty quickly, and once ready, they are
cached - so I suspect that the disadvantages of a precompiled binary form
outweigh its advantages except in applications with truly *huge* numbers of
text messages.