gemma translator - Moses Yebei

The Problem

Running real‑time voice translation on a small, offline device is hard. Cloud services add latency, cost, and a dependency on connectivity that many kiosk or handheld deployments cannot tolerate. This repo delivers a turnkey solution that runs a Gemma 4 model locally, captures microphone audio, and returns spoken translations without an internet connection.

What This Does

The project bundles a React/Vite UI and a Python FastAPI backend that together:

Front‑end (frontend/src/App.jsx) captures microphone input via useAudioRecorder, sends the raw waveform to the backend, and displays the translated text and synthesized speech in a terminal‑style UI (components/LanguageLane.jsx, components/ResponseDrawer.jsx).
Back‑end (backend/server.py) receives audio, forwards it to Moonshine for speech‑to‑text, then sends the text to LiteRT‑LM to run the gemma4‑e2b model locally. The resulting translation is returned as JSON, and the TTS engine converts it back to audio.
Deployment scripts (deploy-pi.sh, start.sh, setup.sh) automate the creation of a Python virtual environment, installation of dependencies, download of the LiteRT model, and launch of all services.

How It Is Wired

Entry Points

start.sh – orchestrates all services.
In dev mode: runs node --inspect frontend/ (Vite dev server) and python -m backend.server.
In prod mode: builds the React app (npm run build), starts backend/server.py (serves /dist/), and the LiteRT inference server (lite-rt start -m gemma4-e2b).

Control Flow

frontend/src/main.jsx mounts App.jsx.
App.jsx uses useAudioRecorder to capture mic data.
Recorder calls fetch('/api/transcribe', {body: audioBlob}).
backend/server.py receives the POST, streams the blob to Moonshine (moonshine.stt), gets text.
Text is sent to LiteRT (lite-rt run) via the API exposed in server.py.
The response JSON contains translation and a URL to an audio file.
App.jsx fetches the audio and plays it, while the translated text is displayed in ResponseDrawer.jsx.

Key Functions

server.transcribe() – handles /api/transcribe.
server.translate() – proxies to LiteRT.
server.tts() – streams audio back via Moonshine.

The backend is the single point with the widest blast radius: any change to the inference pipeline must be reflected in server.py. The frontend is decoupled; UI changes rarely touch the backend.

How To Use It

Setup

# Clone
git clone https://github.com/moses-y/gemma-translator

# Make scripts executable
chmod +x setup.sh download_model.sh start.sh deploy-pi.sh

# Install Python deps
./setup.sh          # creates venv, installs FastAPI, Moonshine, etc.

# Download the Gemma 4 model
./download_model.sh

Run Locally (Development)

./start.sh          # starts Vite dev server (http://localhost:5173) and backend

Run in Production Mode

./start.sh --prod   # builds UI, serves via backend on http://localhost:3000

Deploy to Raspberry Pi 5

./deploy-pi.sh     # installs systemd unit, builds UI, configures LXDE kiosk

Configuration

No external env vars are required for the provided scripts.
Model path is hard‑coded in download_model.sh to ~/.lite-rt/lm/gemma4-e2b.

Real‑World Use

An 8 GB Raspberry Pi 5 Raspberry‑Pi kiosk can sit in a museum exhibit and translate spoken questions into the exhibit’s language, all on a small 480×320 touchscreen. The UI remains responsive because the model inference runs locally and audio capture is piped directly to the backend.

Code Health & Issues

Medium/SDLC – No test files detected – 0 tests across 31 files.
Medium/SDLC – No CI/CD pipeline detected – no .github/ or ci/ folder.
No obvious security or licensing gaps beyond the MIT license.

The Bottom Line

This repo delivers a functional, offline voice‑translation stack that’s easy to deploy on a Raspberry Pi 5. The architecture is clear, but the lack of automated tests and CI limits confidence in future changes. Teams wanting a quick prototype can adopt it immediately; teams requiring production‑grade reliability should add tests and a CI pipeline.

What the analyser found

Deployment readiness

4/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

31 files

JSX7
JavaScript5
Shell4
Markdown2
JSON2
Python1

ReactExpress

Module dependencies

