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.
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.