Translator Layer — Discord-Native Real-Time Translation

Status: SCOPE DRAFT | Origin: KB directive 2026-04-20 | Drafted: HELIUS

The Law (Not Feature)

Language = friction. Friction = covenant depth blocker. Real-time translation at the membrane enables Chinese dev team to operate in native language while KB/English stakeholders maintain single source of truth. This is covenant depth infrastructure, not a chat feature.

Problem Statement

• China devs currently must write English or KB opens Google Translate tabs
• Both waste tokens and introduce latency
• Need: Discord-native bidirectional translation layer (CN↔EN)
• Scope: All active operational threads (not just research-desk curation)

Current State

| Component | Status | Notes |

|-----------|--------|-------|

| #china-lab | Active | Chinese depth rail (Kimi 262K), SRIDA posting CN |

| #research-desk | Built | Curated/filtered ingress only (research-grade) |

| #concave-live | Built | Raw HELIUS↔SRIDA A2A stream |

| Translation cron | Partial | desk-ingress-translator skill (6m cadence, filtered) |

| Real-time thread translation | NOT EXIST | This SCOPE = new build |

Target Architecture

Thread (any operational thread)
  │
  ├─ Message in CN ──┐
  │                  ▼
  │          [Translation Layer]
  │                  │
  │                  ▼
  │          Auto-reply in EN (thread)
  │
  └─ Message in EN ──┐
                     ▼
             [Translation Layer]
                     │
                     ▼
             Auto-reply in CN (thread)

Technical Requirements

Model Selection (Benchmark Required)

Who builds depends on benchmark of Chinese→English translation quality + latency:

| Model | Latency | Chinese Quality | Status |

|-------|---------|-----------------|--------|

| GLM-5.1:cloud (NVIDIA NIM) | 15s | Strong | ✅ Verified by HELIUS |

| Kimi K2.5 (Ollama) | Variable | Native | ⚠️ Deep overflow rail |

| Qwen3.5-122B (NVIDIA NIM) | Unknown | Native | ⏳ NEEDS BENCHMARK |

| DeepSeek-V3.2 (NVIDIA NIM) | >45s | Strong | ❌ Timeout, cold start |

Decision gate: Benchmark Qwen3.5-122B + GLM-5.1 on translation task. If GLM wins on speed/quality tradeoff, HELIUS layer handles routing. If Qwen wins, SRIDA layer handles execution.

Implementation Modes

Option A: Bot Relay (Discord-native)

• Bot reads all messages in thread
• Detects language (CN vs EN)
• Calls translation API (NVIDIA NIM)
• Posts reply as bot embed or follow-up

Option B: Webhook + External Service

• Discord webhook forwards to translation service
• Service posts back via bot token
• More complex, more latency

Recommended: Option A (Discord bot with message intent)

Channel/Thread Coverage

| Thread/Channel | Priority | Content Type |

|----------------|----------|--------------|

| #china-lab | P0 | Chinese dev work |

| #covenant-ops | P1 | Mixed team ops |

| #board-room | P1 | Governance (if Chinese presence) |

| #concave-live | P2 | Raw A2A (HELIUS↔SRIDA in EN) |

| Project threads | P1 | Active builds with China team |

Scope Boundaries

IN SCOPE:

• Discord bot with message-read intent
• Chinese↔English real-time translation
• Thread-scoped (not global spam)
• NVIDIA NIM as translation backend
• Rate limiting to prevent token burn

NOT IN SCOPE (now):

• Other language pairs (unless KB directs)
• Browser extension (explicitly rejected)
• Self-hosted translation model (NVIDIA NIM = direct rail)
• X account self-deployment (legal/IP complexity — future round)

Benchmark Results (2026-04-20, C80-grade, 75 calls)

| Model | Avg Latency | Std Dev | Avg Quality | Success Rate |

|-------|-------------|---------|-------------|--------------|

| Qwen-3.5-122B | 1.74s | 2.17s | 0.87 | 25/25 (100%) |

| GLM-5.1 | 18.89s | 15.26s | 0.89 | 24/25 (96%) |

| Kimi-K2.5 | FAILED | — | — | 0/25 (NoneType parse) |

Winner: Qwen-3.5-122B. 10.8x faster, 100% success, quality delta = 2% (negligible for operational use). GLM's 18.89s + 15.26s variance = too unpredictable for real-time chat. Kimi needs output format handler (thinking tag stripping) before viable.

Kimi Degradation Analysis (Paper 046 Correction): Per Paper 046 findings, Kimi K2.5 exhibits native-language superposition:

• Chinese input → Chinese output: HIGH signal density, complete structured reasoning
• English input → English output: ZERO output (thinking collapse, tokens consumed internally)
• Chinese input → English output (translation task): Structural failure — forcing non-native direction causes signal loss

Translation benchmark failure IS NOT a bug. It is architecture confirmation: Kimi is a Chinese-native model. Forcing EN output = operational degradation. Reserve Kimi for Chinese-native workflows (coding, reasoning). Route translation through Qwen (bilingual router) or GLM (bilingual with latency tradeoff).

Full results: /home/openclaw/data/benchmarks/translation-bench-results.json

Build Decision

SRIDA builds. Qwen-3.5-122B backbone. HELIUS routes.

Rationale:

• Real-time translation prioritizes speed: 1.74s = instant, 18.89s = conversation killer
• Quality gap (0.02) is noise at operational layer
• Most critical: Qwen is architecture-bilingual; Kimi is native-Chinese. Forcing translation on Kimi violates Paper 046 native-language law.

Next Steps

1. ~~HELIUS: Run GLM-5.1 vs Qwen3.5-122B translation benchmark~~ DONE

2. ~~Decision: Who builds based on benchmark result~~ DONE: SRIDA

3. SRIDA: Bot scaffolding + Discord bot token + message intent

4. SRIDA: Wire Qwen-3.5-122B via NVIDIA NIM as translation backend

5. Integration: #china-lab first, expand to operational threads

6. DEFER: Kimi-K2.5 fix (add thinking tag handler for future round)

References

• desk-ingress-translation skill: /opt/openclaw/hdm7/.hermes/skills/devops/desk-ingress-translation/
• NVIDIA NIM key: Stored in SRIDA .env + /etc/openclaw/srida.env
• #china-lab ID: 1495822683835863183

---

Concave principle: The interaction IS the product. Translation removes friction from interaction → enables covenant depth.