The 10 most depended-upon modules of 13, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_frontend_src_utils_api["api"] n1_frontend_src_TranslatorApp["TranslatorApp"] n2_frontend_src_App["App"] n3_d_src_hooks_useAudioRecorder["useAudioRecorder"] n4__src_components_LanguageLane["LanguageLane"] n5_rc_components_ResponseDrawer["ResponseDrawer"] n6_c_components_SettingsOverlay["SettingsOverlay"] n7_nd_src_components_Visualizer["Visualizer"] n8_rontend_src_utils_audio_blip["audio-blip"] n9_ntend_src_utils_audioHelpers["audioHelpers"] n2_frontend_src_App --> n1_frontend_src_TranslatorApp n2_frontend_src_App --> n6_c_components_SettingsOverlay n2_frontend_src_App --> n0_frontend_src_utils_api n1_frontend_src_TranslatorApp --> n4__src_components_LanguageLane n1_frontend_src_TranslatorApp --> n5_rc_components_ResponseDrawer n1_frontend_src_TranslatorApp --> n7_nd_src_components_Visualizer n1_frontend_src_TranslatorApp --> n3_d_src_hooks_useAudioRecorder n1_frontend_src_TranslatorApp --> n0_frontend_src_utils_api n1_frontend_src_TranslatorApp --> n8_rontend_src_utils_audio_blip n3_d_src_hooks_useAudioRecorder --> n9_ntend_src_utils_audioHelpers

Dependencies

6 of 47 declared dependencies are a major version behind. Resolved 47 of 47 against the registry.

Package	Declared	Latest	Behind
`vite`	^5.3.4	8.2.1	3 major
`@vitejs/plugin-react`	^4.3.1	6.0.5	2 major
`react`	^18.3.1	19.2.8	1 major
`react-dom`	^18.3.1	19.2.8	1 major
`@types/react`	^18.3.3	19.2.18	1 major
`@types/react-dom`	^18.3.0	19.2.4	1 major

Findings

MediumNo test files detected - untested code paths repository-wide
MediumNo CI/CD pipeline detected - no automated build/test gate .github/ or CI config

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

critical1

high3

medium3

low1

Upgrade the pinned dependency carrying a critical advisorycritical3 occurrences

anyio@4.14.1 CVE-2026-63374 (critical) +2 more

The manifest pins the exact version the advisory covers, so this is not a warning about drift: the vulnerable code is what installs, and a critical rating means it is reachable over the network without credentials or user interaction.

Fix: Upgrade to the fixed version named in the advisory, then commit the lockfile.

Add a test suite; this repository has nonehigh13 occurrences

13 source files, no test files

Any change ships with no signal that existing behaviour still holds, so a regression reaches production undetected.

Fix: Add one test per public entry point, then a CI step that runs them.

Add a workflow that builds and tests this repositoryhigh

13 source files, no CI configuration

Every change merges with nobody having run the build once, which across this estate is 499 repositories.

Fix: Add a workflow running the project build and test command on push and pull_request.

Replace the wildcard CORS origin with an explicit allow listhigh

backend/server.py

Access-Control-Allow-Origin', '*'

Any page on the internet can call the API with the browser's cookies attached, so a logged-in visitor to an unrelated site performs authenticated requests without knowing, and the wildcard combined with credentials is the exact configuration browsers refuse for that reason.

Fix: List the origins the API actually serves, and never pair a wildcard with credentials.

Enable Dependabot or Renovatemedium

2 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Move large binaries to Git LFS or out of the repositorymedium

stl/main-body.stl

1 blobs over 5MB: main-body.stl 6.5MB

One repository here carries twenty blobs over 5MB including a 10.9MB spreadsheet, so every clone and every CI checkout pays for data nobody diffs.

Fix: Track those extensions with LFS, or move datasets to object storage and fetch them in a setup step.

Give the outbound request a timeoutmedium

backend/server.py

1 outbound call(s) with no timeout

requests has no default timeout, so a peer that accepts the connection and then says nothing holds the worker forever, and with a small worker pool a single slow dependency takes the whole service down without anything appearing to fail.

Fix: Pass timeout= on every call, or use a session with one configured.

Add the repository convention files this project lackslow3 occurrences

missing .editorconfig, .gitattributes, a formatter config

Without them one contributor's editor writes tabs into a Python file, a shell script commits with CRLF and fails in the container, and a notebook diff is unreviewable.

Fix: Add .editorconfig, .gitattributes with text=auto eol=lf, and a formatter config.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.