Re: Localization

[Jonathan Gapen]

Adam Fedor wrote:
> 
> I didn't realize it was so compilcated. We could split up the work
> somehow.
> 
> system libraries can be localized using GSLocalizedString. I'm not sure
> how that can be worked into the standard method.

   I'm not quite sure why localization needs to be so complicated.  The
three standard functions (macros, really), NSLocalizedString(),
NSLocalizedStringFromTable(), and NSLocalizedStringFromTableInBundle(),
ought to handle all localization needs.
   Of the rest:
   * NSLocalizedStringFromTableInFramework(): Should not be necessary. 
A framework ought to be a type of bundle (a "linkable bundle," if you
will) for which NSLocalizedStringFromTableInBundle() works.  If
frameworks don't act like bundles already, IMHO, they should be fixed to
work that way, rather than adding incompatible functions to accomodate
them.
   * _(): Saves typing, but again adds to the list of GNUstep-specific
features.  Furthermore, this to me seems rather silly.  If you want to
localize your program, you need to hand off the Localizable.strings file
to your translators *with comments*.  If you don't care yet about
localization, why use a macro at all?
   * NSLocalizedStaticString(), and __(): No comment.  The utility of
these functions escapes me.
   * GSLocalizedString() and GSLocalizedStringFromTable():  As I see it,
these functions have limited utility.  The gnustep-base library doesn't
contain any user-interface objects, it communicates directly with the
user when something goes awry.  Ideally, this never happens.  And when
users start apps from other apps rather than the command-line, they
don't see these messages anyway.  Furthermore, NSBundle depends on a lot
of other classes to locate and load the Localized.strings file, so you
can't localize big chunks of those classes.  Much of the gnustep-gui
library is the same way.  Its user interfaces, the panels and such,
eventually will use locale-specific NIBs.

   As for creating the Localizable.strings from the source files, it's
simply a matter of searching the sources for NSLocalizedString()
instances, which a perl script can handle.  What would be really useful,
though, is a library to parse Objective C.  That'd be useful for
creating Localizable.strings, for syntax highlighting in ProjectCenter,
and parsing class definitions in Gorm.  But for now, a perl script would
do.

-- 
All persons, living or dead, are purely coincedental.