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).
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 :-)
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.
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.
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?
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.
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.
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
I appreciate the ambition and the tech, however, I do wonder if you have bitten off more than you can chew regarding localisation. I write this as a Brit, so not that far off the Standard American Diet.
First off, the locale switcher needs to be buried in the footer, with the locale provided by the browser request and automatically getting the units and language right. This will work for most people but there will be the theoretical use cases of the person on a VPN using a computer in a public library in Burkina Faso. Yes, you will need to have things going on in the backend to do this, but think of the user experience!
As for my critique of localisation, I would say that this is more of a critique of the USDA database (and LLMs) rather than a critique of your skilled efforts to make a beautiful website. Furthermore, this critique is from the UK, and other no-American English speakers, for example in Australia, might think I am being unreasonable. However, honest feedback and an idea of what you could do with that dubious USDA data, to make it work for people visiting the USA, in the happier times that should be coming soon...
In the UK we have labelling standards that are fairly similar to what goes in the EU. We list carbohydrates per 100g and per portion size, with sugars broken out separately. This is clear. With Nutrepedia I am wondering what a carbohydrate is. We list fibre as its own thing, not as a carbohydrate.
I don't believe the LLM wall of waffle text adds any value whatsoever. You are just wasting people's time and sending people into deep sleep with that slop. Nobody likes to read AI slop, particularly if it is useless, as is the case here. Harsh, I know, and opinion, I know, but AI slop is out there with 'horoscopes' as not worth reading.
I looked up 'haricot beans' because they are extremely popular in the UK, albeit in Baked Beans form. Ask for 'haricot beans' in a supermarket and nobody will be able to tell you where they are, even though there could be a whole aisle of the things.
Haricot beans are navy beans in the US and they are notable for phosphatidylserine. Unless you are eating offal, there isn't a better source of phosphatidylserine than haricot beans. Yet, despite the wall of LLM slop, no mention of phosphatidylserine or whether this matters (allegedly phosphatidylserine is important for cell wall strength and you can get snake-oil-supplements if you are gullible).
Then there is the small matter of cholesterol. Not present in haricot beans because plants don't do cholesterol. However, why not explicitly state the big zero? You have cholesterol listed if I look up beef.
I am also not sure that I would describe a bean as a seed. What is the difference between a bean and a seed? Why not call it a grain? Or a nut? Or a plant-fetus?!?
I suppose a bean is a seed, but, for legumes, beans are beans, not seeds. It is 'baked beans' not 'baked seeds'. Coupled to this is the gym-bro-influencer on the carnival barker diet that has a biological hatred of 'seed oils', so 'seed' is already a controversial word in the world of gym-bro 'science'.
The search did return navy beans for the keywords 'haricot beans', but the results were different when I switched to my chosen locale. In fact, with the same search terms, I had three different result sets and no way of going back to the search page to see how the LLM gaslighting was going.
The big long list of amino acids cribbed from USDA in the full details was also perplexing. Which ones are essential and which ones can be made by 'liver gymnastics'?
Why does this matter? Beans and rice. Beans have some essential amino acids in abundance but not all, same with rice. So you need to mix and match.
Nit-picking at the navy beans seems unfair, but they are listed as 'boiled without salt'. So I look for the words 'salt' or 'sodium' and can't find the entry.
In the UK it is all about HFSS (High fat, sugar and salt). You can get salty plants, e.g. samphire, as consumed by people that watch the TV show 'Masterchef'. Therefore, it should not be assumed that salt (UK) or sodium (simplified English) needs to listed, even if the result is zero.
We have a traffic light system for HFSS on most foods. Haricot beans should be green for everything, whereas beef is going to be red for saturated fat. They don't have traffic light food labels in the USA because freedom, however, that is the important summary on the front of the pack.
Most American food is either banned or boycotted in the UK and Europe. US agricultural commodity crops just go into animal feed, to fatten animals kept in captivity. Therefore, everything on the USDA database is not applicable outside of the land of the burger.
This is particularly true for processed foods. An internationally recognised product such as a a KitKat bar will be formulated very differently for British tastes to European or American tastes. In the UK, HFSS rules will come into play, so the USDA values don't apply, even at the macro nutrient level.
Incidentally, according to the USDA there are FIVE macro nutrients, not three.
Since there is no attribution to USDA or wherever the pictures come from, with no links to describe what some of the micro nutrients are, does this help anyone? Is the content misleading to an international audience? I would say so.
So, what to do?
IMHO the USDA data is garbage as far as the rest of the world is concerned. It won't be possible to shoehorn it into a form even for a British audience any more than an American pick up truck makes sense on a British road. As for our cousins in countries that don't have English as their first language, you have your work cut out there.
Consider asking questions about whom the user is, and what their pain points are. The international traveller going to the USA could be that user you want. I know nobody is going to the US these days but times change and people will be back.
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.
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.
Is there a way to set the default unit? I'd prefer to see the information per 100g by default (instead using random units).
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).
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 :-)
Thanks for the suggestions, they are valid concerns and I didn't know that about Chrome and Lighthouse. ty for the tips
The search results aren't hyperlinks? So middle clicking to open in a new tab does nothing. Odd choice.
Yeah, unfortunately, looks like they're `<div hx-get>`. This is exactly what I tell everyone to avoid in htmx: https://dev.to/yawaramin/why-hx-boost-is-actually-the-most-i...
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.
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
Thanks for catching that. Will fix soon.
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.
- we need an indian version of this website with all the 10000+ indian food items listed on it
awesome, very good looking and simple, useful functionality
Very nice, what is the source of the data?
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.
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?
Great optimization!
Nice great job, how do you handle multi languages?
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.
Simple and beautiful, I love it.
cool! i see at least two reasons in the title to upvote this
lol, ty, Clojure + HTMX have been an amazing combo for this project. and postgres too, for the DB.
The search seems a bit weird. A search for salmon includes almonds in the results, and a search for spinach includes Tahitian taro.
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.
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
https://github.com/ChatScript/ChatScript
I appreciate the ambition and the tech, however, I do wonder if you have bitten off more than you can chew regarding localisation. I write this as a Brit, so not that far off the Standard American Diet.
First off, the locale switcher needs to be buried in the footer, with the locale provided by the browser request and automatically getting the units and language right. This will work for most people but there will be the theoretical use cases of the person on a VPN using a computer in a public library in Burkina Faso. Yes, you will need to have things going on in the backend to do this, but think of the user experience!
As for my critique of localisation, I would say that this is more of a critique of the USDA database (and LLMs) rather than a critique of your skilled efforts to make a beautiful website. Furthermore, this critique is from the UK, and other no-American English speakers, for example in Australia, might think I am being unreasonable. However, honest feedback and an idea of what you could do with that dubious USDA data, to make it work for people visiting the USA, in the happier times that should be coming soon...
In the UK we have labelling standards that are fairly similar to what goes in the EU. We list carbohydrates per 100g and per portion size, with sugars broken out separately. This is clear. With Nutrepedia I am wondering what a carbohydrate is. We list fibre as its own thing, not as a carbohydrate.
I don't believe the LLM wall of waffle text adds any value whatsoever. You are just wasting people's time and sending people into deep sleep with that slop. Nobody likes to read AI slop, particularly if it is useless, as is the case here. Harsh, I know, and opinion, I know, but AI slop is out there with 'horoscopes' as not worth reading.
I looked up 'haricot beans' because they are extremely popular in the UK, albeit in Baked Beans form. Ask for 'haricot beans' in a supermarket and nobody will be able to tell you where they are, even though there could be a whole aisle of the things.
Haricot beans are navy beans in the US and they are notable for phosphatidylserine. Unless you are eating offal, there isn't a better source of phosphatidylserine than haricot beans. Yet, despite the wall of LLM slop, no mention of phosphatidylserine or whether this matters (allegedly phosphatidylserine is important for cell wall strength and you can get snake-oil-supplements if you are gullible).
Then there is the small matter of cholesterol. Not present in haricot beans because plants don't do cholesterol. However, why not explicitly state the big zero? You have cholesterol listed if I look up beef.
I am also not sure that I would describe a bean as a seed. What is the difference between a bean and a seed? Why not call it a grain? Or a nut? Or a plant-fetus?!?
I suppose a bean is a seed, but, for legumes, beans are beans, not seeds. It is 'baked beans' not 'baked seeds'. Coupled to this is the gym-bro-influencer on the carnival barker diet that has a biological hatred of 'seed oils', so 'seed' is already a controversial word in the world of gym-bro 'science'.
The search did return navy beans for the keywords 'haricot beans', but the results were different when I switched to my chosen locale. In fact, with the same search terms, I had three different result sets and no way of going back to the search page to see how the LLM gaslighting was going.
The big long list of amino acids cribbed from USDA in the full details was also perplexing. Which ones are essential and which ones can be made by 'liver gymnastics'?
Why does this matter? Beans and rice. Beans have some essential amino acids in abundance but not all, same with rice. So you need to mix and match.
Nit-picking at the navy beans seems unfair, but they are listed as 'boiled without salt'. So I look for the words 'salt' or 'sodium' and can't find the entry.
In the UK it is all about HFSS (High fat, sugar and salt). You can get salty plants, e.g. samphire, as consumed by people that watch the TV show 'Masterchef'. Therefore, it should not be assumed that salt (UK) or sodium (simplified English) needs to listed, even if the result is zero.
We have a traffic light system for HFSS on most foods. Haricot beans should be green for everything, whereas beef is going to be red for saturated fat. They don't have traffic light food labels in the USA because freedom, however, that is the important summary on the front of the pack.
Most American food is either banned or boycotted in the UK and Europe. US agricultural commodity crops just go into animal feed, to fatten animals kept in captivity. Therefore, everything on the USDA database is not applicable outside of the land of the burger.
This is particularly true for processed foods. An internationally recognised product such as a a KitKat bar will be formulated very differently for British tastes to European or American tastes. In the UK, HFSS rules will come into play, so the USDA values don't apply, even at the macro nutrient level.
Incidentally, according to the USDA there are FIVE macro nutrients, not three.
Since there is no attribution to USDA or wherever the pictures come from, with no links to describe what some of the micro nutrients are, does this help anyone? Is the content misleading to an international audience? I would say so.
So, what to do?
IMHO the USDA data is garbage as far as the rest of the world is concerned. It won't be possible to shoehorn it into a form even for a British audience any more than an American pick up truck makes sense on a British road. As for our cousins in countries that don't have English as their first language, you have your work cut out there.
Consider asking questions about whom the user is, and what their pain points are. The international traveller going to the USA could be that user you want. I know nobody is going to the US these days but times change and people will be back.
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.
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.
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.