Forem: Koushikxd

I Built Bridge, a Multilingual AI Health Companion for Everyone

Koushikxd — Fri, 13 Mar 2026 19:17:18 +0000

This idea came from the kind of problem everyday almost everyone in a family deals with at some point.

I mainly built this because daily medicines are already hard enough to keep track of, and doctors bad handwriting on prescriptions makes it even more confusing. A lot of times you get a prescription and dont fully understand what it says. If im allergic to something, I need to know what a meal, menu, or label includes before I eat it. And if im buying something from another country, I should be able to quickly understand what the label or packaging says

So thats why I built Bridge.

Bridge is a multilingual AI health companion that helps patients and caregivers setup a health profile, track medicines, upload health related images, and get short structured guidance in a language they can actually understand.

Why I Built It

I wanted to build a health app which was easy to use.

The goal with Bridge was never to make some doctor replacement, and also not to generate giant AI paragraphs that nobody wants to read. I wanted it to do a few things properly:

help a patient set up the important health details and blockers
track medicines and dose schedules + reminders
let users upload health related images like medicines, perscriptions, meals etc..
turn messy information into short, structured safety guidance
make the whole thing work in multiple languages
support voice based onboarding and assistant conversations too

That last part matters a lot. In healthcare, small misunderstandings can become big problems very quickly. If someone misses an instruction, takes the wrong medicine at the wrong time, or eats something unsafe because a label was hard to understand, thats not a small UX issue anymore. Thats real.

One important part here was lingo.dev. I did not want translation to feel like some side feature bolted on later. The app saves the users preferred language early in onboarding, and from there the interface and patient facing content can follow that locale. That means the app can feel more native to the user instead of always feeling like an english first product.

What Bridge Does

Bridge starts with onboarding. First the user chooses their preferred language. After that, the app collects health context like age, allergies, chronic conditions, dietary restrictions, religious restrictions, and any other notes that matter for safety.

I also added voice support in onboarding. Users can speak instead of typing everything, and Bridge can speak back too. I liked this part because it makes onboarding feel less like filling a form and more like an actual guided flow.

Then the app helps the user add medicines and dosing times. Once thats done, the home screen becomes a simple dashboard with:

active medicines
the next dose
dose actions like taken, skipped, or snoozed
progress from recent days
recent scans
caregiver access and linked profiles

The scan flow is the other big part of Bridge.

Users can upload things like:

prescriptions
medicine labels
food labels
meal photos
menus
other health related images

Bridge then runs OCR and AI analysis on the upload. Instead of returning a giant wall of text, it gives a structured result:

detected item
safety status
why it was flagged
suggested next action
confidence

If there are important details like allergens, ingredients, medicine instructions, or profile related conflicts, those get surfaced too. So the output feels more useful and less like "here is a bunch of text good luck".

This is also where lingo.dev became really useful for me. A user might scan a medicine package from another country, a restaurant menu, or some label they cannot read quickly. Bridge can analyze that and then present the useful result back in the users own language, which is honestly a huge part of the actual value. The important thing is not just "yes we translated it", but that the user can understand what it means for them without doing extra work.

This is a small part of the localization code I used for patient facing text:

const engine = new mod.LingoDotDevEngine({
  apiKey: process.env.LINGODOTDEV_API_KEY,
})

return await engine.localizeText(message, {
  sourceLocale: "en",
  targetLocale: normalizedLanguage,
  fast: true,
})

It looks simple, but that simplicity helped a lot. After Bridge figures out the useful result from a scan, I can localize the response into the users language instead of leaving them with english only output.

And this is the part where the AI scan result gets converted into the users locale after the image is analyzed:

const result = await analyzeWithVision(input)
const localizedResult = await localizeAnalysisResult(
  result,
  input.preferredLanguage
)

return { ...localizedResult, tier: "vision" }

So the flow is basically: analyze the image first, get a structured result, and then localize that result back into the users preferred language using lingo.dev. That was important to me because scanning a foreign package or menu is only useful if the final answer comes back in a language the user can understand quickly.

I also added a site AI assistant which supports both speech to text and text to speech. So users can talk to Bridge, ask about medicines, labels, prescriptions, or translations, and hear the answer back in their preferred language. For a health app, I think this makes the whole thing much more accessible.

The Main Idea Behind the Product

A patient does not just need another overengineered health app. They need something easier to act on. They need context. They need the app to remember their profile, medicines, and restrictions. They need the result to be short enough that they can understand it quickly, specially on a phone.

