-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Chant search page filters have abbreviations only #1591
Comments
@annamorphism @lucasmarchd01 thoughts or memories of why this was? |
#512, #699, #703 are responsible for the discussion around this issue. I'm not entirely sure the reason we switched to using the abbreviations was justified. It seems like part of the reason was because the double square brackets looked strange. Instead maybe we can just come up with a better string representation for these models. |
thanks @lucasmarchd01 -- that makes sense. I guess it is good to have the abbreviation in the list so then when the filtered results show up in the table with the abbreviation, it's clear why the source is in the results. I'm wondering why we have some genre names with brackets. It looks like those are mostly deprecated genres? It looks like there are some chants with the I wonder if the one chant with And then I don't see why the |
Yes, that [M] should be reclassified--it's a little strange, actually, because that's a relatively recently added chant, so I wonder if the bracketed genres came back into use on NewCantus somehow after previously being deprecated. I also don't see why [?] couldn't be ? . |
The "Genre" and "Service" filter dropdowns on the chant search page display only abbreviations for those fields. This means that unless you are a CantusDB power user, you have to go to the separate pages that list the translation of these abbreviations to their names to filter effectively.
For example, this screenshot shows the possible values of "Genre" filter on the chant search page:
Was there a reason for this? I can't immediately find an issue that would suggest why this was implemented with the abbreviation only.
The text was updated successfully, but these errors were encountered: