Re: [Discuss-gnustep] Localization

[Nicola Pero]

> > How would a genstrings-like tool know that the strings in the result array
> > need to be localized ? 
> 
> If I remember  well, genstrings would not work very  well with such an
> example. (get-local-strings won't work well at all).
> 
> The localization MACROS (are not functions) do not work this way:
>      NSLocalizedString (result[0], @"")
> 
> They  have   a  double  semantic,  being  processed   twice,  once  by
> genstrings, and once by the cpp. By genstrings, they are mere tags for
> their arguments,  to let genstrings extract  them and put  them in the
> strings file.   By cpp, they send a  message to some bundle  to do the
> localization of the key string.  (Which is done using the strings file
> generated by genstrings).

OK - but - gettext *is* doing it - it must be possible - and actually 
I have a very clean solution.  

The final syntax would be something like: 

$(@"Save")  --> the shortest and fastest way to localize 
                a commont string.  *Every* string which is
                meaningful to be localized should always 
                be at least as localized as this.

NSLocalizedString (@"Save", @"Let the user save the file to disk"); --> 
                the longer but better way of localizing a string, to be 
                encouraged and used whenever possible.

other OPENSTEP functions --> power programmers will certainly benefit from
                             them whenever they need.

$$(@"Save") --> the shortest and fastest way to localize a static string. 
                The string variable still has to be passed to $() when
                used.

NSLocalizedStaticString (@"Save", @"Let the user save the file to disk");
                         --> the longer but better way of localizing a
                             static string.

Not sure if it worth or needed to add longer macro variants of these.

All the macros (at least certainly $$ and NSLocalizedStaticString has to
be a macro) would be defined in the same file say LocalizedStaticString.h. 
This file is protected as usual by a define, something like

#ifndef __NSLocalizedStaticString_h_GNUSTEP_whatever_we_use_here
#define __NSLocalizedStaticString_h_GNUSTEP_whatever_we_use_here

#define $$(X) X

#endif

When we run the preprocessor (ie, gcc -E) during the genstrings stage, we
pass -D__NSLocalizedStaticString_h_GNUSTEP_whatever_we_use_here as a
compiler option - this will prevent the NSLocalizedStaticString.h to 
be included.  The macro $$() will not be expanded, and our genstrings-like
tool can look for strings inside $$() and add them to the file of strings 
needed for translation.  [When genstring finds $() or NSLocalizedString 
with an argument which is not a constant string, it ignores it.]

When you compile the program instead, $$() is expanded to do nothing 
on the string and everything runs fine.

In that way, programmers who want or need to use statically initialized 
strings can simply do 

static NSString *array[3] = { $$(@"Graphics"), $$(@"Code"), $$(@"Support") };

and then use it as simply as in 

for (i = 0; i < 3; i++)
{
  doSomethingWith ($(array[i]));
}

This is very similar to gettext, but I really think this is one of the
best features of gettext so there's nothing bad in taking it.

Porting to apple is trivial, people just add 

#define $$(X) X
#define $(X) NSLocalizedString(X, @"No comment available");

Am I missing something ?

> Since localization is  needed mainly for natural language,  we need to
> add a  comments to all localizable  string to let the  translator do a
> good job.  Well, you, as a programmer  may not feel the  need, but the
> translator would miss them terribly.

I perfectly understand your point, and I think we should encourage
programmers to add comments.  But in real world programmers do what they
like, so it's sometimes better to have them localize strings without
comments with a trivial syntax which is so easy that everyone will use it
rather than have them localize nothing.  Gettext has won his battle here,
because completely everything is completely localized.  I think the
trivial syntax _() which any programmer just learns in no time and
requires no time to use was part of the winning mix.