Re: Localizing the backend

[Nicola Pero]

> Hi,
> 
> I've recently changed the .nfont package format to (hopefully) support
> all parts of GNUstep font handling (there's a spec of sorts at
> http://w1.423.telia.com/~u42308495/alex/GNUspec/nfont_packages.txt).
> 
> This includes localized font display names, and some should be
> automatically localized (common stuff like "Bold", "Italic", ...; see
> the spec for details). To do this, I need a Localizable.strings for the
> backend.
> 
> It would be easy to hard-code rules to update the .strings files using
> make_strings, but it would be even better if -make could handle it
> automagically :). What's the status of localizing strings for bundles?

The status of localizing strings for bundles is ... it should be done :-)

The suggested way to do it is to re#define _() inside your bundle to be
[myBundle localizedStringForKey:(key) value:@"" table:nil] rather than
[[NSBundle mainBundle] localizedStringForKey:(key) value:@"" table:nil].  
Where myBundle should point to your bundle ... there are various ways to
get it.  bundleForClass: might be one ... but there is a slight risk it
doesn't work on new platforms (eg, I'm still not sure it works reliably on
Windows), you want to make sure that you return (key) rather than nil in
case you can't get to the bundle.  If you can figure out a better way of
getting the backend bundle, it might be nice.  Btw, in some cases the
backend might be a library ... some additional work to do to cover this
case.

Anyway, once you've done this, you can use your make_strings tool to
generate/update Localizable.strings files.

I added a 'make strings' target to all targets containing code/headers,
and by typing that make_strings should be run, and the .strings files
created/updated.  It should work for bundles as well.

I have considered automating this more (that is, having
Localizable.strings (/the required .strings files) for all languages
depend on all the source/header files, and having gnustep-make
automatically run make_strings each time the source/header files were
newer than any Localizable.strings file), and concluded that it would be a
bad idea, because it would execute make_strings very often, and 99% of the
times unnecessarily.  If you're working on your source code, it would be
quite annoying to have make_strings run each time you change a detail in
your source code and recompile.  Continuously running 'make_strings' does
not give you much benefit anyway, since make_strings in itself does not do
the real work: you have to edit the *.strings files manually to translate
the entries, and it's quite reasonable to assume that when you/your
translator decide to do this work and sit down to translate/update
translation of entries, you/your translator would type 'make strings'
first (not a great deal giving this command, compared to the actual
translation work which follows), then go on to actually translate/update
the entries.

Anyway - that's it.  Let me know if it works for you. :-)