[Top][All Lists]

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

Re: [Discuss-gnustep] Localization

From: Nicola Pero
Subject: Re: [Discuss-gnustep] Localization
Date: Fri, 22 Sep 2000 02:49:55 +0200 (CEST)

> > >     I had the idea a while back of creating a command-line tool that would
> > > scan your sources for occurances of this macro, and then create a template
> > > Localizable.strings file to hand off to your translators.  Of course,
> > > Apple beat me too it, as I noticed in their release notes that they have
> > > added just such a tool to MacOS X.
> > 
> > Ahm - yes - forgot that - this is the other thing which gettext has 
> > (and I guess MacOS X has taken the idea from gettext) and which OPENSTEP 
> > lacks.
> Wrong. genstrings  existed at least  since NeXTSTEP 3.3. 
> I doubt that it would be missing in OPENSTEP.

Great - it is missing in GNUstep then :)

Pretty simply, most of you have convinced me that what we already have if
well documented and completed [by writing something like genstrings etc], 
and with a little short-cut inline function, could be quite good  :)

One thing I still miss in the picture.  

Look at the following example, in which I declare 

static NSString *result[2] = { @"yes", @"no" }; 

and then use it at runtime as: 

if (i > 5)
    [button setStringValue: NSLocalizedString (result[0], @"")];
else /* i <= 5 */ 
    [button setStringValue: NSLocalizedString (result[1], @"")];

[This example is stupid, but more complicated examples, very meaningful,
can be built.  It's quite common to put messages into static arrays /
structures while writing apps, so you have all the strings and options in
a single place separated from the code and it is easy to add/remove/change
strings, options, messages, blocks, bundles etc.  Sometimes these kind
of tables could be better saved in property list files, but not always.].

How would a genstrings-like tool know that the strings in the result array
need to be localized ? 

[In gettext there is a special macro for this, expanding to nothing but
being recognized as a marker for translatable strings by the tool.]

And - if one wants a comment with each string from the array, can this be
accomplished ?  The only solution I see is a macro variant of
NSLocalizedString which expands to nothing discarding the comment; it
would have as variant the one without the comment.  But since I don't see
anything of this kind in the gnustep base library I wonder how this would
be managed in OPENSTEP.


And still, we really need to introduce just some very short form of
NSLocalizedString, without the comment.  Something like

static inline NSString *NS_(NSString *s)
  return NSLocalizedString (s, @"");

I can use this definition in my code of course, but everyone will have
this problem (since every single line of code has to be localized), so why
don't we choose a system-wide convention ?

We can't spend time typing 

NSLocalizedString (@"Save", @"No comment")

(35 characters overhead to localize a string)  when what we want to do
is simply to enter the string "Save", while any gnome boy is typing


(3 characters overhead).  It's important considering that *any* string
meant to talk to the user *must* be localized.

Perhaps NS_(@"Save") is not that bad.

reply via email to

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