MenuBridge AI：保留本地菜式特色的本地 AI 餐牌翻譯工具

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.

What I Built

I built MenuBridge AI, a local AI-powered restaurant menu translation assistant.

The idea came from a practical problem in the hospitality industry.

Restaurants, cafés, hotels, villas, and other hospitality businesses often serve international guests and need multilingual menus. Translating normal text is relatively straightforward, but restaurant menus are different.

Local dishes such as:

• Kottu
• Pol Sambol
• Hoppers
• Lamprais
• Watalappan

have cultural meaning that can easily be lost when they are translated literally.

For example, a restaurant probably does not want Kottu converted into an awkward literal translation.

Instead, it may want something like:

Seafood Kottu
→
Kottu aux fruits de mer

while translating the description naturally for French-speaking customers.

That is what MenuBridge AI is designed to do.

It allows the restaurant to enter:

• Restaurant name
• Source language
• Target language
• Dish name
• Description
• Category

The restaurant can also maintain its own Restaurant Dictionary.

For example:

Term:
Kottu

Rule:
Keep the word Kottu in the translated menu name.

Another example:

Term:
Pol Sambol

Rule:
Keep Pol Sambol as the original dish name and describe it as a Sri Lankan coconut relish.

These rules are automatically included when the local AI model generates the translation.

Who would pay for it?

The target users are:

• Restaurants
• Cafés
• Hotels
• Villas
• Guest houses
• Food delivery businesses
• Tourism businesses

A small hospitality business may regularly need menu translations but may not have an in-house translator.

MenuBridge AI could therefore work as either:

• a one-time menu translation service, or
• a low-cost recurring menu translation tool.

The important part is that the restaurant can define how its own dishes should be handled instead of relying completely on a generic translator.

Demo

Here is my video demonstration of MenuBridge AI:

https://youtu.be/TvbMEBuHEhk

The demo shows the complete workflow:

Restaurant Setup
        ↓
Add Menu Item
        ↓
Restaurant Dictionary
        ↓
Translate with Local AI
        ↓
Review Translation
        ↓
Approve
        ↓
Translation History
        ↓
Export Approved Menu

The application also keeps generated translations and terminology rules locally so they remain available after refreshing the application.

Code

The complete source code is available on GitHub:

https://github.com/nadunjayaweera/OrderInRestaurant-ai.git

The project contains both the React frontend and Node.js/Express backend.

How I Built It

MenuBridge AI uses a relatively simple architecture:

React Frontend
      ↓
Node.js / Express
      ↓
Restaurant Dictionary
      ↓
Ollama
      ↓
Gemma 3 1B
      ↓
Structured JSON Translation
      ↓
Review / Approve
      ↓
Local JSON Storage
      ↓
CSV Export

Frontend

The frontend is built with:

• React
• Vite
• CSS

The interface contains three main areas.

1. Restaurant Setup

The user selects:

Restaurant Name
Source Language
Target Language

For example:

Restaurant: Ceylon Kitchen
Source: English
Target: French

2. Menu Item

The restaurant enters the existing menu item.

For example:

Dish:
Seafood Kottu

Description:
Chopped roti mixed with prawns, cuttlefish,
vegetables, egg, spring onions, and house spices.

Category:
Main Course

3. Restaurant Dictionary

This is one of the most important parts of the project.

Instead of asking a generic translation model to decide everything itself, the restaurant can provide terminology instructions.

For example:

Kottu
Keep the word Kottu in the translated menu name.

or:

Hoppers
Keep the original word Hoppers and explain that it
is a Sri Lankan bowl-shaped pancake.

These instructions are stored locally and sent to the AI when a menu item is translated.

Local AI

MenuBridge AI currently uses:

Gemma 3 1B

running locally through:

Ollama

The backend sends Gemma information about:

• the restaurant
• source language
• target language
• menu item
• description
• category
• restaurant terminology rules

I also instruct the model to follow several important rules:

- Preserve culturally important dish names.
- Follow the restaurant terminology rules.
- Never invent ingredients.
- Never remove ingredients.
- Do not change allergen or dietary information.
- Avoid awkward literal translations.
- Keep descriptions concise.
- Return valid JSON only.

Gemma then returns a structured result such as:

{
  "original_name": "Seafood Kottu",
  "translated_name": "Kottu aux fruits de mer",
  "translated_description": "Roti haché sauté avec des crevettes, de la seiche, des légumes, un œuf et des épices maison.",
  "cultural_note": "Kottu is a Sri Lankan dish name and has been preserved.",
  "kept_original_term": true
}

Using JSON output makes it much easier for the frontend to reliably display the generated translation.

Translation Review and Approval

I did not want the application to treat every AI-generated translation as automatically correct.

Every generated result is initially stored as:

GENERATED

The restaurant can review it and then approve it.

After approval:

APPROVED

is stored with the translation.

This gives the restaurant control over what eventually gets published.

That matters because even a good AI translation can sometimes choose terminology differently from what the business prefers.

