[Jervais/Even G2] Modul 1 Übersetzung – Stufe 0 testen (nächste Woche) #137

New issue

Open

opened 2026-07-05 19:26:28 +00:00 by orbitalo · 0 comments

orbitalo commented

2026-07-05 19:26:28 +00:00

Owner

Ziel

Live-Übersetzung Khmer→Deutsch auf Even Realities G2 (MentraOS). Modul 1 ist der primäre, kurzfristige Baustein. Vor jedem Server-Aufwand: MentraOS-eigene Übersetzung testen (Stufenplan).

Nächster Schritt (höchste Prio)

Stufe 0 – MentraOS-eigene Übersetzung testen (~1 Tag)

Fertige Community-App bzw. Subscription translation:km-KH-to-de-DE mit echtem Khmer-Audio testen
Referenz: Mentra-Community/LiveTranslationOnSmartGlasses
Prüfen: ist das Sprachpaar km→de in der MentraOS-Konsole tatsächlich freigeschaltet?
Bewerten: Qualität + Latenz ausreichend? → wenn ja: fertig, KEIN eigener Server nötig

Offene Verifizierungspunkte

MentraOS Auto-/Multi-Source-Subscription – existiert translation:auto-to-de o.ä. im SDK? Trägt den "kleine Kandidatenliste statt jede Sprache"-Anspruch. (Azure-LID: max. 4–10 Kandidaten, kein Open-Range über MentraOS bestätigt, kein Code-Switching pro Satz.) Am besten VOR Stufe 0 im SDK-Code nachschlagen.
Khmer in ElevenLabs Scribe v2 Realtime – Realtime existiert (WebSocket, ~150ms, PCM 16kHz, VAD). Batch kann Khmer (Moderate 20–50% WER), Realtime-Benchmark nur 30 Sprachen → Khmer-Realtime-Support/-Qualität per direktem API-Call gegen echtes Khmer-Audio prüfen. Nur relevant falls später ElevenLabs statt Google für Stufe 2.
Ring-Zuverlässigkeit (R1) unter MentraOS – Launch-Feedback meldet Unzuverlässigkeit. Praktisch testen, Bügel-Touchpad als Fallback einplanen. Menü über Doppelklick (DOUBLE_CLICK_EVENT), NICHT Long-Press (existiert nicht in Ring-API).

Fallback-Stufen (nur falls Stufe 0 nicht reicht)

Stufe 1: eigener AppServer auf Proxmox, nur transcription-Stream (km-KH, Azure) + eigene Übersetzung (Google/Microsoft). Kein audio_chunk-Handling.
Stufe 2: volle Eigenbau-Pipeline: audio_chunk (PCM) → Google STT V2 (chirp_3, regionaler Recognizer eu/asia-southeast1, NICHT v1 language_code) → Translation → showTextWall(). Laufende Google-API-Kosten (STT ~$0,016–0,024/min + Translation/Zeichen) fallen kontinuierlich an. Latenz realistisch oberes Ende 0,7–1,2s+ (Extra-Hop über MentraOS-Cloud).

Bestätigte Fakten (Recherche 05.07.)

Honcho representation() = read-only Snapshot ohne LLM-Call/Neuberechnung (Modul 2)
Even G2 + MentraOS voll unterstützt, roher Audio via audio_chunk/session.mic.onAudioChunk erreicht auch entfernte Cloud-Apps
Azure kann Khmer STT; Soniox nicht

Grundsatz

Vor jedem Umsetzungsschritt die höhere Stufe erst ausschließen. Aktueller Stand: Stufe 0 ist der nächste Schritt, nicht Stufe 2.

## Ziel Live-Übersetzung Khmer→Deutsch auf Even Realities G2 (MentraOS). Modul 1 ist der primäre, kurzfristige Baustein. Vor jedem Server-Aufwand: MentraOS-eigene Übersetzung testen (Stufenplan). ## Nächster Schritt (höchste Prio) **Stufe 0 – MentraOS-eigene Übersetzung testen (~1 Tag)** - [ ] Fertige Community-App bzw. Subscription `translation:km-KH-to-de-DE` mit echtem Khmer-Audio testen - [ ] Referenz: `Mentra-Community/LiveTranslationOnSmartGlasses` - [ ] Prüfen: ist das Sprachpaar km→de in der MentraOS-Konsole tatsächlich freigeschaltet? - [ ] Bewerten: Qualität + Latenz ausreichend? → wenn ja: fertig, KEIN eigener Server nötig ## Offene Verifizierungspunkte 1. **MentraOS Auto-/Multi-Source-Subscription** – existiert `translation:auto-to-de` o.ä. im SDK? Trägt den "kleine Kandidatenliste statt jede Sprache"-Anspruch. (Azure-LID: max. 4–10 Kandidaten, kein Open-Range über MentraOS bestätigt, kein Code-Switching pro Satz.) Am besten VOR Stufe 0 im SDK-Code nachschlagen. 2. **Khmer in ElevenLabs Scribe v2 Realtime** – Realtime existiert (WebSocket, ~150ms, PCM 16kHz, VAD). Batch kann Khmer (Moderate 20–50% WER), Realtime-Benchmark nur 30 Sprachen → Khmer-Realtime-Support/-Qualität per direktem API-Call gegen echtes Khmer-Audio prüfen. Nur relevant falls später ElevenLabs statt Google für Stufe 2. 3. **Ring-Zuverlässigkeit (R1) unter MentraOS** – Launch-Feedback meldet Unzuverlässigkeit. Praktisch testen, Bügel-Touchpad als Fallback einplanen. Menü über Doppelklick (`DOUBLE_CLICK_EVENT`), NICHT Long-Press (existiert nicht in Ring-API). ## Fallback-Stufen (nur falls Stufe 0 nicht reicht) - **Stufe 1:** eigener AppServer auf Proxmox, nur `transcription`-Stream (km-KH, Azure) + eigene Übersetzung (Google/Microsoft). Kein audio_chunk-Handling. - **Stufe 2:** volle Eigenbau-Pipeline: audio_chunk (PCM) → Google STT V2 (chirp_3, regionaler Recognizer eu/asia-southeast1, NICHT v1 language_code) → Translation → showTextWall(). Laufende Google-API-Kosten (STT ~$0,016–0,024/min + Translation/Zeichen) fallen kontinuierlich an. Latenz realistisch oberes Ende 0,7–1,2s+ (Extra-Hop über MentraOS-Cloud). ## Bestätigte Fakten (Recherche 05.07.) - Honcho `representation()` = read-only Snapshot ohne LLM-Call/Neuberechnung (Modul 2) - Even G2 + MentraOS voll unterstützt, roher Audio via `audio_chunk`/`session.mic.onAudioChunk` erreicht auch entfernte Cloud-Apps - Azure kann Khmer STT; Soniox nicht ## Grundsatz Vor jedem Umsetzungsschritt die höhere Stufe erst ausschließen. Aktueller Stand: Stufe 0 ist der nächste Schritt, nicht Stufe 2.