So Bridge is really trying to sit in between raw health information and actual patient action.

Not replacing doctors or medical professionals. Just helping people not get lost before they even know what they should ask.

For me, lingo.dev fits into this idea really well because the app is not only translating app text. It also helps Bridge deliver explanations and scan results in the users own locale. So if someone is more comfortable in Hindi, Tamil, Arabic, Spanish, or another supported language, the app can meet them there instead of forcing everything through english first.

Tech Stack

I kept the stack pretty practical and modern:

Next.js
React
lingo.dev for localization workflow
TypeScript
Convex for backend
Better Auth for authentication
AI SDK with Google Gemini
Tesseract OCR
Tailwind CSS
React Hook Form and Zod
Serwist for PWA support

Why I Chose This Stack

I picked Next.js because I'm very familiar with it and can help ship projects fast

I used Convex for backend because why not

Better Auth because it is wayy better than clerk

For AI features i used AI SDK by vercel obviously and gemini models because of the free monthly api limit honestly

I added Tesseract OCR as part of the image pipeline because not every image is clean, and extracting text is still useful even when the vision analysis is not perfect.

I also used lingo.dev to localize the whole app + others parts of the app where translation si needed

How the Flow Works

The full product flow is pretty straight forward:

User signs in
User selects a preferred language
User completes onboarding questions
User adds medicines and dose times
Home screen shows active tracking and recent activity
User uploads a health related image
Bridge analyzes the upload against the patient profile
User gets short structured guidance
User can use the assistant with text or voice in their preferred language
Caregivers can be linked to view and monitor their firends/family health status

I tried to keep every step simple. This app is meant to be used on phones too, so every screen had to feel light, clear, and direct.

One thing I learned while building this is that health products get messy very quickly if you over design them too early. I had to keep pulling the app back to the core question:

Does this help the user do the next safe thing?

If the answer was no, I tried not to add it. That was harder than I expected honestly but worked for me

The Feature I Like Most

My favorite part is honestly two things together, the straight to the point scanning and the care network feature.

The scanning part is my favorite because it does not just dump extracted text and leave the user to figure everything out. It tries to give a short useful result. If something looks risky, it says that. If it conflicts with allergies or restrictions, it highlights that. If confidence is low, it says that too.

Care Network

A lot of people do not manage health stuff alone. It can be parents, grandparents, partners, siblings, or close friends helping each other. That is why I built the care network into Bridge.

With the care network, a user can connect a trusted person to their profile so they can stay aware of what is going on. That includes things like medicine tracking, recent scans, and general health context. I liked this feature a lot because it makes the app feel more real and useful, not just like another AI tool showing results on a screen.

To me It adds a human side to the product. Instead of always checking on someone manually or asking the same health questions again and again, a caregiver or loved one can just stay connected and understand what is happening.

I think that matters a lot, especially for older adults, people recovering from something, or anyone who just does not want to manage everything alone.

Why This Matters

I think multilingual support in healthcare software gets treated like some extra bonus feature a lot of the time. It really is not.

For many users, language is the difference between independence and confusion.

If someone can understand their medicine, remember their schedule, share access with a caregiver, and get a simple explanation from a scanned label, that is already meaningful. Even if the app only helps them avoid one mistake, that still matters.

Bridge is still an early project, but I think the direction is strong because the problem itself is very real.

What I Learnte From Building It

A few things really stood out while building Bridge:

structured AI output is much more useful than long generated text
profile context makes scan analysis way more valuable
voice support makes onboarding and assistant flows easier for some users
localization makes it easy for user's who don't speak english natively

Closing

Bridge is my attempt at building a health companion that is multilingual, practical, and actually usable by real people instead of being just another health app

It helps patients and caregivers set up context, track medicines, scan health related information, and get short structured guidance that would be really helpful to them.

There is still a lot I want to improve and add but I am happy with the core idea and the direction its going in and might add more updates and functionalities in the future.

If you want to check it out:

GitHub: https://github.com/koushikxd/bridge

Built for the lingo.dev hackathon.

Lingo Bolt: Removing the Language Barrier From OpenSource

Koushikxd — Thu, 19 Feb 2026 14:29:10 +0000

A few months ago I tried to contribute to a Japanese open source project. The codebase looked interesting, the issues seemed approachable, but everything was in Japanese. The README had a small english section but half the steps were wrong or missing. I spent an hour just trying to get it running locally and eventually gave up.

