Re: Localization

[Nicola Pero]

> > Ah ah - alarm bell - `rather silly' ? - nobody is forcing you to use it.
> > Don't use it if you don't like it.  It's just a trivial macro,
> 
>     Yes, that's true, but does it have to be part of GNUstep?  

Well - the problem is I think everyone will have to use a macro of this
kind, as I don't believe programmers will replace each string with
`NSLocalizedString (xxx, nil)' - it's too long.  If everyone uses a
different macro, then it's more difficult to read other people's code and
exchange code between applications.  Having a single cross-program macro
should make it simpler to pass from one program to another one.  If you
want to port your application from gnustep to macos-x, then you add
`#define _(X) NSLocalizedString (X, nil)' at the beginning, inside a
#ifdef THE_MACRO_WHICH_IDENTIFIES_MACOS-X. 


> I took a look at gettext and found that it uses the _() macro, too.  

Yes - that's why we use the same name - so that people coming from gettext
understand immediately what the macro does.


> it could also mess with gettext.

You can #undef the macro before including gettext headers if you ever need
to use gnustep + gettext. 

We could change the name of the macro to $() as Richard proposed, only
that would make the meaning of the macro more obscure - and perhaps it
will conflict with something anyway.


> > >    * NSLocalizedStaticString(), and __(): No comment.  The utility of
> > > these functions escapes me.
> > 
> > Ok - take for example GSTest.
> > 
> > There is a list of bundles - each bundle contains a test.  This list is
> > displayed in a submenu.  Now the list is contained in a file, testList.h.
> > Code in another file loads the list - which is a statically allocated
> > array - and builds the menu from the list.  For each entry, it reads from
> > [...]
> > How do I translate this ?
> > 
> > The answer is - pure openstep can't do that - but gettext can.
> 
>     I believe there's a pure OpenStep way to do it:  Make your test list
> a property list inside the app bundle, instead of a statically-allocated
> array.  That way, not only can you localize the property list, you can
> vary the list of tests without even touching the program source code.

That's a good point I think.

I suppose the property list would be something like - 

(
 {
   MenuName = "Cut & Paste";
   Bundle = "CutPaste-test";
 },

 {
   MenuName = "Keyboard Input";
   Bundle = "KeyboardInput-test";
 },

 {
   MenuName = "NSBox";
   Bundle = "NSBox-test";
 },

 ...
)

The translator then has to translate the property list too - but not all
entries, only the `MenuName' entries.  Actually he has to understand that
the strings `MenuName' and `Bundle' need not to be translated, nor the
values for the `Bundle' entries, but only what comes after each of the
`MenuName ='.  I suppose he is supposed to look at the source code to
figure this out.

Gettext instead has the approach that the only thing the translator needs
to do is take the list of strings to translate (the equivalent of the
Localizable.strings file) and translate them.  It's a standard operation. 
Once that is done, the program is translated.  He never sees code nor a
different file format - because the format of the file with the list of
strings to translate is the same for all programs.  This way, a person who
is *not* a programmer can easily translate a program. 

Instead, the approach you suggest - using extensively external files in
custom formats for each set of static strings the programmer needs to keep
- means the translator has to translate not only the Localizable.strings
file, but also various files in different custom formats.  Again - for
example in my case the translator needs to translate this test list, in
which he needs to translate the MenuName values but not the Bundle values,
and of course not the `MenuName' and `Bundle' keys.  That seems trivial to
you and me - I'm not sure how much trivial it is for a translator, who is
not a programmer and doesn't understand the code which reads the property
list and uses it.  If each application has just four or five files each
one in a different format and to be translated (but only partially!) in a
different way, then it gets complicated.  Moreover, to keep up-to-date
your translations, you need to do it by hand - by comparing the old
translated property list with the new property list to translate, and
figure out by hand what you need to change.  That's a real hassle - even
for a programmer which uses diff (you can't diff the old translated
property list with the new property list to translate) - not to speak of
the poor translator which can't use diff.  While - if we had all
translatable strings put into the Localizable.strings file, which is
always in the same format, then we could have a standard tool which can
merge the new strings to translate into the old translation file - and you
only have to open the merged file and translate the missing strings.  Then
we would write a GUI front-end to that and anybody can translate anything.

I believe OpenStep's localization facilities are not up to the standard
gettext GNU ones.  This based on pure experience - that looking on Peanuts
for an example of a nextstep application which was translated in any
language different from English, I could find very few if any - while
*any* normal GNU program is translated at least in a dozen of languages -
and usually many more.  I think gettext being so much easier to use - both
for the programmer and for the translator - is one of the reasons.  The
other reason of course is that OpenStep requires you to create a new NIB
for each new language - which is actually the same problem - and is
precisely related to the approach you suggest - for each resource the
application uses, to make the translation you need to edit a different
file with a different syntax/format - in the case of NIBs the format is so
different and complex that you need to edit it with a programming tool! -
an approach which IMHO is very inappropriate and makes translating and
keeping translations in sync very difficult.  I have no idea how could you
quickly update a translated NIB when some string in the original NIB is
changed as diff won't help you by no means.  But - at least for NIBs I'm
sure we'll be able to add an extension to Gorm to make it overcome this
problem and keep a single NIB and have all the strings in the NIB looked
up at run-time in the translation table (and widgets properly resized
accordingly).  Of course - you don't need to say it - I know you don't
like this proposal as apple does differently - it will be disabled by
default so that you can happily spend days creating and updating manually
tons of new NIBs for each language you translate into.