OpenRouter spricht jetzt 简体中文, Español, Português (Brasil), Deutsch, Français, 日本語 und 한국어, neben Englisch. Die Lokalisierung ist im Beta-Stadium und startet heute. Zum Wechseln wählt man eine Sprache im Kontomenü aus oder geht direkt zu einer Adresse wie openrouter.ai/ja oder openrouter.ai/ko/models.
Eine Website zu übersetzen und die Übersetzung aktuell zu halten, ist schwierig – bei uns besonders. Die OpenRouter-Website hat 16,918 englische Zeichenketten, und wir ändern jeden Tag einige davon, sodass eine einmalige Übersetzung binnen einer Woche veraltet wäre. Wir haben eine Schleife gebaut, die uns dabei im großen Stil hilft. Jeden Tag findet sie die geänderten Zeichenketten, übersetzt sie, prüft sie im Code und lässt ein zweites Modell die Bedeutung gegen das Englische verifizieren. Wenn eine Übersetzung eine Prüfung nicht besteht oder der Verifizierer sie ablehnt, schickt die Schleife sie mit dem angegebenen Grund zurück und versucht es erneut. Diese Wiederholungsschleife ist der Teil des Systems, der sich selbst korrigiert.
Einige Fehler schaffen es trotzdem daran vorbei, und Menschen finden diese. Wenn Prüfer und Leser einen Fehler melden, machen wir daraus eine Glossarregel, einen Stilhinweis oder eine Überschreibung, und Fehler, die die tägliche Prüfung findet, werden außerdem zu Testfällen, die jedes künftige Modell bestehen muss. Die gesamte Pipeline läuft auf OpenRouter.
Übersetzungen liegen in Git neben dem Code
Bevor ein Modell überhaupt beteiligt wird, brauchen die Übersetzungen ein Zuhause. Wir nutzen die Open-Source- General Translation -Runtime, um Zeichenketten in unserem React-Code zu umschließen. Wir commiten Übersetzungen als JSON-Kataloge neben dem Code und laden sie lokal zur Laufzeit, sodass kein Übersetzungsdienst im Anfragepfad sitzt. Eine Zeichenkette wird binnen eines Tages nach ihrem Merge zur Übersetzung aufgenommen. Bis dahin zeigt die Seite den englischen Quelltext. Jeder übersetzte Eintrag speichert außerdem einen Fingerabdruck des Englischen, aus dem er stammt. Wenn jemand das Englische bearbeitet, passt der Fingerabdruck nicht mehr, und der Eintrag kommt zurück in die Warteschlange. Diese Regel ermöglicht es dem täglichen Lauf, jeden veralteten Eintrag zu finden, ohne den ganzen Katalog neu zu übersetzen.
Die Pipeline
Jede Zeichenkette in dieser Warteschlange durchläuft fünf Stadien, bevor sie die Website erreicht.
1. Extrahieren
Ein Skript durchsucht das Frontend und schreibt jede umschlossene englische Zeichenkette in einen Quellkatalog. Jeder Eintrag erfasst seine Datei und seine UI-Rolle, etwa Button, Überschrift oder Tabellenkopf. Die Rolle ist wichtig, weil dasselbe englische Wort an anderer Stelle eine andere Übersetzung benötigen kann. „Queue“ auf einem Button ist eine Anweisung, und einer der Fehler später in diesem Beitrag ist ein Modell, das es als Substantiv übersetzt.
2. Übersetzen
Wir senden neue und geänderte Zeichenketten in Batches von bis zu 40 an GPT-6.1 Sol und nutzen Structured Outputs , um die Antwort an ein striktes JSON-Schema zu binden. Jede Anfrage enthält unsere globalen und sprachspezifischen Stilhinweise, die Glossarregeln für jeden Produktbegriff im Batch und die UI-Rolle jeder Zeichenkette.
Hier ist ein vereinfachtes Beispiel einer Übersetzer-Anfrage für einen japanischen Batch, mit gekürzten Stilhinweisen und Glossarregeln.
{
"model": "openai/gpt-6.1-sol",
"messages": [
{
"role": "system",
"content": "Translate OpenRouter UI strings into Japanese. ..."
},
{
"role": "user",
"content": "[{\"id\":\"q1\",\"role\":\"button\",\"text\":\"Queue\"}]"
}
],
"response_format": {
"type": "json_schema",
"json_schema": {
"name": "translations",
"strict": true,
"schema": {
"type": "object",
"properties": {
"translations": {
"type": "array",
"items": {
"type": "object",
"properties": {
"id": { "type": "string" },
"text": { "type": "string" }
},
"required": ["id", "text"],
"additionalProperties": false
}
}
},
"required": ["translations"],
"additionalProperties": false
}
}
}
}Da jedes Modell auf OpenRouter dieselbe Anfrage entgegennimmt, bedeutet der Versuch eines anderen Übersetzers nur eine Änderung des Modell-Slugs. So haben wir den Modellvergleich später in diesem Beitrag durchgeführt.
3. Prüfen
Der Code weist eine Antwort zurück, die einen ICU-Platzhalter, einen Plural-Zweig, ein Rich-Text-Tag oder führende bzw. nachgestellte Leerzeichen beschädigt, oder die einen Produktbegriff in einer vom Glossar verbotenen Form wiedergibt. Wir senden einen abgelehnten Batch in kleineren Teilen erneut und benennen dabei den Fehler, standardmäßig für bis zu 4 Durchläufe. Das Limit ist eine Einstellung, die bis 20 gehen kann. Eine Zeichenkette, die nach dem letzten Durchlauf weiterhin fehlschlägt, bleibt auf Englisch und wird im Pull Request markiert.
4. Verifizieren
Ein zweiter Aufruf desselben Modells, als Verifizierer agierend, liest jede Übersetzung gegen das Englische und listet Fehler nach Schweregrad auf. Jeder kritische oder schwere Fehler, etwa ein ausgelassener Satzteilverweis oder ein umgekehrter Sinn, schickt die Zeichenkette mit allen bisherigen Einwänden an den Übersetzer zurück. Der Übersetzer erhält bis zu 3 Wiederholungsversuche nach seinem ersten Versuch, und der letzte Wiederholungsversuch verwendet mehr Reasoning-Aufwand. Die Kosten pro Zeichenkette haben kein separates Limit, da die Wiederholungsgrenzen sie bereits begrenzen. Mitgezählt die Prüf-Wiederholungen kann eine Zeichenkette bis zu vier Übersetzungsversuche mit jeweils bis zu vier Prüfdurchläufen benötigen, plus einen Verifizierer-Aufruf nach jedem Versuch. Das ergibt im schlimmsten Fall etwa 20 Modellaufrufe pro Zeichenkette und Sprache. Ist der Verifizierer nicht verfügbar, schreibt die Pipeline nichts, und die Zeichenkette bleibt auf Englisch. Ein Leser, der einen Tag lang Englisch sieht, ist besser dran als einer, der eine ungeprüfte Übersetzung sieht.
5. Überprüfen
Jeder tägliche Batch landet als Pull Request. Ein KI-Reviewer liest den Diff und veröffentlicht Feststellungen, und ein Mensch mergt den Pull Request.
Wie wir messen
Der Rest dieses Beitrags stützt sich auf drei Eval-Suiten, daher hilft es, vor den Zahlen zu wissen, was jede einzelne testet.
- Der Modellvergleich (254 Fälle) führt die Pipeline mit verschiedenen Übersetzermodellen aus und bewertet jede Antwort mit dem Produktions-Verifier. Wir haben damit den Übersetzer ausgewählt.
- Der Pipeline-Vergleich (454 Fälle) führt ein Modell zweimal aus, einmal durch die volle Pipeline und einmal mit einem bloßen Zwei-Zeilen-Prompt. Code-Prüfungen, der Verifier, Richter aus drei anderen Modellfamilien und ein Back-Translation-Check bewerten es alle.
- Die Defects-Suite (22 Fälle) enthält echte Fehler, die die tägliche Überprüfung nach dem Bestehen durch den Verifier entdeckt hat. Jeder Fall verbietet den Fehler, der ausgeliefert wurde.
Was wir versucht und wieder verworfen haben
Die Pipeline sieht jetzt einfach aus, weil wir drei Teile des ersten Entwurfs entfernt haben, nachdem die Evals sie gemessen hatten.
Ein günstigerer Übersetzer
Wir haben zunächst ein kleineres, günstigeres Modell getestet, GPT-6 Luna (openai/gpt-6-luna). Im Modellvergleich bestand es 91.7% der Fälle beim ersten Versuch, gegenüber 99.2% bei GPT-6.1 Sol. Seine schwächsten Sprachen waren Koreanisch und Japanisch. Seine schwerwiegendsten Fehler waren Antworten, die General Translation, unser Übersetzungsframework, nicht kompilieren konnte, etwa seine Übersetzung von „Legacy alias of {value}“. Diese Fehler hielten bei jedem Retry an.
Das schwerere Modell kostete etwa das 3.4-Fache, $1.94 gegenüber $0.57 für diese 254 Fälle. Wir zahlen die Differenz, weil eine falsche Zeichenkette, die nie konvergiert, mehr Zeit und Aufwand zur Behebung kostet, als es gleich beim ersten Mal richtig zu machen.
Ein separates Beurteilungsmodell
Bevor der Verifizierer existierte, bewertete ein separates Beurteilungsmodell jede Übersetzung, und wir übersetzten alles erneut, was es markierte oder als unsicher einstufte. Um zu sehen, wie gut es funktionierte, verschlagworteten wir einen Benchmark mit drei Arten von Zeichenketten: bekannte Fehler, korrigierte Übersetzungen (von Hand korrigierte Versionen früherer Fehler, die bestehen sollten) und eine saubere Stichprobe. Das Beurteilungsmodell erkannte tatsächlich echte Probleme. In einem Benchmark-Durchlauf markierte es 91% der echten Defekte dieses Durchlaufs als unsicher. Es markierte auch 11 der 14 korrigierten Übersetzungen und 42 der 150 sauberen, sodass es viel gute Arbeit zur erneuten Übersetzung zurückschickte.
Mit dem Verifizierer an Bord senkte das Abschalten des Beurteilungsmodells die Genauigkeit beim ersten Durchlauf von 99.2% auf 98.8% und ließ das Endergebnis unverändert. Das Beurteilungsmodell hatte etwa 45% der ersten Entwürfe zur erneuten Übersetzung zurückgeschickt. Wir lassen es nun standardmäßig ausgeschaltet.
Schwierige Zeichenketten für einen Menschen übrig lassen
Anfangs blieb eine Zeichenkette, die der Verifizierer bei jedem Retry ablehnte, unübersetzt, bis jemand sie von Hand korrigierte. Eine vollständige Neuübersetzung des Katalogs, 16,274 Zeichenketten in 7 Sprachen, ließ 97 solcher Zeichenketten übrig (0.09%). Jetzt ordnet die Pipeline die abgelehnten Entwürfe nach den Feststellungen des Verifizierers, übernimmt den am wenigsten falschen und markiert ihn im Pull Request zur Überprüfung. Die Schleife endet immer mit einer Übersetzung, selbst wenn diese noch einen markierten Fehler enthält, und die Markierung bringt sie vor die Person, die den Pull Request zusammenführt.
Was die Pipeline gegenüber dem nackten Modell hinzufügt
Das meiste, was die Pipeline hinzufügt, sind weniger offensichtliche Fehler. Um das zu messen, führt unser Eval dasselbe Modell zweimal über 454 Fälle, einmal durch die vollständige Pipeline und einmal mit einem Zwei-Zeilen-Prompt und ohne Stilhinweise, Glossar oder Retries. Das nackte Modell lieferte eine fehlerhafte Antwort, sodass 453 Paare zum Vergleich übrig bleiben.
| Messgröße | Nacktes Modell | Vollständige Pipeline |
|---|---|---|
| Glossar- oder Authoring-Prüfung nicht bestanden | 147 von 453 | 4 von 454 |
| Vom Verifizierer beim ersten Durchlauf akzeptiert | 263 der 306, die die Prüfungen bestanden (85.9%) | 448 von allen 454 (98.7%) |
| Kritische Fehler, summiert über drei Beurteiler aus anderen Modellfamilien | 203 | 109 |
| Paare, die jede Seite bei der Gesamtpräferenz gewonnen hat | 117 | 139 |
| Bedeutung hat Rückübersetzung überstanden | 90.8% | 89.3% |
Eine Authoring-Prüfung ist eine handgeschriebene Regel für einen einzelnen Eval-Fall. Beispielsweise darf „Queue“ auf Chinesisch nicht als 队列 übersetzt werden, die Substantivform, die ausgeliefert wurde. Die Prüfungsfehler fielen von 147 auf 4, was die Arbeit des Glossars und der Retries zeigt.
Die Zahlen zum ersten Durchlauf des Verifizierers verwenden unterschiedliche Grundlagen. Beim nackten Modell sind es die 306 Zeichenketten, die die Code-Prüfungen bestanden, und bei der Pipeline alle 454. Der Verifizierer stammt aus derselben Modellfamilie wie der Übersetzer, daher sagt seine Bestehensquote aus, wie oft das Modell mit sich selbst übereinstimmt. Wir verwenden GPT-6.1 Sol für beide Aufgaben, weil es der genaueste der beiden getesteten Übersetzer war. Für eine externe Sicht sendet das Eval jedes Übersetzungspaar, unmarkiert, an drei Beurteiler aus anderen Modellfamilien: Claude Opus 5.5, Gemini 4 Argon und DeepSeek V4 Pro. Über die drei Beurteiler hinweg fanden sie 109 kritische Fehler in der Ausgabe der Pipeline und 203 in der des nackten Modells. Die Fehler jedes Beurteilers werden separat gezählt, sodass eine Zeichenkette, die alle drei Beurteiler markieren, drei zur Gesamtsumme beiträgt.
Bei der Gesamtpräferenz über die 453 Paare wählten die Beurteiler die Pipeline in 139 Fällen und das nackte Modell in 117, mit 61 Unentschieden und 136 Paaren, bei denen die beiden Übersetzungen identisch waren. Dieser Abstand ist viel geringer, als die Prüfungsfehler und kritischen Fehler zeigen, daher liegt der Wert der Pipeline hauptsächlich in den spezifischen Fehlern, die sie beseitigt.
Die letzte Zeile übersetzt jede Antwort zurück ins Englische und fragt, ob die Bedeutung erhalten blieb. Sie bewertete das nackte Modell mit 90.8% und die Pipeline mit 89.3%. Rückübersetzung kann keine Terminologie oder Registerebene erkennen, was der Großteil dessen ist, was die Pipeline ändert, daher lesen wir dieses Ergebnis als Unentschieden.
Die Feedback-Schleife
Der Verifizierer findet die meisten Fehler, bevor sie ausgeliefert werden, und Leser finden einen Teil des Rests.
Aktivieren Sie Select-to-Report im Sprachdialog, markieren Sie dann beliebigen übersetzten Text, fügen Sie eine Notiz hinzu und senden Sie sie ab. Jeder Bericht kommt mit der Sprache, der Seite und dem exakten Text an. Ein Modell sichtet ihn zuerst, wählt eine von vier Korrekturen aus und stellt die Korrektur innerhalb von Minuten bereit. Unser AI-Reviewer prüft die Korrektur, und ein Mensch führt das endgültige Merging durch.
- Falsche Bedeutung. Die Zeichenkette kehrt noch am selben Tag zum Englischen zurück und erhält dann eine korrigierte Übersetzung.
- Falscher Begriff. Wir fügen den Begriff mit der akzeptierten Form und den für diese Sprache abzulehnenden Formen zum Glossar hinzu. Namen von Compliance-Standards und Protokollen wie HIPAA, SOC 2, OAuth und SAML pinnen wir fest, damit die Pipeline sie auf Englisch belässt.
- Falscher Ton oder falsche Zeichensetzung. Die Regel kommt in die Stilhinweise für diese Sprache.
- Ein einziger fehlerhafter String. Eine exakte Überschreibung fixiert die genehmigte Formulierung, und kein späterer Durchlauf kann sie ändern.
Fehler, die die tägliche Überprüfung nach bestandener Verifizierung noch aufdeckt, wandern in die Fehlersuite. Sie umfasst bisher 22 Fälle. Dazu gehören „Queue“, das als Substantiv auf einer Schaltfläche übersetzt wurde, die ein Verb gebraucht hätte, „shadow traffic“, das als Straßenverkehr wiedergegeben wurde, und eine HIPAA-Einstellung, deren Bedeutung invertiert wurde. Jeder Fall verbietet den Fehler, der ausgeliefert wurde, sodass jedes künftige Modell, jeder Prompt oder jede Glossaränderung, die ihn wieder einbringt, die Evaluierung nicht besteht.
Was es kostet
Als wir es erstmals kalkulierten, kam eine vollständige Neuübersetzung aller 16,274 Strings in 7 Sprachen, insgesamt 113,918 Übersetzungen, auf etwa $430 – inklusive Übersetzung und Verifizierung. Auf diese Zahl kamen wir, indem wir produktionsgroße Chargen in jeder Sprache berechneten und hochskalierten. Das ergibt weniger als einen halben Cent pro String und Sprache. Die Verifizierung macht etwas mehr als die Hälfte aus, etwa $228, also $0.002 pro String und Sprache. Der Katalog ist inzwischen auf 16,918 Strings gewachsen, und eine vollständige Neuübersetzung davon kostet heute etwa $460. Die tägliche Schleife sendet nur, was sich geändert hat, und ein Tag mit 677 geänderten Strings über 7 Sprachen kostet grob $18.
Beide Zahlen decken nur die Übersetzungs- und Verifizierungsaufrufe ab. Sie lassen die Ingenieurszeit für den Aufbau der Pipeline, die Aufrufe des KI-Reviewers und des Triage-Modells sowie die Person, die jeden täglichen Pull Request zusammenführt, außer Acht.
Die heutigen 16,918 Strings enthalten 136,429 englische Wörter, sodass 7 Sprachen insgesamt 955,003 Wörter ergeben, was unsere Kosten auf etwa $0.0005 pro Wort bringt. Hier ist dieselbe vollständige Neuübersetzung zu den von Smartling und Gengo veröffentlichten Wortpreisen zum Start, Stand 10. November 2026.
| Option | Tarif | Gesamte Website, 7 Sprachen |
|---|---|---|
| Unsere Pipeline, Übersetzung und Verifizierung | etwa $0.0005 pro Wort | etwa $460 |
| Smartling Machine Translation | $0.0075 pro Wort | etwa $7,200 |
| Smartling AI Translation | $0.06 pro Wort | etwa $57,300 |
| Gengo Standard | $0.09 pro Wort | etwa $86,000 |
| Smartling AI Human Translation | $0.12 pro Wort | etwa $114,600 |
| Gengo Advanced | $0.18 pro Wort | etwa $171,900 |
| Smartling Human Translation | $0.20 pro Wort | etwa $191,000 |
Dies sind Listenpreise; Enterprise-Verträge werden verhandelt, und jede Zeile über maschineller Übersetzung beinhaltet menschliche Prüfung oder Projektmanagement, die unsere Zahl nicht berücksichtigt. Die nächste Vergleichsoption auf Augenhöhe ist Smartlings maschinelle Übersetzung, und unsere Pipeline kostet etwa 6% davon.
Was Sie wiederverwenden können
Wenn Sie Ihr eigenes Produkt lokalisieren, lassen sich vier Teile dieses Designs direkt übertragen.
- Ordnen Sie jeder Übersetzung einen Fingerabdruck zu ihrer englischen Quelle zu, damit veraltete Einträge automatisch erneut in die Warteschlange gestellt werden.
- Lassen Sie Code beschädigte Platzhalter, Plural-Zweige, Tags und verbotene Begriffe ablehnen, bevor ein Modell den Sinn prüft.
- Verwenden Sie einen Verifizierer, der jeden Fehler mit seinem Schweregrad benennt, und leiten Sie diese Einwände an den Übersetzer zurück.
- Verwandeln Sie jeden von einer Person gefundenen Fehler in eine Glossarregel, einen Stilhinweis, eine Überschreibung oder einen Eval-Fall.
Senden Sie uns Ihr Feedback
Während der Beta-Phase wird einige Formulierungen noch nicht optimal sein, und der schnellste Weg zur Behebung ist die Meldung per „Auswählen und Melden“ im Sprachdialog. Wir prüfen jede Meldung und machen daraus eine Glossarregel, einen Stilhinweis oder eine Überschreibung.
Häufig gestellte Fragen
Welche Sprachen unterstützt OpenRouter?
OpenRouter ist auf Englisch, Chinesisch (vereinfacht), Spanisch, Brasilianisches Portugiesisch, Deutsch, Französisch, Japanisch und Koreanisch verfügbar. Die Lokalisierung befindet sich in der Beta.
Wie ändere ich die Sprache auf OpenRouter?
Wählen Sie eine Sprache aus dem Kontomenü, oder öffnen Sie eine lokalisierte Adresse wie openrouter.ai/ja.
Welche Modelle übersetzen OpenRouter?
GPT-6.1 Sol (openai/gpt-6.1-sol) übersetzt jede Zeichenkette, und ein zweiter Aufruf desselben Modells überprüft sie gegen das Englische. Beide laufen über die OpenRouter-API.
Wie viel kostet die Übersetzung der gesamten Website?
Eine vollständige Neuübersetzung der heutigen 16,918 Zeichenketten in 7 Sprachen kostet etwa $460, Übersetzung und Verifizierung inklusive, was weniger als einen halben Cent pro Zeichenkette und Sprache ausmacht. Derselbe Auftrag würde bei Smartlings veröffentlichtem Maschinenübersetzungstarif etwa $7,200 und bei veröffentlichten Preisen für KI- und Humanübersetzung etwa $57,300 bis $191,000 kosten.
Wie melde ich eine schlechte Übersetzung?
Aktivieren Sie „Auswählen und Melden“ im Sprachdialog, markieren Sie den Text, der falsch klingt, fügen Sie eine Notiz hinzu und senden Sie sie ab.