Re: base library Localizable.strings

[Nicola Pero]

> > But work on this has already been initiated in the base library, except
> > the file is called Localizable.strings - this doesn't look right, because
> > the gui library will have its own file and it must go in the same
> > directory - so I would rather call them something like
> > 
> > BaseLocalizable.strings
> > GuiLocalizable.strings
> > XgpsLocalizable.strings
> > 
> > or something similar (suggestions welcome).
> > 
> > Can I rename the base library Localizable.strings to
> > BaseLocalizable.strings ?  Any reasons why I shouldnt' ?
> > 
> 
> It's tough because we don't have the libraries stored as frameworks.

Yes - hmmm.

The problem is we can't reasonably turn the base/gui libraries into
frameworks, because frameworks are too complex and too difficult.  They
would be broken once every couple of days, while we want them to be as
stable as possible.  I often wished we didn't have frameworks in
gnustep-make because of their complexity and the complexity of the rules
to build frameworks :-)

The other reason is that a framework is meant to contain a shared library,
while we want to keep the ability to build gnustep-base as a static
library.

I think what we might do is, we implement/use some sort of new
`lightweight framework' support for gnustep.  We use that in gnustep core
libraries - for other libraries other people can do what they want - use
standard frameworks, lightweight frameworks, normal libraries + bundles,
or whatever they want.

A lightweight framework means that we just associate a bundle with a
library in some standard way.  For example, the base library bundle might
be in

$GNUSTEP_SYSTEM_ROOT/Libraries/Bundles/gnustep-base/

the gui library bundle might be in 

$GNUSTEP_SYSTEM_ROOT/Libraries/Bundles/gnustep-gui/

(the bundle name being simply built from the library name,
libgnustep-base, by removing the `lib').

We add to NSBundle a new API,

[NSBundle bundleForLibrary: @"gnustep-base"];

which returns the gnustep-base's bundle (simply, by searching for 
$GNUSTEP_USER_ROOT/Libraries/Bundles/gnustep-base, then for
$GNUSTEP_NETWORK_ROOT/Libraries/Bundles/gnustep-base, then for
$GNUSTEP_LOCAL_ROOT/Libraries/Bundles/gnustep-base, then for
$GNUSTEP_SYSTEM_ROOT/Libraries/Bundles/gnustep-base, and returning the
first match).

This is enough to implement cleanly separated localization for the
different gnustep core libraries.  It will still perfectly work with
gnustep-base compiled as static.  It doesn't depend on nothing we don't
depend on yet - so it will work reliably.  If we want to make it extremely
complete, we can add some very simple code to library.make so that you can
specify resource files in a library, in the same way as you specify
resource files in a bundle, and library.make automatically installs them
in
$GNUSTEP_INSTALLATION_DIR/Libraries/Bundles/library-name-without-the-lib
when you install the library.  (at this point, our libraries are similar
to frameworks - they contain resources stored in an executableless bundle
- but incredibly simpler - that's why I'd call them
lightweight-frameworks).

Of course, it does not completely answer your question about how external
developers might access the resources for the libraries - well I'm quite
happy it doesn't answer your question, because I think the resources of a
library are *private* to the library and shouldn't be accessed by the
external code :-) unless the library *itself* provides an API for them to
access the resources.

Which is precisely what happens with FoundationKit and ApplicationKit - in
your example, if you want to localize the string NSASCIIEncoding in a
third-party code, you should *NOT* try to access the private Foundation
Localizable.strings mapping table - you should instead use the public API

+ (NSString *)localizedNameOfStringEncoding:(NSStringEncoding)encoding

This is absolutely obvious.  Internally, the gnustep-base library
implementation will access its own bundle, get the appropriate file from
there (which might not necessarily be Localizable.strings, for the simple
fact that the gnustep-base authors might decide to organize the
translation tables in different files in each release or perhaps - just an
absurd example just to explain the point - on another system where the
operating system or glibc can provide the translation itself, drop the
bundle tables at all and ask the operating system or glibc directly to
perform the translation) and send you the translation.  If you access the
translation using the public API, you don't have to worry about the
internals, you're safe when the internals of the library and the
management of resources in the library change.

Similarly - other example which comes to mind - for [NSImage +imageNamed:]
- if you want GNUstep.tiff, you shouldn't be attempting to get the
ApplicationKit bundle and trying to extract the image from wherever it's
stored inside the bundle - that's *private* to the ApplicationKit - you
should use the public API +imageNamed:, and that will internally get the
required resource from the appropriate private internal bundle (also
because privatish hackish stuff might be done inside the library - for
example the actual filename of GNUstep.tiff might be anything - for
example GNUstep-dark.tiff in one version and GNUstep-light.tiff in another
- and mapped internally to the name GNUstep in both versions in the public
API).

If you still want to access the internal resources at all costs, you can
use [NSBundle bundleForLibrary: @"gnustep-base"] to get the bundle.  If
you want your code to be portable to MacOS-X, you would do 

 NSBundle *bundle;

#ifdef GNUSTEP
 bundle = [NSBundle bundleForLibrary: @"gnustep-base"];
#else
 bundle = [NSBundle bundleForClass: @"NSString"];
#endif

I seriously doubt that will work anyway, because I'm pretty sure internal
resources (such as localizable string files) are different between gnustep
and MacOS-X system kits.  I would be surprised if they were the same.

`Lightweight frameworks' are not real frameworks, so +bundleForClass:
wouldn't work for them, and they wouldn't be listed in +allFrameworks:.  
I don't think this is a particular problem.

Well - I'm very tired today - have been coding intensively in these days -
so I'm not sure it all makes sense might be all crap :-) but if you like
it, and if I still like it tomorrow when I'm up again :-) I might likely
implement all this in half a day.

> At least you'll have to change the table name internally in the base 
> library (like in NSString.m).
> 
> I think it would be rare for a developer to access the base/gui/etc 
> licalized strings, but it could happen. I don't know how to handle that. 
> Perhaps when someone tries to get the localized strings for a particular 
> "framwork", NSBundle would internally translate the table to the correct 
> one, e.g.
> 
> str = [[NSBundle bundleForClass: [NSString class]]
>                      localizedStringForKey: NSASCIIStringEncoding
>                                      value: nil
>                                      table: nil]
> 
> would get the correct table (BaseLocalizable.strings).