Hey, I've extended/refined my original protocol extension idea:
SHOW DB will list all databases in the standard format, including translation dictionaries, but a new command will be added.
xxx - Database list follows.
<<name>> <<desc>> <<charset>> <<language(s)>> <<translation(s)>>
name, desc, and charset are required, translation is added if the database is a translating dictionary. Language tags are seperated by commas(en,fr), and the various properties are stored in the databases(00-database-language, etc). <<translation>> is the language the database translates from, <<language>> is the language of the definitions/entries.
Define & Match commands would be extended WHEN the DB is * or !, I know Rik said he doesn't like special casing, but it makes more sense in this case(IMHO).
DEFINE * <<word>> <<language>> <<sourcelanguage>>
<<language>> is required, it lets you narrow your search to a specific language. If <<sourcelanguage>> is included, then only those databases that translate from <<sourcelanguage>> to <<language>> will be searched. If the language variables are ommited, then all available databases are searched.
This extension would let users do the following....
Search all languages & translations(all databases):
DEFINE * test
Narrow the search to a specific language(translation dictionaries not included):
DEFINE * test en
Narrow the search to a specific translation:
DEFINE * test fr en
Search all languages, but not translations:
DEFINE * test *
Search all translations:
DEFINE * test * *
Translate a word to all available languages:
DEFINE * test * en
Search all databases that translate to a certain language:
DEFINE * test fr *
That's a lot of flexibility... the only combination that isn't possible with the above implementation is the ability to search all x language dictionaries including translations.
Commas could be allowed in queries to allow even more flexibility:
DEFINE * test en,fr
While we're talking commas, why aren't they allowed in database variables?
DEFINE jargon,vera test
Anyway, If someone will implement this extension in their server, I'll gladly implement it in my client(MacDICT).
I don't have the DICT rfc in front of me, and I don't remember exactly how it handles character sets, so the <<charset>> property may not be necessary.