Filter search results by user-selected dictionary sources

[eddieantonio]

Prerequisite: #125

Enables the "advanced search" dropdown that allows one to filter on dictionary source.

Addresses the following user story:

As a Cree language educator, I want to see search results ONLY from certain dictionary sources

• Requires new UX [Diane]
• Requires accessible HTML/CSS [Eddie]
• Requires database implementation [Matt or Eddie]

[eddieantonio]

Note: I deleted my first attempt at the HTML in this commit: ae6c0c9.

git revert ae6c0c9d7567ba77ad26718e2103c5963360a31a

To get the code back.

[eddieantonio]

@nienna73 here are the old mockups that our UX deverloper made in 2019:

[nienna73]

Do we want to keep this UI or add the dictionary source to the settings page?
Adding the options to the new settings page makes more sense to me.

[eddieantonio]

Do we want to keep this UI or add the dictionary source to the settings page?
Adding the options to the new settings page makes more sense to me.

I agree; I think it makes more sense to add it to the settings page, since I think it's actually a niche feature. That being said, I have a personal attachement to the style of those checkboxes! 😂

[dwhieb]

I also like this UI! But also agree that the settings page is the place for them.

[nienna73]

@aarppe is the idea that a user can select more than one dictionary source at a time? For example, CW and MD? Or should they only be able to select one, that is: CW or MD (among the other choices)?

[aarppe]

@nienna73 The idea is that users could select any combination of sources, so CW alone or MD alone, or both CW and MD (and then more, once we get AECD in as well).

[nienna73]

The idea is that users could select any combination of sources

Okay, that's what I've been trying to do. I'm finding it difficult to set multiple options, so I wanted to clarify this was actually the goal.

[nienna73]

I came across an edge case in development:

What do we do when the search result is a form of a word from a different dictionary, like in the example above?
Should I include the definition of mîpit (in this case)?
Or completely remove nîpit from the results?

[dwhieb]

@nienna73 Is the above screenshot filtering what currently happens when filtering for MD entries, or for CW entries?

[nienna73]

That's a good question. The example above is showing only MD results.

I found a perhaps better example, still filtering to show just MD results:

[dwhieb]

@nienna73 Ok so to clarify: This second example is supposed to be showing only MD results, but it includes a CW entry because ayiwinisa is recognized as a form of the CW entry ayiwin. Do I have it right?

I'm 100% fine with simply not showing either "form of ayiwin" or the entry for ayiwin in this case.

Another solution is to remove the entry for ayiwin, but keep "form of ayiwin", simply without the link. Also 100% fine with that.

@aarppe Do you have a preference?

[nienna73]

@dwhieb Yes, you have that correct. I think both of those options are possible, so I'll wait to see what the preferred implementation is.

[aarppe]

This is the problem when MD doesn't also include a lemma entry for inflected word-form entries - we'll have more of these cases with some of the imperative verbs. When I was thinking about this almost three years ago, I was considering whether we ought to add "technical" lemma entries, though we might want to run those past speakers - fortunately there's only a few hundred of such forms.

Strictly speaking, if we're not showing content from the other dictionary, then it might be best that we're consistent about that, and neither show the lemma entry, i.e. not show ayiwin (like: cîmân) etc., nor the link to the lemma entry (which is in the other dictionary), i.e. form of ... etc. However, the FST analysis can still show that lemma (right now the stem, but I think we'll want to swap back to lemmas eventually), since the FST lexicon is independent of the actual sources.

[aarppe]

@nienna73 As part of the dictionary source selection (#126, this issue is getting resolved, but to close that we need to resolve the case of empty results, cf.