Looking for advice on multiple language spell service installation

[Wolfgang Lux]

After committing a set of changes that extend GNUstep's spell server  
to support multiple languages, I'm looking for advice on how GSspell  
should properly announce its service.

By default, users will see only the dictionary for AmericanEnglish in  
the Spelling panel. To make dictionaries available for other  
languages supported by aspell, users (or rather an administrator)  
must change the NSLanguages key in GSspell.service's Info- 
gnustep.plist. Apparently, this is not really a workable solution, in  
particular since the change would have to be repeated whenever -gui  
is reinstalled.

The current state could be improved in two ways:
1) Have GSspell.service update its own Info-gnustep.plist to match  
the list of aspell's available dictionaries if it is run with a  
special command line flag.
2) Create a GSspellService.plist file in the user's Services  
directory and have it announce the additional languages besides  
AmericanEnglish.

Of course the first solution still requires administrator privileges,  
but I think this could be acceptable if GSspell.service is  
automatically run with the appropriate flag in a post installation  
phase. However, I'm not sure whether this works well for package  
installation, so I'd appreciate if any package maintainer who is on  
this list could comment on this.

Unfortunately, neither of the two approaches works at present in  
GNUstep. The first approach fails because GSspell.service is unable  
to locate its own info dictionary [1]. The second fails because the  
spell checker would attempt to start an executable in the user's  
Services directory for the additional languages, even when I  
explicitly set the executable path in GSspellService.plist.

Before starting to work on either implementation, I'd appreciate to  
receive comments on which solution you consider better. Or maybe I  
have been overlooking something completely obvious.

Wolfgang

[1] NSBundle currently uses a special case to locate the Info.plist  
file in application bundles and restricts this case to a few well  
known extensions. Of course, I could easily extend this list to  
the .service extension, but this feels just like a stop gap measure.