openreads
openreads copied to clipboard
[FEATURE_REQUEST] Search by defined language
Is your feature request related to a problem? Please describe. The searches now don't have any filter on the language, so they are showed also editions in other languages (mainly, English). While some time this could be useful (you don't find the edition in your language, but you find it in another one, and you later change some info), most of the time you probably want to filter on your language.
Describe the solution you'd like OpenLibrary support filtering by language (see: https://openlibrary.org/search/howto), which will find any books with at least one edition in that language. I would make it like this by default. If no editions are found, we can display a useful message to inform the user, and a button to remake the search without the language filter.
Describe alternatives you've considered If no editions are returned, we could automatically remake the search. But I like the idea of informing the user.
Additional context Try for e.g. https://openlibrary.org/search.json?q=beatrice%20mautino&limit=10&offset=0&language=eng and then https://openlibrary.org/search.json?q=beatrice%20mautino&limit=10&offset=0
I like the idea. I think we had something similar in v1, but If I'm remembering correctly it was filtered on the client side (there was a lot of stuff wrong with the Open Library API implementation anyway).
We would need to create a list of languages that Open Library has and present the list to the user. And maybe the language user is choosing the most should be placed on top.
The languages could be displayed as a scrollable Row of selectable Chips beneath the search bar. Just like here the Priority chips
Unless you want to work on this I don't think this should be in the 2.2.0 milestone.
Oh, I thought a simpler solution, which is using by default the same language defined in the app (I don't know where it is, but I'm confident it is saved somewhere). So, if I use the app using the Italian language, my search query will be done automatically in Italian.
I think that adding a list of choices doesn't add something useful, but instead it slows the flow. I'm all in making a good choice by default.
The list of supported languages in Open Library seems … complete (https://openlibrary.org/languages)
I'm happy to work on this, but yeah, maybe I'm too optimistic with the milestone, I change it.
How about we add the primary language as a default selection in the chips and then give the option to select others? If it's okay, I'll get started on this.
EDIT: Not sure but maybe it would be better to only display the selected language and then make it possible to pick another in a dropdown menu by tapping on the default selection. Scrolling through these languages horizontally is a bit cumbersome in my current implementation.
Maybe having an array of "additional languages" in setting. So we search by app language by default, and have your tabs for additional languages. I don't think anyone would have more 3 or 4
What would the array consist of @lucastucious ? Language name and language code for the search query? Then I think we would need to have list of all the languages with all the translations which is gonna add lot's of work for our translators.
How can we keep the feature simple? Just use short language codes? Or have the language names pre-translated?
How i see it :
- An single app language selection, like we have now. This language drive the app language (localization) and the main search language in search.
- An optional "search languages" array. Maybe the same look as the tag window, maybe only the language codes (fr, pt, zh, ...). Each one of theses appear in tabs suggested by @th8m0z
Why don't we just offer a button that opens a dropdown with all possible languages to filter with through the OpenLibrary API on the search page, where the user can select which one they want?
I feel like filtering by a specific language is not a super common occurrence, so this would suffice.
Right now the search is already working but the chips contain all languages, which is probably not what we want. If we want to keep it simple, it would also be possible to just limit the chip list to the languages supported by the OpenLibrary API and sort them by number of books.
I don't think that will answer the use case. If you're spanish, 99% of your search will be in spanish. If you have to scroll or check some tag each time, instead of just setting it one time in settings, it's an error.
You should be able to set your main language of search.
I made lots of trials on this topic (the code is done) , but I'm stuck in what could be the best user experience. I describe my thoughts below.
The majority of the searches I think are made by ISBN (which is by nature language specific) or by title (which is not unique only for titles that are equals in multiple languages, e.g. 1984). So, firstly, the problem occurs , I think, only for a small percentage of searches.
For the cases when the same search can give multiple results for multiple languages (eg. by author) , my bet is that by default the users want only the results in their language (we can automatically pick the one chosen as the app language, because it's easy and effective), or at least see the results ordered by language (but for us is more difficult to implement).
I don't think that it is useful by any mean to add the possibility to choose the language in the search: the UI would be bloated, and I think it's a rarity (but not impossible) that someone want a book in a specific language, different from the default one. Consider also that if someone that is for example (like me) Italian want a book in French can always search the book by the French title: it's a straightforward method to get the perfect result.
My proposal is to always search filtering the search with the current locale language, but adding to the bottom of the result list a bottom with a caption like "search results in all languages", which redo the exact same search without the language filter
Then there is the editions "problem". Even if we filter the books in a specific language, the editions are always showed in all languages (the filter can only be done ex post, after the fetch from Open Library). So, is it better to filter the books by language and also their editions or only the books and to show all editions (maybe sorted by language) ?
I cannot choose , I think I'll make a poll on matrix...
Can't we display the edition with like, the default one in the assumed user language, and in the "other editions" tab a list of all language orderer by language (user one first) ?
Consider also that if someone that is for example (like me) Italian want a book in French can always search the book by the French title: it's a straightforward method to get the perfect result.
I don't know if I would agree with that, for me the use case is precisely to find books in different languages without knowing the local titles. Also, some languages may have different characters which I don't know or which are not in my default keyboard.
I like how the search works in the web version of Open Library.
I search for Godfather and 1st result is in my native (polish) language. It's the same result as in Openreads but in the app the title is in english.
Ok, here I am. I made two polls on Matrix (https://matrix.to/#/!HRsxusjQtcBhgtYWtR:matrix.org/$_UkuZCerTKAW0UZyovPb1vVqiVz8rmVuKYq2wspPXbc?via=matrix.org&via=tchncs.de&via=nitro.chat) asking what they prefer. So, my proposals are:
- order the results and the versions showing firstly the ones with the local language, or
- the same of the above, but with the addition of a button to redo the search, limiting the results to only the ones with the local language, or
- do nothing, but shows the language (as a code , for e.g. "en" or "it") below any versions (as an addition to https://github.com/mateusz-bak/openreads-android/pull/429)
@mateusz-bak tell me what do you think
P.s.: technically speaking, the only way I saw to order results by language (if defined) is to parse the JSON and see if it contains the language properties, and sort by that value. So it's a thing we can make only after fetching all results/versions (it's what I wanted to propose in https://github.com/mateusz-bak/openreads-android/issues/342)
I like option 1 - this works as I mentioned in the previous comment.
For sorting search results - here I'm more sceptic as there are lots of "not clean" search results and you get the same book couple of time in different languages (I think the search results are sorted by the best matching or popular?)
Per P.S. I'm just interested how it is implemented in the web search, as I don't thing the results there are filtered after being received by the browser. Maybe you can dig how this works either by checking web calls in the browser or maybe asking Open Library support? (just an idea)
@apobrt what are you deciding then? And how is this going?
By the way just found that web query to the API includes Accept-Language pl,en-US;q=0.7,en;q=0.3
header