simple search with Exact ID

[funderburkjim]

From #21, this question arose:

And is there a way to link directly to some word? Not to simple, but to an exact ID?

One of the current problems with simple search is that we don't know what spelling system the user has in
mind. If the user is inputting directly generally english phonetic spellings and is using common English
sibilants and nasals, things work fine.

But if we assume the user already is using a citation based SLP1 or HK, then problems can arise.

I've been thinking that we should make some API provision for the user to say that he is intentionally using
HK or SLP1, if that is what he's doing.

example 1 SLP

Currently https://sanskrit-lexicon.uni-koeln.de/simple/mw/gaRa gives (in IAST) gara ghāra garā gāra,
none of which is right if the user was thinking slp1, where the word (in IAST) is gaṇa.

So, maybe we could allow https://sanskrit-lexicon.uni-koeln.de/simple/mw/gaRa?in=slp1.

This probably could be parsed, and then some of the simple-search algorithm would be altered to take into
account that the user was thinking slp1.

This would be especially useful if someone was making ahead of time a specialized vocabulary;
such as a vocabulary for some pedagogical story.

Default would allow handling of capital letters.

Suppose I'm reading an article in Wikipedia, such as https://en.wikipedia.org/wiki/Ramayana.

This article has many Sanskrit words, usually in IAST, but sometimes almost in IAST.
It would be nice to be able to cut and paste such a word into a simple search to get a dictionary reference.

For example, https://sanskrit-lexicon.uni-koeln.de/simple/mw/Lanka . But this result currently gives no
information.
The problem is with the capital letter. Also, suppose you try
https://sanskrit-lexicon.uni-koeln.de/simple/mw/GURU . You get the wrong answers currently: muru mūru.
The reason is that capital 'G' is (in HK transliteration) a nasal (guttural nasal), and the search procedure
says we should try other nasals, hence the 'm'.

The default search should, instead, I think, ignore capitalization (as does IAST).

[gasyoun]

But if we assume the user already is using a citation based SLP1 or HK, then problems can arise.

Only a robot can use SLP1, so we do not care a lot about bots, do we?

some API provision for the user to say that he is intentionally using HK or SLP1, if that is what he's doing.

Agree.

Currently https://sanskrit-lexicon.uni-koeln.de/simple/mw/gaRa gives (in IAST) gara ghāra garā gāra,
none of which is right if the user was thinking slp1, where the word (in IAST) is gaṇa.

Good example.

So, maybe we could allow https://sanskrit-lexicon.uni-koeln.de/simple/mw/gaRa?in=slp1.

All I ask is without the ?. So we can have like.

https://sanskrit-lexicon.uni-koeln.de/simple/mw/gaRa/slp1

As per

This would be especially useful if someone was making ahead of time a specialized vocabulary;
such as a vocabulary for some pedagogical story.

Fully agree. Pedagogical use is what I keep in mind all the time.

It would be nice to be able to cut and paste such a word into a simple search to get a dictionary reference

Yes, yes and yes!

The default search should, instead, I think, ignore capitalization (as does IAST).

Yes, or give preference to Nomen proprium in meanings?

[funderburkjim]

All I ask is without the ?. So we can have like.
https://sanskrit-lexicon.uni-koeln.de/simple/mw/gaRa/slp1

The current url assumptions are that the 3rd argument (simple/1/2/3) (e.g. 'slp1' in the above) refers to
the choice of 'output' . And the 4th argument refers to the use of accent.

Now we COULD change the url assumptions (That is, how the program interprets the parameters)
so that the 3rd one is as in your example (i.e., the input spelling assumption).

In that case, the 'output' and 'accent' parameters would not be settable by the url; rather, they would have
the values (from cookies) that the user had previously set.

Should the 'output' and 'accent' parameters be settable by the url?

My snap opinion, no -- let 'output' and 'accent' be set only by the user (via cookies), and not by the url.

What do you think?

[funderburkjim]

To continue the thought, with the change in url assumptions,
the 3rd parameter would represent the spelling assumption of the 2nd parameter (the word being looked up):

• If 3rd parameter is absent, then use so-called normal English spelling assumption of 2nd parameter.
  This would include IAST spelling.
  • If the 2nd parameter is Devanagari, then we would be able to take this into account;
    the program would first convert to slp1, then do the search under slp1 spelling assumption
• Otherwise, we would expect 3rd parameter to be either slp1 (slp) or hk (kh).
  • something else for 3rd parameter would be considered an error, and we would revert to same process
    as if 3rd parameter is absent.
  • Would prefer not to allow itrans, at least for now.
  • We could allow 3rd parameter to be 'iast', but this might be same as the default (3rd parameter absent)

[gasyoun]

My snap opinion, no -- let 'output' and 'accent' be set only by the user (via cookies), and not by the url.

Yes, cookie setting is enough.

Would prefer not to allow itrans, at least for now.

Agree. And agree with all the assumptions as well.

[gasyoun]

@funderburkjim is there something from myside that can be done, to move ir forward?
82nd in @drdhaval2785 list it remains Top5 UI task from sanskrit-lexicon/COLOGNE#325