Re: Gorm Localisation Support

[Jeff Teunissen]

Greg asked me and Stiivi (Stefan) to describe our "proposals" (actually,
ideas) for handling localization with Gorm here. Stefan has already written
his, so here's mine.

What I suggest is a non-public subclass of NSString, called perhaps
"GSLocalizedString", which when decoded will return NSStrings.

The content of the string is the "key" to be searched for in the stringsfile
with the same base name (replacing the original extension with ".strings")
as the archive from which the object was unarchived. Having looked up the
string, it can be returned from the +decodeWithCoder: method (or returned
as-is if it could not be found)

Inside Gorm, each "localizable" string value will have to be marked
specially using a check box, so that it can be encoded as a
GSLocalizedString when the .gorm is saved. On archive save, the stringsfile
containing all localizable strings would be saved alongside the .gorm file.

For languages which do not require special modifications to the UI of the
archive, one would be able to simply translate the strings and save them
into a Language.lproj directory. For those that do require such mods, one
would create a new .gorm (or copy the existing one and modify it) and place
_that_ into the .lproj.

I believe that this method would be pretty straightforward to implement, and
is pretty robust (as well as simple) in design. A potential "gotcha" might
be the requirement for knowing the filename of the archive.

-- 
| Jeff Teunissen  -=-  Pres., Dusk To Dawn Computing  -=-  deek @ d2dc.net
| GPG: 1024D/9840105A   7102 808A 7733 C2F3 097B  161B 9222 DAB8 9840 105A
| Core developer, The QuakeForge Project        http://www.quakeforge.net/
| Specializing in Debian GNU/Linux              http://www.d2dc.net/~deek/