Re: [dict-beta] RFC - 2229: Suggestions for Update

Gaurav Vaish <[email protected]> Wed, 16 Mar 2005 13:22:55 +0530
Newsgroups gmane.comp.web.wml
Message-ID <[email protected]>
> It is possible to create so called virtual dictionary.
> In particular, dictd is capable of doing this.

  How is it done? It's the first time I'm hearing of "virtual
dictionary". How do I direct the server to check on Engligh-US or
French-France dictionary?

> Select German-English virtual dictionary or configure your DICT client
> to select only specified list of databases.

   Same comments as previous.

> First, you should learn what your DICT server provides ;).

   The client is "looking for the words spidering across dictionaries"
- something like what you find at websites like dictionary.com: Main
result + references / sitings from other dictionaries.

>  GV> selected all German databases?
> I think yes, it not a problem of protocol, but the one of DICT client
> or server.

   I think an enhancement can be (read: should be) done in the
protocol. I would, in new scenario, select the German language (de_DE
locale) and issue a "DEFINE ! word" command.

   Why do you want the client to first issue a "SHOW DB" and then
"DEFINE <db> word" for all DBs? Is that efficient?

   I consider it - "a protocol problem" rather than the implementation.

>  GV>    Infact, this very point gives me another idea - searching for a
>  GV> word in locale L1 but want to have the meaning in locale L2.
> This a client-side problem. I don't see any reason to implement
> such sorts of tasks on the server-side.

   There is. Check my example below. I am looking at dictionary as not
only for the people who already know the language and want to improve
vocabulary but also to those new in that language.

   Well.. I'm trying to expand the scope of the dictionary -- the
usability, the reach.

> The simplier server is, the more ways to make it faster.

   The more facilities the server has, the more usage and outreach it
has. Speed is not a problem today. A 3.2GHz machine with 1GB RAM,
100GB diskspace is dirt cheap.


>  GV> say, "amor". German dictionary will explain it in German words, but
>  GV> what I am looking for is the English word "love".
>  GV>    Is this facility available in current specs? Or is there some kind
>  GV> of workaround?
> Your client should be UTF-8-aware to allow you to enter and see
> both german and english symbols. I don't see any problem here.

   The problem is not with symbols but the locale.
   I said - I want the meaning of a foreign-language word in my
mother-tongue. Is there a way the current specs can achieve this? I
think - NO. Again... the language and not symbols.

   The symbols may be restricted to only Roman English symbols (ASCII
to be precise), but not the language.

>  GV>    Also, here's another possibility that came to my mind -- I am
>  GV> looking for a medical term, in German and you are looking for a
>  GV> medical term in French. Should the server have two different databases
>  GV> like "de_DE_Medical" and "fr_FR_Medical"? Or does it make more sense
>  GV> to first select the locale and then select the Medical database?
> If a dictionary contains headwords in different languages
> it is very bad dictionary. Don't use it or ask DICT server administrator
> to separate it into two independent dictionaries.

   And then search for individual dictionaries? Across all languages?

   Give me the solution to the above problem. How will I tell the
server that it should look in the German dictioanry and, in French
dictinary for you? How will the two clients select the databases?

   Please don't tell me that the client should select it appropriately.

> Despite efficient data structures,
> efficient DICT server
> should be based on event-driven logic.

   And that's what these locales, charsets etc extensions are all about.

>  GV>   You'll notice all references at the end of the page, after all
>  GV> definitions. How does the client handle it? I think there should be
>  GV> enough space created by the server for the client to play. :-)
> 
> As far as I understand all this stuff are client-side features.

   How does the client identify (programatically, not manually) where
the meaning ends and the corss references start?


   To reitereate in other words -- the current dict implementation is
totally flat. You have to search in databases / dictionaries. Period.

   I want to make it hierarchial whereby you can choose the
word-locale and meaning-locale (to start with), charset etc...


  btw, I heard no remarks on the new URL style? ;-)


-- 
Cheers,
Gaurav Vaish
http://www.mastergaurav.org
http://mastergaurav.blogspot.com
--------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

_____________________________________________________________________
Website META Language (WML)                         http://thewml.org
User Support Mailing List                        [email protected]
Automated List Manager                            [email protected]