Local JSON Storage

I intentionally kept the project lightweight.

Instead of adding MySQL or another database, MenuBridge stores its current data in local JSON files.

It stores:

Restaurant terminology rules
Generated translations
Approved translations

This means that refreshing the React application does not remove the restaurant's terminology or translation history.

It also keeps the MVP simple enough for a small business use case.

CSV Export

Approved menu translations can be exported as CSV.

The export includes information such as:

Restaurant
Category
Source Language
Target Language
Original Name
Original Description
Translated Name
Translated Description
Cultural Note

This makes the translated data easier to move into other workflows such as:

• Excel
• Google Sheets
• restaurant POS systems
• online menus
• QR menus
• printed menus

Testing with Sri Lankan Dishes

I tested MenuBridge with several Sri Lankan dishes because they are good examples of why restaurant translation needs context.

Some of the test items included:

Seafood Kottu
Pol Sambol
Egg Hoppers
String Hoppers
Lamprais
Isso Wade
Watalappan

For culturally important terms, I used restaurant dictionary rules to tell the AI when the original name should remain.

For example:

Lamprais

can remain Lamprais, while the menu description explains what it is to an international customer.

That is more useful than replacing the culturally recognized name with an overly literal translation.

Why Does Open Innovation Matter?

Open innovation is particularly important for MenuBridge AI because this is intended to be useful for small businesses.

Lower Operating Cost

A restaurant may translate hundreds of menu items over time.

It may also repeatedly update:

• seasonal dishes
• descriptions
• ingredients
• menu categories
• promotional menus

If every translation requires a paid cloud AI request, the operational cost grows with usage.

With MenuBridge AI, Gemma runs locally through Ollama.

Once the model is installed, the application does not need to pay an AI provider for every translation request.

That makes a low-cost side-hustle product much more realistic.

Privacy

Restaurants may also have menu information they would prefer to keep internally.

That could include:

• upcoming dishes
• recipe descriptions
• ingredient information
• internal terminology
• restaurant-specific naming conventions

Running the model locally means the core AI translation can happen on the restaurant's own machine rather than requiring the menu data to be sent to a remote AI service.

Restaurant-Specific Customization

This is probably the biggest advantage for this project.

A generic translator does not know how every restaurant wants its dishes represented.

MenuBridge allows a business to define instructions such as:

Kottu
→ Keep Kottu in the name

Pol Sambol
→ Keep the original term and explain that it is
a Sri Lankan coconut relish

Hoppers
→ Keep Hoppers and explain the type of dish

The open-weight AI model can then use these instructions as context.

This gives the restaurant more control over how its menu is translated.

Model Flexibility

The application is also not permanently tied to one commercial AI provider.

Because the inference layer runs through Ollama, I can experiment with other compatible open-weight models later.

That means MenuBridge could eventually evaluate different models for:

• translation quality
• language support
• speed
• hardware requirements
• restaurant terminology handling

without redesigning the entire product around one proprietary API.

Could This Become a Real Side Hustle?

Yes.

The project is intentionally small and focused on one business problem.

A possible service could be:

Restaurant provides their existing menu
        ↓
MenuBridge translates it
        ↓
Restaurant reviews translations
        ↓
Approved multilingual menu is exported

It could be offered as:

One-Time Menu Translation

for a restaurant that only needs an existing menu translated.

Or it could later become:

Monthly Menu Translation Service

for restaurants that regularly add or change dishes.

Future commercial features could include:

• Bulk Excel upload
• Multiple target languages at once
• Restaurant accounts
• Multiple restaurant profiles
• Translation editing
• QR menu generation
• POS integration
• Menu publishing
• Translation history
• AI-assisted allergen checks

For this challenge, however, I intentionally kept the MVP focused on the central problem.

What I Learned

This was another step in my journey of learning how open-weight AI can be integrated into real applications.

I practiced:

• Running Gemma locally with Ollama
• Connecting local AI to Node.js
• Building structured prompts
• Requesting predictable JSON output
• Validating model-generated data
• Connecting React to an AI backend
• Persisting application data with JSON
• Building review and approval workflows
• Exporting generated content to CSV
• Designing AI around a specific industry problem

One of my biggest takeaways from this project is that the model itself does not need to solve everything.

Giving the restaurant control through terminology rules makes the overall system much more useful.

The AI provides flexibility, while the restaurant provides domain knowledge.

That combination is what makes MenuBridge different from simply putting a generic translation box inside an application.

Final Thoughts

The goal of MenuBridge AI is simple:

Translate the menu, not the identity of the food.

A restaurant should be able to make its menu understandable to international customers while still keeping the names and cultural meaning that make its dishes unique.

Using Gemma locally through Ollama made it possible to build this without requiring a paid AI API or sending every menu item to an external AI provider.

For a small hospitality business, that combination of:

Local AI
+
Restaurant-specific terminology
+
Human review
+
Simple export

could become a practical and affordable menu translation workflow.