When we started building Alkemos, the hardest problem was not the math — it was the data. Nutrition databases are plentiful in English, but almost none of them treat Arabic as a first-class language. Food names, measurement habits, and even serving conventions differ across the Arabic-speaking world, and a database that ignores this ends up useless for the very audience it claims to serve.
Our food database now covers 8,830 foods, each with per-100g values in both English and Arabic. Getting here taught us three lessons that apply to anyone building a bilingual data product:
1. Translation is the easy 20%. The hard part is terminology: "habba" (Arabic for "one piece") versus grams, regional dish names that exist in one country and not another, and brand-local products that no international database will ever list. We ended up normalizing names around how people actually search — in Arabic first, then mapping to the English scientific name.
2. Per-100g values are the only honest default. Household measures vary; 100 grams does not. Every entry in our database carries per-100g macronutrient values, which also makes the data citable by writers and researchers who need a consistent basis. We document the full methodology publicly, because a number without a method is just a claim: data methodology.
3. A database is only as useful as the tools built on it. That is why the food database powers our interactive meal planner — you can build a meal from any of the 8,830 foods and watch the macros update live, in Arabic or English, with no signup.
If you write about nutrition for an Arabic-speaking audience, these resources are free to reference. The database lives at alkemos.com/foods, and the bilingual search works the same in both languages.
The bigger point: bilingual data is not a localization project. It is a data modeling decision you make on day one, or you spend years retrofitting it. We chose day one.
Top comments (0)