"ni" gives a confusing result (maybe)

[TheSeptembre]

"ni" gives no result even if it is in the list

[jProgr]

I tried searching "ni" (without quotes) and got a couple of results; the "ni" definition was in the 11th place. I also tried searching "ni" (with quotes) and got no results; are you talking about this case? The dictionary does not use a fuzzy search algorithm, it uses a substring match. Also, it functions as reverse dictionary too, it looks at the meanings when searching, not only at the word keys. Do you think it should use another algorithm? Which results were you expecting?

[TheSeptembre]

I was initially confused that ni (without quote) did not bring the result at the top and thought it didn't work, whereas, as you make me notice now, it actually brings back results. However, it's maybe confusing since we have as first result:

akesi : n non-cute animal, reptile, amphibian, dinosaur, monster akesi definition appear since "animal" contains ni.

✳ What I suggest as a light workaround:

• try to bring first, if exists, the perfect match (ni) for toki pona words or highlight if the word searched has a perfect match in the result set.
• Then add other results

💢 Possible issues with this:

• synonyms (i don't know if some toki pona words exists in english too)
• performances
• ...?

_ also, thank you in general for this project, which is very simple and useful for toki pona community. ♥

[jProgr]

I like those suggestions. I will try both and see which one makes more sense.

[jProgr]

Also check out @LongJohn-Silver suggestion:

I still think that the best solution would be to add to search entries for the two languages […] Maybe instead of two search boxes it could be something like this, with two buttons to select the language

—https://github.com/jProgr/TokiPonaDictionary/issues/10#issuecomment-726249288

[jProgr]

After some deliberation, I will implement the following solution: The current results will still show in the same way but for every exact match (that is, every entry in the dictionary that has a string that is exactly as the query) there will a duplicate of such entry that will be shown before the current results and will be highlighted somehow.

The considered solutions were the ones present in this issue and #10. I thought about the advantages and problems of each one:

• "Highlight" solution.

  • Advantages:
  • Few changes are needed in order to implement this solution.
  • Problems:
  • The result would still be buried with the other ones.

• "Bring first" solution.

  • Advantages:
  • The desired information may be an exact match and by showing it first the user may not need to look into the result set.
  • If the desired information is not in the exact match, by not touching the current results, users may look intuitively (that is, the results are ordered and there is nothing out of place) into the results for the desired information.
  • Problems:
  • How to handle too many exact matches?
  • If the desired information is not an exact match then the entries that are duplicated and show before the result set are effectively noise for the user. I think that to solve this problem I will make the exact match entries a little bit smaller.

• "Multiple buttons" solution:

  • Problems:
  • If the default search is not the one the user needs then the dictionary is not immediately usable.
  • I think it's a bit misleading to have an "English" button when the dictionary is not actually English-Toki Pona. For example, one would expect a translation of the english word "Yes" to Toki Pona but this is not how a reverse dictionary works.

What do you think?

[jProgr]

These are the principles I follow when taking any decision about the tool:

• The dictionary should be a Toki Pona to English dictionary with a reverse search function.
• The dictionary should be immediately usable.
• The dictionary should serve as few bytes as possible, with the content being first.
• The dictionary should strive to show entries in alphabetical order because that's how a physical dictionary is ordered.
• The dictionary should work on any desktop and mobile devices.
• The dictionary should be open about its sources.
• The dictionary must strive to help learners of the Toki Pona language and be a fast tool for quick consulting.
• This dictionary should strive to cover all the words as used by Toki Pona speakers without forgetting about the official dictionary.

Maybe I should add these to the code.

[TheSeptembre]

After some deliberation, I will implement the following solution: The current results will still show in the same way but for every exact match (that is, every entry in the dictionary that has a string that is exactly as the query) there will a duplicate of such entry that will be shown before the current results and will be highlighted somehow.

I like it a lot and find it very elegant. Seems lightweight and might not confuse users. 👏

[jProgr]

With the help of @mitaa the new search algorithm was implemented. While testing it out I noticed that a lot of the results between the exact matches and the partial ones were the same and the page usually ended up with the same word twice. And so I decided to remove the partial results and leave only the exact ones. The new release 210217 (currently live) has those changes.

Later I thought about showing the partial results if the exact results are empty, but I'm not sure.

[Saevon]

Removing partial matches has made finding some words harder to find though

• Some definitions use conjugations so you can't find the similar words. (e.g. "creature" shows either monsuta or kala, based on pluralization) or (e.g. "in" finds a lot of words but not insa if you actually meant "inside == in") or ("nothing" not showing "ala")
• You also don't get feedback if you misspell something: e.g. accidentally missing the u in Monsta. Normally you'd see the word before you make the mistake
• You need to write out the full exact word to see anything (which I almost never did for most of my usage)