Rendered at 03:14:13 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
yawaramin 5 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 5 hours ago [-]
Thanks for the suggestions, they are valid concerns and I didn't know that about Chrome and Lighthouse. ty for the tips
laurentlb 9 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 9 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).
voidnap 4 hours ago [-]
The search results aren't hyperlinks? So middle clicking to open in a new tab does nothing. Odd choice.
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 10 hours ago [-]
Thanks for catching that. Will fix soon.
simlan 6 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 10 hours ago [-]
awesome, very good looking and simple, useful functionality
olarm 9 hours ago [-]
Very nice, what is the source of the data?
llovan 9 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____ 3 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 8 hours ago [-]
Great optimization!
razorson 10 hours ago [-]
Nice great job, how do you handle multi languages?
llovan 9 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 10 hours ago [-]
Simple and beautiful, I love it.
setnone 9 hours ago [-]
cool! i see at least two reasons in the title to upvote this
llovan 9 hours ago [-]
lol, ty, Clojure + HTMX have been an amazing combo for this project. and postgres too, for the DB.
Finnucane 9 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 9 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.
llovan 10 hours ago [-]
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 9 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.
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.
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.