Multilingual Recipe Search

Wed, 21 Oct 2026 19:31:41 +0000

When building Recipe Finder, we hit a frustrating limitation with our upstream data provider: the Spoonacular API only understands English queries.

If a user typed a craving in their native language—like cartofi in Romanian or стейк in Cyrillic—the search returned zero results, even when hundreds of matching recipes existed in the database. Worse, our search fallback logic would spend up to four API requests trying to find matches before giving up and rendering an empty state.

Rebuilding the entire platform around a new recipe database wasn't practical. Instead, for Release 2.20.0, we built a lightweight, fail-safe translation layer in front of the search pipeline using Google Gemini Flash and a normalized lookup cache.

What's New

Until now, Recipe Finder searched in English only. With release 2.20.0, the search automatically detects which language you wrote in and finds the exact same recipes you would get by searching in English:

Search in the language you think in, with no need to translate first.
Full support for non-Latin alphabets (e.g., Cyrillic queries return steak recipes, and searching for cartofi in Romanian returns potato recipes).
Zero impact on English queries, which behave identically to before.

How It Works: The Architecture

The core rule is deliberately simple: if a query is in English, we use exactly what you typed; if it isn't, we resolve its English translation before hitting the recipe API.

                [ Raw Query: "cartofi" ]
                            │
                            ▼
              ┌───────────────────────────┐
              │ Normalize (case & spaces) │
              └─────────────┬─────────────┘
                            │
                            ▼
                     ┌─────────────┐
           ┌─────────┤  DB Cache   ├─────────┐
           │         └─────────────┘         │
      MISS │                                 │ HIT
           ▼                                 │
 ┌───────────────────┐                       │
 │ Gemini Flash API  │                       │
 │ (Reasoning: Off)  │                       │
 └───┬───────────┬───┘                       │
     │           │                           │
   OK│           │ERROR / SLOW               │
     ▼           │(Fallback: raw query)      │
┌─────────┐      │                           │
│ Save DB │      │                           │
└────┬────┘      │                           │
     │           │                           │
     └───────────┴──────────┬────────────────┘
                            │
                            ▼
                [ Resolved: "potatoes" ]
                            │
                            ▼
              ┌───────────────────────────┐
              │  Spoonacular Search API   │
              │  & Relevance Re-Ranking   │
              └───────────────────────────┘

Step-by-Step Pipeline

Cache first: The incoming query is normalized (case and spacing) and looked up in our database. If we have seen it before, we already know the answer and skip the AI layer entirely.
One language check: On a first-time query, a single request to Google Gemini Flash decides whether the text is English and, if not, returns the English equivalent. Both outcomes are saved to the database—including "this is already English"—so common English searches never trigger a second check.
Search and rank with the right query: The recipe search runs with the resolved query, and results are ranked against it so the best matches appear first.
Safe by design: If the language check is slow, fails, or the database is unavailable, the search simply runs with the original query, exactly as it did before this release. Translation can never break a search.

Key Engineering Trade-offs

1. Sequential vs. Parallel Execution

We chose to run the language check before the recipe search, rather than in parallel. Running both at once would hide the wait on uncached queries, but it would also spend a recipe-search request on every non-English query—and that daily API quota is our scarcer resource.

2. Disabling Extended Reasoning

We disabled Gemini's extended reasoning for this specific request. Detecting and translating a short food phrase doesn't need chain-of-thought tokens, and leaving it off keeps the call significantly faster and cheaper. Other AI features in the app remain unaffected.

Performance and Cost

Speed: In our testing, first-time searches completed in roughly 1 to 1.5 seconds end-to-end, including the recipe search itself. Repeat searches hit the cache and skip the language check entirely.
Cost: Based on Google's published Gemini Flash pricing, we estimate roughly $0.0001 per language check, which works out to about $1 for every 10,000 new, distinct searches. Repeated searches cost nothing because of the cache.
Fewer wasted requests: A non-English search used to consume up to four recipe-search requests and still find nothing. It now uses one.

Current Limitations & What's Next

Recipe titles and descriptions are still shown in English, because that is how the recipes are stored upstream.
The results page currently displays what you typed rather than its translated equivalent.
The ingredient include/exclude filters are not translated yet.
The first search for a brand-new phrase takes slightly longer than a repeat search.

Next, we plan to add a "Showing results for…" indicator so it's clear when a search was translated, and extend the same translation pipeline to the ingredient filters.

If there's a language or regional dish phrase that doesn't work well for you, we'd love to hear about it—give it a try at recipe-finder.org!

Coder Legion - Recent posts tagged mutlilanguage