Open trendspotter opened 1 year ago
by the way: many times you may notice that some products are inserted with the wrong country of sale. For example, dairy products from a small local producer have a country of sale overseas (e.g. european producer versus country of sale United States) which is mostly nonsense because this type of fresh short-life product is not shipped overseas nor does it have a sales representative in that country. It's clearly an users misconfiguration of the environment in the mobile app. That environment assumes that the user sets it up once and then doesn't change it even if they travel to multiple countries. Scanning food is often needed by travelers in foreign countries to better understand them. So when they scan them, they enter them directly into the database,but wrong country. So correct this is very difficult, when you have about 3M products in database.
@trendspotter thank you for the report. We are aware that current state of search is really not at the level we need.
@simonj2 started something with https://github.com/openfoodfacts/openfoodfacts-search/ and we would really love to build a modular search engine upon that (we hope to get some sponsor for this).
This issue is stale because it has been open 90 days with no activity.
@trendspotter FYI we have a funding and we are starting the project (more to come).
This issue has been open 90 days with no activity. Can you give it a little love by linking it to a parent issue, adding relevant labels and projets, creating a mockup if applicable, adding code pointers from https://github.com/openfoodfacts/openfoodfacts-server/blob/main/.github/labeler.yml, giving it a priority, editing the original issue to have a more comprehensive description… Thank you very much for your contribution to 🍊 Open Food Facts
The site has a complicated and hard to use search.
Why?
It is not clear how good the full-text word search is. Nowhere is it explained what the search can find and what it cannot.
It is not possible to search by full EAN code,
you can't search by part of the EAN code, with a wildcard to limit the search to a specific country. For example 123*
the search distinguishes between letters with accents. However, users who don't use the accented alphabet in their own language will enter the product name without it, which is wrong, e.g. á=a š=s č=c etc.
the search is limited to whole words. Thus, you can't find a product with a misspelled name, or only part of the name.
the search intentionally does not show results from the search word if it is already contained in the product's brand name, this may not be clear to the user
why this is important:
This is also why there are many products in the database "from France" although they may not be from France. Only in France there are most users who scan and enter products from different countries into the OFF database. Correcting these products is very time consuming.
Either figure out how to reduce this behavior or teach users from France to enter products exactly by the country where they scanned it. Learn users to enter the names of products precisely.
It is very hard for other users to subsequently edit the local country database. if we don't know the exact name of the food, it is hard to find it.
Also, there is no way to batch correct or delete multiple erroneous products at once, but this functionality belongs more in the "bulk editing of products and rights to those edits" topic
How to improve it:
Create a fully full-text search without the restrictions the user expects from a full-text search (including the ability to wildcard or exclude search strings)
work accurately and well with all NON-ASCII characters, especially with accented characters
if it is not possible, please explain the limitations of the web search