You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I would like to be able to provide more expressive criteria when searching for terms and books. For example, if I want to search for the term that translates as "know" in the terms page, I also get every "Well Known" word, because it appears to be including the "status" field in the search:
Describe the solution you'd like
It would be nice if I could target my search to particular fields, perhaps with a format like field:value, e.g., translation:know (or perhaps support abbreviations, e.g., tr:know). This idea could also be extended to add more expressive filters, (after:2024-04-01 for terms/books added after 2024-04-01). Some ideas for filters (you could really go nuts with adding filtering options, though):
translation:foo or tr:foo - translation contains foo
Support for other string fields: title, term, parent, etc.
ancestor:foo - find all terms that have foo as one of its parents, grandparents, etc.
status:3 - status is 3 (could also support comparisons, e.g., status:>n, status:<n).
is:ignored, is:known
tag:foo - term/book has the tag foo (this maybe should be an exact match, rather than a substring match)
lang:foo - term/book uses language foo (exact match)
Date filtering based on when the term/book was added.
By default, if the search string doesn't contain keyword: anywhere, then it should continue to function like it does now (substring match of all fields). You could also mix and match these modes, e.g., is:known lang:Spanish foo - find all known Spanish words that contain "foo" in any field.
Describe alternatives you've considered
Currently the only way I know of to find the term I'm looking for when the English word includes text from other fields is to remember part of the foreign word and use that in my search.
The text was updated successfully, but these errors were encountered:
Thanks @bwkimmel, this is a nice idea. Right, the text search sometimes returns too much stuff, as you noted with "know"! Sorry about that, I haven't bothered to fix this, been focusing on the reading etc as opposed to term search which has been "just good enough" to get by.
Some of this is already covered by the "filters" at the top. Click the green "+" button:
but I can see the appeal of a small "search syntax" as you've suggested.
Re the link of terms to books (implied by "filtering when the book was added", and "title") -- Lute actually doesn't work that way, it parses things on the fly as opposed to maintaining a running index of terms and where they're used.
Is your feature request related to a problem? Please describe.
I would like to be able to provide more expressive criteria when searching for terms and books. For example, if I want to search for the term that translates as "know" in the terms page, I also get every "Well Known" word, because it appears to be including the "status" field in the search:
Describe the solution you'd like
It would be nice if I could target my search to particular fields, perhaps with a format like
field:value
, e.g.,translation:know
(or perhaps support abbreviations, e.g.,tr:know
). This idea could also be extended to add more expressive filters, (after:2024-04-01
for terms/books added after 2024-04-01). Some ideas for filters (you could really go nuts with adding filtering options, though):translation:foo
ortr:foo
- translation containsfoo
title
,term
,parent
, etc.ancestor:foo
- find all terms that havefoo
as one of its parents, grandparents, etc.status:3
- status is 3 (could also support comparisons, e.g.,status:>n
,status:<n
).is:ignored
,is:known
tag:foo
- term/book has the tagfoo
(this maybe should be an exact match, rather than a substring match)lang:foo
- term/book uses languagefoo
(exact match)By default, if the search string doesn't contain
keyword:
anywhere, then it should continue to function like it does now (substring match of all fields). You could also mix and match these modes, e.g.,is:known lang:Spanish foo
- find all known Spanish words that contain "foo" in any field.Describe alternatives you've considered
Currently the only way I know of to find the term I'm looking for when the English word includes text from other fields is to remember part of the foreign word and use that in my search.
The text was updated successfully, but these errors were encountered: