Re: [Discuss-gnustep] Localization

[Nicola Pero]

> You then use NSBundles localizedStringForKey:value:table: method to fetch the
> appropriate localized version for each string you want to localize.

I don't know much about this - but - are there any plans for some simpler
GNUstep extension/front-end to this ?

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.

Anyway, it is so simple I have never seen a GNOME app which
is not-localized (perhaps the translation is missing, but the app can 
use any translation as soon as someone provides it).

Perhaps shouldn't we add some similar trick to the gnustep libraries ? 

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.

That would be programmer-friendly programming: everything you write is
always and automatically localized without programmer's intervention.  It
would even be better than gettext - you don't even need the _(). 

This is a proposal meant more to scandalize than to be taken seriously,
but it sums up what I think should be the aim of localization API efforts: 
complete total silent automatical localization without any programmer's
intervention. :)  IMO OPENSTEP fails in this.  It's much easier to write
single language applications than translatable applications (yes, simply
because in a single language app you just write the string while in a
translatable application you have to call a method with three arguments
each time you use a string), which means the API is not enough
translation-friendly.  But adding a simple front-end to the system - very
well designed in all other respects - should be trivial.

An improvement would already be something like

NSString *myString = NSTranslate (@"Hello World");

which would invoke something returning a localized version of 'Hello
World', and doing the whole stuff.  I think a shorter name for the
function would be best;  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.

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).

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.