Localization (summary?)

[richard]

On Fri, 22 Sep 2000 02:49:55 +0200 (CEST), n.pero@mi.flashnet.it wrote:
> 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
>
> _("Save")
>
> (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.

While having a comment (as in NSLocalizedString()) is obviously the best
thing to do, realistically many programmers probably won't bother - so
anything that makes them more likely to enable some sort of localisation is
probably a good thing.

The shortest possible is _(Save) - zero characters overhead on the
unlocalized @"Save" - using the preprocessor facility to 'stringify' the text
inside the brackets.  Unfortunately, stringification imposes some limitations
on what characters the string text may contain (no commas, no backslash escape
sequences, no // or /* sequences, leading/trailing space removed, embedded
whitespace sequences compressed to single spaces).

Next shortest is _(@"Save") - with no such limitations, but I think that the
vast majority of strings would not suffer from the limitations anyway.

If it's a preprocessor macro, _() won't interfere with gettext unless you
include the header that defines it in source code that actually wants to use
the _() function of gettext (and you can always #undef the macro).

Alternatively, we could always use $() instead of _()

I'd advocate the _(Save) form as a shortest-possible convenience, with
NSLocalizedString() used (and encouraged) especially where comments are needed
for clarity, or required where _() has been undef'ed to permit use of the
gettext _() function or where the limitations of stringification are not
acceptable.

Possibly we could have _(Save) and $(@"Save") ?

As for the case where we have tables of constant strings to use in the code
(eg  static NSString *table[3] = { @"foo", @"bar", @"feep" }; )

I suggest that rather than adding another mechanism for localizing static
tables, we deprecate their use in favour of something of the form -

  static NSString *table[3];
  static NSArray *array = nil;

  if (array == nil)
    {
#if LAZY_PROGRAMMER
      array = [[NSArray alloc] initWithObjects: _(foo), _(bar), _(feep), nil];
#else
      /*
       * Use a separate string file (DemoTable) to avoid clashes with
       * other localized text in this application.
       */
      array = [[NSArray alloc] initWithObjects:
        NSLocalizedStringFromTable(@"foo",
          @"A meaningless piece of text", @"DemoTable"),
        NSLocalizedStringFromTable(@"bar",
          @"More meaningless text for demonstration", @"DemoTable"),
        NSLocalizedStringFromTable(@"feep",
          @"How do you localize gibberish anyway?", @"DemoTable"),
        nil];
#endif
      [array getObjects: table];
    }



Then we need to write/improve/standardize the utility (get-local-strings?) to
scan source-code to build lists of the strings needing translation. This
should be built in the Tools area of the base library.

And of course, we should provide some documentation - a guide to localization
in GNUstep.