Rendered at 09:05:26 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
Leptonmaniac 4 hours ago [-]
To be honest, there's still a long way to go.
First, what is the benefit of using this over something established like fddb or any already existing nutritional app?
Second, just translating the words for the units (like cup) doesn't work, because for example while "szklanka", the Polish word for glass, is indeed used in Polish recipes, there it means more something along the lines of "just grab whatever standard glass you have, it will be fine". It explicitly does not mean a unit of measurement of 236 ml.
Third, since you are using a US source you fall into the trap of US defaultism here. The way carbohydrates are labeled is different around the world and I think only the US does this weird thing where you have to manually subtract the dietary fiber from the total carbohydrates. This matters because you essentially give non-US users (and definitely users from the EU) plainly incorrect amounts of labeled carbohydrates.
All in all, cute project and good on you trying to tackle it. It looks okay though the AI smells bother me personally, but I don't think nutritional data is a great place to start for such a project and honestly I will not remember your site in a few days anymore.
laurentlb 15 hours ago [-]
Is there a way to set the default unit?
I'd prefer to see the information per 100g by default (instead using random units).
llovan 15 hours ago [-]
thanks for the feedback. That's a good suggestion. I will be adding some tweaks soon for improved unit handling. Also another idea I had that I want to implement is being able to compare several foods side by side in a split view (on desktop or tablet landscape modes).
yawaramin 11 hours ago [-]
Hello, nice work. I recommend running Chrome's built-in Lighthouse analysis tool specifically for accessibility. It will make some very helpful suggestions, like img alt text and colour contrast issues. One example that I eyeballed is the search bar–the background colour is pink and the text colour is yellow. Kinda hard to read :-)
llovan 11 hours ago [-]
Thanks for the suggestions, they are valid concerns and I didn't know that about Chrome and Lighthouse. ty for the tips
voidnap 10 hours ago [-]
The search results aren't hyperlinks? So middle clicking to open in a new tab does nothing. Odd choice.
Thanks for catching this. I had implemented the cards as HTMX-clickable divs, which broke native link behavior. I just shipped a fix: search result cards are now real anchor links, so middle-click/cmd-click/ctrl-click work normally while plain clicks still use the in-page HTMX transition.
cd4plus 16 hours ago [-]
I can't enter a serving size that's not a whole number on mobile because it automatically closes the keyboard when the text field is cleared
llovan 16 hours ago [-]
Thanks for catching that. Will fix soon.
vivzkestrel 6 hours ago [-]
- we need an indian version of this website with all the 10000+ indian food items listed on it
simlan 12 hours ago [-]
Looks good. The quantities input box behaves strange on Firefox mobile. Can't seem to delete the input and type something new. Jumps to a default or any number before I get to type my grams.
recursivedoubts 16 hours ago [-]
awesome, very good looking and simple, useful functionality
olarm 15 hours ago [-]
Very nice, what is the source of the data?
llovan 15 hours ago [-]
The only source currently for all data is the USDA's Food Data Central. I'm planning on adding more nutrient data sources in the near future.
____tom____ 9 hours ago [-]
Really. Because it looks less useful than its source.
If I search for Apple on food central, I get offered different types of Apple, like Fuji, honeycrisp, etc. with nutripedia I just get raw and cooked, which are within each type on food central.
In addition, nutripedia has a bunch of what looks like AI written text that is not particularly useful.
Writing an AI generated wrapper around something is not enough to be interesting. What do you see as your value add?
torsianWorld 14 hours ago [-]
Great optimization!
razorson 16 hours ago [-]
Nice great job, how do you handle multi languages?
llovan 15 hours ago [-]
Thank you! Each locale has its own route terms, UI strings, portion terms, localized food names, synonyms, slugs, and search behavior.
The app uses ICU MessageFormat for pluralization/units and locale-aware number/unit formatting. Search varies by script: Latin languages use pg_trgm/unaccent, CJK and other non-Latin scripts use PGroonga, and romanized aliases are indexed separately so Latin-keyboard queries can still find native-script foods.
For localization I do use multiple LLM passes, but mostly as a structured localization pipeline rather than a one-shot translator: generate localized names/aliases/slugs/content from canonical food and nutrient data, then run separate review/evaluation passes and human spot checks.
The hard part is regional naming and portions, not basic translation. For example, in Spanish, "Potato" as papa vs patata is the simple version of the problem.
Kuyawa 16 hours ago [-]
Simple and beautiful, I love it.
setnone 15 hours ago [-]
cool! i see at least two reasons in the title to upvote this
llovan 15 hours ago [-]
lol, ty, Clojure + HTMX have been an amazing combo for this project. and postgres too, for the DB.
Finnucane 15 hours ago [-]
The search seems a bit weird. A search for salmon includes almonds in the results, and a search for spinach includes Tahitian taro.
llovan 14 hours ago [-]
Thanks for the feedback. Currently in addition to fuzzy matching the search system will match against synonyms broadly, so some unintended leafy greens would match Spinach as in your example results. I'll have to tweak the fuzzy matching a bit.
jazzyjackson 4 hours ago [-]
If you really want to dig into semantic fuzzy search you can check out the wordnet project and chatscript, which provides an excellent lem , stem , and parse tool which tags each search term with its term in wordnet, so you can match against a hierarchy of concepts, including category of food. There are other solutions I’m sure but I’ve always wanted to make a local db search with this, I think it would be more structured and debuggable thank straight vector similarity
Hi HN, I'm Jovan. I've been building Nutrepedia part-time from Monterrey, Mexico.
It's a multilingual nutrition reference site: 1,635 foods rendered into 47,415 localized pages across 29 regional locales. Each page has nutrition facts, localized names, portion terms, regional routing, imagery, and short food context.
The stack is Clojure, HTTP-Kit, Compojure, Hiccup, HTMX, and Postgres. Postgres handles the food data, localized content, admin workflow, task queues, search, and evaluation records.
The search piece has been the most interesting technically. Latin-script fuzzy search uses pg_trgm and unaccent. CJK and other non-Latin scripts use PGroonga. Romanized aliases are indexed separately, so a query like "rasbhari" can find a Hindi food name like "rasbhari" / "रसभरी".
I built this because most nutrition tools feel calorie-first, signup-first, and English focused. I wanted the reference layer to be free and useful before asking anyone to track meals or create an account.
I'd especially appreciate feedback on search, localization mistakes, whether the pages are useful before tracking exists, and any obvious technical blind spots.
snowpid 15 hours ago [-]
cool projects. bear in mind some languages like Spanish are spoken across different countries. German for example is spoken in Germany, Austria and Switzerland. Using the Germany flag is misleading.
First, what is the benefit of using this over something established like fddb or any already existing nutritional app?
Second, just translating the words for the units (like cup) doesn't work, because for example while "szklanka", the Polish word for glass, is indeed used in Polish recipes, there it means more something along the lines of "just grab whatever standard glass you have, it will be fine". It explicitly does not mean a unit of measurement of 236 ml.
Third, since you are using a US source you fall into the trap of US defaultism here. The way carbohydrates are labeled is different around the world and I think only the US does this weird thing where you have to manually subtract the dietary fiber from the total carbohydrates. This matters because you essentially give non-US users (and definitely users from the EU) plainly incorrect amounts of labeled carbohydrates.
All in all, cute project and good on you trying to tackle it. It looks okay though the AI smells bother me personally, but I don't think nutritional data is a great place to start for such a project and honestly I will not remember your site in a few days anymore.
If I search for Apple on food central, I get offered different types of Apple, like Fuji, honeycrisp, etc. with nutripedia I just get raw and cooked, which are within each type on food central.
In addition, nutripedia has a bunch of what looks like AI written text that is not particularly useful.
Writing an AI generated wrapper around something is not enough to be interesting. What do you see as your value add?
The app uses ICU MessageFormat for pluralization/units and locale-aware number/unit formatting. Search varies by script: Latin languages use pg_trgm/unaccent, CJK and other non-Latin scripts use PGroonga, and romanized aliases are indexed separately so Latin-keyboard queries can still find native-script foods.
For localization I do use multiple LLM passes, but mostly as a structured localization pipeline rather than a one-shot translator: generate localized names/aliases/slugs/content from canonical food and nutrient data, then run separate review/evaluation passes and human spot checks.
The hard part is regional naming and portions, not basic translation. For example, in Spanish, "Potato" as papa vs patata is the simple version of the problem.
https://github.com/ChatScript/ChatScript
It's a multilingual nutrition reference site: 1,635 foods rendered into 47,415 localized pages across 29 regional locales. Each page has nutrition facts, localized names, portion terms, regional routing, imagery, and short food context.
The stack is Clojure, HTTP-Kit, Compojure, Hiccup, HTMX, and Postgres. Postgres handles the food data, localized content, admin workflow, task queues, search, and evaluation records.
The search piece has been the most interesting technically. Latin-script fuzzy search uses pg_trgm and unaccent. CJK and other non-Latin scripts use PGroonga. Romanized aliases are indexed separately, so a query like "rasbhari" can find a Hindi food name like "rasbhari" / "रसभरी".
I built this because most nutrition tools feel calorie-first, signup-first, and English focused. I wanted the reference layer to be free and useful before asking anyone to track meals or create an account.
I'd especially appreciate feedback on search, localization mistakes, whether the pages are useful before tracking exists, and any obvious technical blind spots.