I'm a native english speaker. If I had that much trouble, what chance does someone in Brazil or Korea have when they're trying to contribute to a project thats entirely in english?

That's the problem I wanted to fix.

The Problem

Open source is supposed to be for everyone but in practice it runs almost entirely in english. This creates two groups of people who get left out:

Contributors who don't write english well. They might be great developers but they can't properly describe their bug, or they can't understand a maintainers review comment well enough to respond. So they stop trying.

Maintainers who get issues in other languages. Someone's project gets shared in a Brazilian developer community and suddenly there are 5 issues in Portuguese. The maintainer has no idea what they say so they close them or ignore them.

Both sides lose. The project loses contributors and the contributors feel unwelcome.

What I Built

Lingo Bolt is a web app plus a GitHub bot that tries to fix this. You sign in with GitHub, connect a repo, and you get a few tools that let you work with it in any language.

The GitHub Bot

This is the main feature and the part that requires zero effort from contributors. You install the lingo-bolt GitHub App on your account or org, configure your default language and thats it. The bot starts listening to your repos through GitHub webhooks.

How the webhook flow works

When GitHub sends an event to our webhook endpoint, the app verifies the signature and routes it to the right handler. There are three events we care about:

issues.opened         --> new issue was filed
pull_request.opened   --> new PR was opened
issue_comment.created --> someone commented on an issue or PR

Auto language detection and labeling

When a new issue comes in, the bot uses GPT-4o-mini to detect what language its written in and creates a label like lang:portuguese or lang:chinese and applies it to the issue automatically.

This is useful even without translation. Maintainers can filter issues by language label and at least know what they're dealing with.

Auto translation

If auto-translate is enabled, the bot detects the language of the content and if its different from the maintainer's default language, it translates it and posts a comment with the translated version. It skips posting if the detected language already matches the default, so you don't get noise when issues are already in the right language.

const detected = await detectLanguageCode(text);
if (detected === locale || detected === locale.split("-")[0]) return;

const translated = await engine.localizeText(text, {
  sourceLocale: detected,
  targetLocale: locale,
});

await postComment(octokit, owner, repo, issueNumber,
  `**Auto-translated to ${defaultLanguage}:**\n\n${translated}`
);

Manual commands

Beyond the automatic stuff, anyone can trigger the bot manually by mentioning @lingo-bolt in a comment:

@lingo-bolt translate to spanish    --> translates the issue body to Spanish
@lingo-bolt summarize               --> summarizes in the maintainer's default language
@lingo-bolt summarize in french     --> summarizes in French specifically

The summarize command is really useful for long threads. It uses GPT to write a concise summary of the issue, then if the target language isn't english it translates that summary using Lingo.dev before posting it as a comment.

const { text: summary } = await generateText({
  model: openai("gpt-4o-mini"),
  prompt: `Summarize the following GitHub issue/PR content concisely. Keep it clear and actionable.\n\n${text}`,
});

if (locale !== "en") {
  finalText = await engine.localizeText(summary, {
    sourceLocale: "en",
    targetLocale: locale,
  });
}

Per-repo overrides

The bot dashboard lets you configure settings at both the installation level and per individual repo. So if you have an org with 10 repos but only want auto-translate on 3 of them, you can set that up without it affecting the rest.

RAG Indexing + AI Chat

Once you connect a repo, you can index it. The app clones it, chunks the code, embeds it using text-embedding-3-small, and stores it in Qdrant. After that you can chat with the repo in any language.

But its more than just a Q&A bot. The chat has tools that can fetch live data from GitHub — open issues, pull requests, issue details. So you can ask things like:

"show me open issues that look easy to fix"
"what does issue #42 need, explain it to me"
"how does the authentication work in this codebase"
"where should I start if I want to add dark mode"

And because the chat also has access to the indexed codebase, it can point you to the exact files and functions relevant to whatever issue you're looking at. You ask about an issue, it finds the relevant code, explains whats happening, and tells you where to look.

For someone who's not confident in english, being able to ask all of this in their own language and get answers that reference actual code in the repo removes two blockers at once: the language barrier and the "i dont know where to start" barrier that most new contributors hit.

const SUGGESTED_PROMPTS = [
  { key: "chat.prompt.showOpenIssues" },
  { key: "chat.prompt.recommendEasyIssue" },
  { key: "chat.prompt.listOpenPrs" },
  { key: "chat.prompt.searchEntryPoint" },
];

MCP Server (IDE Integration)

