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.
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.
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).
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.
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.
> Create a dating app that matches people based on their interest in software development history. Use the BRL-CAD source code repository, the oldest known public version-controlled codebase in active development since 1983, as a conversation starter for tech-savvy singles looking for a unique and intellectually stimulating dating experience.
I learned about BRL-CAD today, not sure I would use it in a dating context, though.
I got my start in Clojure with ClojureScript. If you do front end web development it's a great way to jump in. I think I actually now prefer ClojureScript with the Reagent and Re-frame libraries more than standard React using js/TypeScript.