This one I'm quite happy with. Lingo Bolt exposes an MCP server so you can use its tools directly inside Cursor, VS Code, or any IDE that supports MCP. No separate build step needed — it runs as a remote HTTP endpoint inside the web app at /api/mcp.

Add this to opencode/opencode.json or .cursor/mcp.json:

{
  "mcpServers": {
    "lingo-bolt": {
      "type": "remote",
      "url": "http://localhost:3000/api/mcp"
    }
  }
}

Then you can ask your IDE things like:

Show me open issues for facebook/react in Spanish
Get issue #42 from vercel/next.js in Hindi
Translate the README of expressjs/express to Japanese
Search the codebase of my-org/my-repo for authentication logic

The available tools are:

Tool	What it does
`list_issues`	List issues with titles translated to your language
`get_issue`	Fetch a full issue with comments, translated
`translate_doc`	Translate any file (README, CONTRIBUTING, etc.)
`translate_text`	Translate arbitrary text between languages
`search_codebase`	Semantic search across an indexed repo
`get_onboarding`	Fetch AI-generated onboarding docs for a repo

The list_issues and get_issue tools auto-detect the repo from your current git directory if you don't specify owner/repo. So inside a repo you can just say "show me open issues in Japanese" and it figures out the rest.

There's also a standalone stdio-based MCP package (packages/mcp) if you prefer not running the web app. Same tools, same idea, just runs as a local process.

AI Onboarding Docs

When you index a repo, the app reads through the codebase using RAG and generates proper onboarding documentation — what the project does, how to set it up, the key concepts. You can then translate those docs into any supported language.

So a new contributor from Japan can get onboarding docs in Japanese, based on the actual code and not just whatever the original author wrote (or didn't write).

const ragResults = await Promise.all(
  RAG_QUERIES.map((query) => queryRepository({ query, repositoryId, limit: 8 }))
);

if (locale !== "en") {
  const translated = await engine.localizeText(accumulated, {
    sourceLocale: "en",
    targetLocale: locale,
    fast: true,
  });
}

Markdown Translation

A lot of repos have multiple markdown files beyond just the README — contributing guides, architecture docs, api references. Lingo Bolt clones the repo, finds all the markdown files, and translates the whole set using the Lingo.dev SDK. You can download them individually or as a zip.

The Whole App UI is Translated

The app UI adapts to your preferred language. Instead of shipping JSON translation files for every language, all UI strings are stored in english and translated on demand using engine.localizeObject() from the Lingo.dev SDK. The result is cached so it only fetches once per session.

const translated = await engine.localizeObject(UI_MESSAGES_EN, {
  sourceLocale: "en",
  targetLocale: body.targetLocale,
  fast: true,
});

This means we support 15 languages without maintaining any translation files manually.

Architecture

User
 |
Next.js App
 |
 +-- tRPC routers (repo, bot, user)
 |
 +-- Route handlers
      |
      +-- /api/mcp              --> MCP server (IDE integration)
      +-- /api/repository/index --> clone + embed chunks --> Qdrant
      +-- /api/chat             --> RAG + GitHub tools + GPT stream
      +-- /api/onboarding/generate  --> RAG + GPT stream
      +-- /api/onboarding/translate --> Lingo.dev
      +-- /api/markdown/translate   --> clone + Lingo.dev
      +-- /api/ui/translate         --> Lingo.dev localizeObject
      +-- /api/webhook          --> GitHub App events
           |
           +-- issues.opened        --> auto-label, auto-translate
           +-- pull_request.opened  --> auto-label, auto-translate
           +-- issue_comment.created --> @lingo-bolt command parsing

PostgreSQL (repos, docs, translations, bot installations)
Qdrant (code chunks for semantic search)

How Lingo.dev Is Used

Feature	SDK method
GitHub issue/PR translation (bot)	`localizeText`
AI chat responses	`localizeText`
Onboarding doc translation	`localizeText`
Markdown file translation	`localizeText`
MCP tool responses	`localizeText`
UI string translation	`localizeObject`

Tech Stack

Next.js App Router + React 19
Lingo.dev SDK
tRPC + TanStack Query
Better Auth (GitHub OAuth)
Prisma + PostgreSQL
Qdrant (vector store)
OpenAI (gpt-4o-mini + text-embedding-3-small)
Tailwind CSS + shadcn/ui
Turborepo + PNPM

Language shouldn't be the thing that decides who gets to participate in open source. That's really all this is about.

The project is open source at github.com/koushikxd/lingo-bolt.