Zum Inhalt springen
Nodary

Lokalisierungs­tabellen-Vorlage

Eine String-Tabelle, mit der Übersetzer arbeiten können: eine Zeile pro Key, mit Kontext, Längenlimit, englischer Quelle und vier Übersetzungen, dazu ein Glossar und ein Styleguide pro Sprache. Laden Sie sie als .zip herunter: Die Tabelle ist eine CSV-Datei (UTF-8, durch Kommas getrennt), der Rest ist Markdown, und alles lässt sich in Nodary importieren, wo die CSV zur Tabelle wird, die Sie als Übersetzungstabelle nutzen.

4 Dateien in einem .zip (Markdown und CSV), 5 kB

Kostenlos, ohne Konto und ohne E-Mail-Adresse. Nutzen, ändern und teilen Sie sie, wie Sie möchten.

Lesen Sie jede Datei vor dem Download

Die Übersicht erklärt die Spalten, die Benennung der Keys, Platzhalter und Übersetzungsstatus. Die Tabelle enthält 13 Beispiel-Strings aus Saltmarrow, dem Beispielspiel, das diese Website überall zeigt; zwei Zellen sind absichtlich falsch, um zu zeigen, was die Prüfungen finden.

Dokumente

Datei Lokalisierungstabellen-Vorlage/Lokalisierungstabelle.md

Lokalisierungstabelle

So nutzen Sie diese Vorlage: Kursive Zeilen sind Hinweise. Ersetzen Sie sie durch Ihre eigenen Worte und löschen Sie sie dann. Werte in eckigen Klammern füllen Sie aus. Die Tabelle selbst ist die CSV-Datei neben dieser Seite.

Die Dateien

  • Texte: die Tabelle selbst, eine Zeile pro String, eine Spalte pro Sprache
  • Glossar: die Wörter, die überall gleich übersetzt werden, und die Namen, die nie übersetzt werden
  • Styleguide: wie das Spiel in jeder Sprache spricht

Spalten

SpalteWas sie enthält
keyEin eindeutiger Name für den String, nie für Spieler sichtbar
contextWo der Text erscheint und wer ihn sagt: was ein Übersetzer nicht erraten kann
max_lengthDie meisten Zeichen, die der Text auf dem Bildschirm einnehmen darf
enDer Quelltext
fr, de, es, plEine Spalte pro Sprache, benannt nach ihrem Code

Keys benennen

Benennen Sie Keys danach, wo der Text lebt, vom Allgemeinen zum Besonderen, damit zusammengehörige Strings beieinanderstehen.

  • Muster: [Bildschirm].[Element].[Detail], etwa menu.play oder hud.tide.warning
  • Kleingeschrieben, mit Punkten zwischen den Teilen, ohne Leerzeichen
  • Verwenden Sie einen Key nie für einen anderen Text: Legen Sie einen neuen an

Platzhalter und Markup

Werte, die das Spiel einsetzt, stehen in geschweiften Klammern, etwa {count}; jede Übersetzung behält jeden Platzhalter ihrer Quelle. Markup-Tags, etwa das Fett-Tag in item.crystal.desc, bleiben um die Wörter, die sie markieren.

Übersetzungsstatus

  • FehltEntwurf
  • EntwurfGeprüft
  • GeprüftFinal
  • FinalVeraltet
  • VeraltetEntwurf
Der Status einer Übersetzung: Eine geänderte Quelle macht sie veraltet, sie wird erneut geprüftEin Mermaid-Diagramm in der Datei: Nodary, GitHub und Obsidian zeichnen es.
Mermaid
flowchart LR
  n0["Fehlt"]
  n1["Entwurf"]
  n2["Geprüft"]
  n3["Final"]
  n4["Veraltet"]
  n0 --> n1
  n1 --> n2
  n2 --> n3
  n3 --> n4
  n4 --> n1

Beispiel (Saltmarrow, ein Beispielspiel): Zwei Zellen des Beispiels sind absichtlich falsch. menu.settings auf Deutsch, Einstellungen, hat 13 Zeichen, der Button fasst 10, also meldet die Längenprüfung es; der Gruß der Archivarin hat noch kein Polnisch und zählt als fehlend.

Diese Vorlage dürfen Sie frei nutzen, ändern und teilen. Sie stammt von Nodary, wo sich diese Dateien als Karte verlinkter Dokumente importieren lassen und die CSV als Tabelle.

Vorlage herunterladen4 Dateien in einem .zip (Markdown und CSV), 5 kB

So nutzen Sie sie

  1. Die Beispiel-Strings ersetzen

    Behalten Sie Spalten und Key-Benennung und setzen Sie Ihre eigenen Strings ein. Geben Sie jedem String Kontext und Längenlimit, bevor er in die Übersetzung geht.

  2. Das Glossar früh schreiben

    Fügen Sie jeden Begriff hinzu, sobald eine Übersetzerin zum ersten Mal danach fragt, mit seiner Übersetzung in jeder Sprache. Ein Wort, das zweimal anders übersetzt ist, verwirrt Spieler und verdoppelt die Support-Fragen.

  3. Den Stil pro Sprache festlegen

    Legen Sie vor der Übersetzung fest, wie jede Sprache den Spieler anspricht und welche typografischen Regeln gelten. Später ändern heißt, jeden String neu zu lesen.

  4. Die Quelle einfrieren, bevor sie rausgeht

    Schicken Sie Strings erst in die Übersetzung, wenn ihr Englisch endgültig ist. Ändert sich eine Quelle danach, müssen ihre Übersetzungen erneut geprüft werden.

In Nodary importieren und als Übersetzungstabelle nutzen

Nodary ist ein KI-nativer Workspace, in dem die Dokumente eines Teams verlinkt sind, statt sich zu stapeln. Importieren Sie die .zip, und die CSV kommt als Tabelle unter der Übersicht an, Glossar und Styleguide daneben. In der Tabelle liest „Übersetzungstabelle“ die Rollen aus den Spaltenköpfen (key, context, max_length und eine Spalte pro Sprache), prüft dann jede Übersetzung auf Länge und Platzhalter, gibt jeder einen Status, markiert eine Übersetzung als veraltet, wenn sich ihre Quelle ändert, und exportiert Dateien für Unity, Unreal und Godot: CSV, JSON, gettext .po und XLIFF.

  1. Öffnen Sie die Karte eines Projekts und wählen Sie „Importieren“.
  2. Wählen Sie den Tab „Ordner oder ZIP“, dann „ZIP wählen“, wählen Sie die Datei und importieren Sie.
  3. Öffnen Sie „Texte“, wählen Sie „Übersetzungstabelle“, prüfen Sie die aus den Spaltenköpfen gelesenen Rollen und dann „Als Übersetzungstabelle nutzen“.

Der Free-Plan bietet zehn Dokumente pro Workspace, die eigene Seite des Projekts eingerechnet: Die vier der Vorlage passen mit viel Platz. Die Quellspalte ist Englisch: Ist Ihr Spiel in einer anderen Sprache geschrieben, machen Sie diese Spalte zur Quelle, wenn Nodary die Rollen zeigt.

Wie Nodary mit Spielelokalisierung umgeht
Die Übersetzungstabelle von Saltmarrow in Nodary: Keys, Kontext und Maximallängen mit Spalten für Englisch, Französisch, Deutsch, Japanisch und brasilianisches Portugiesisch, der Fortschritt jeder Sprache und Warnungen zu einem zu langen deutschen String und einem, der seinen Platzhalter {seconds} verloren hat.

Eine String-Tabelle führen, mit der Übersetzer arbeiten können

Eine String-Tabelle scheitert, wenn Übersetzer raten müssen, was eine Zeile bedeutet oder wie viel Platz sie hat, oder wenn sich Text nach der Übersetzung ändert und niemand es merkt. Diese Gewohnheiten verhindern alle drei Fälle.

Jedem String Kontext geben

Wer es sagt, wo es erscheint, worauf es antwortet. „Open“ ist an einer Tür ein Verb und an einem Laden ein Adjektiv: Nur der Kontext verrät es.

Die Länge vom Bildschirm ableiten

Messen Sie, wie viele Zeichen der Button, die Zeile oder die Sprechblase fasst, und schreiben Sie dieses Limit auf, nicht die Länge des Englischen.

Nie Sätze aus Stücken bauen

„Du hast gefunden“ und „3 Kristalle“ im Code zusammenzukleben, zerstört Wortstellung und Grammatik in den meisten Sprachen. Geben Sie jedem Satz einen eigenen Key mit Platzhaltern.

Platzhalter unversehrt lassen

Jede Übersetzung behält jeden {Platzhalter} und jedes Tag ihrer Quelle. Ein verlorenes {count} zeigt Spielern eine Lücke oder bringt das Spiel zum Absturz.

Ein Key, eine Bedeutung

Verwenden Sie einen Key nie für einen anderen Text. Legen Sie einen neuen an und entfernen Sie den alten, sobald ihn nichts mehr nutzt.

Die Quelle einfrieren, bevor sie rausgeht

Übersetzen Sie Text, der fertig ist. Ändert sich eine Quelle trotzdem, markieren Sie ihre Übersetzungen als veraltet, damit sie erneut geprüft werden.

Fragen zur Lokalisierungstabelle

Was ist eine Lokalisierungstabelle?

Eine Lokalisierungstabelle (String-Tabelle) enthält jeden Text, den ein Spiel zeigt, eine Zeile pro String: ein Key, den der Code nutzt, der Quelltext, Notizen für Übersetzer, ein Längenlimit und eine Spalte pro Sprache. Das Spiel lädt den Text per Key in der Sprache des Spielers, sodass sich Text ändern und übersetzen lässt, ohne den Code anzufassen.

Welche Spalten braucht eine String-Tabelle?

Mindestens einen Key und den Quelltext, dann eine Spalte pro Sprache. Eine Kontextspalte und eine Spalte für die Maximallänge ersparen die meisten Rückfragen der Übersetzer. Diese Vorlage hat alle fünf Arten, mit Englisch als Quelle und Französisch, Deutsch, Spanisch und Polnisch.

Wie benenne ich String-Keys?

Danach, wo der Text lebt, vom Allgemeinen zum Besonderen, etwa menu.play oder hud.tide.warning: kleingeschrieben, mit Punkten zwischen den Teilen. Zusammengehörige Strings stehen dann beieinander, und ein Key verrät, wo man im Spiel suchen muss.

Wie gehe ich mit Pluralformen um?

Sprachen zählen unterschiedlich: Polnisch hat drei Pluralformen, wo Englisch zwei hat. Setzen Sie die Zahl hinter eine Beschriftung, etwa „Salz: {count}“, oder nutzen Sie das Pluralsystem Ihrer Engine mit einem Text pro Form.

Wie öffne ich die CSV in Excel?

Google Sheets, LibreOffice Calc, Numbers und Nodary öffnen sie direkt. Excel öffnet sie per Doppelklick nur, wenn das Listentrennzeichen des Computers ein Komma ist; mit deutschen Einstellungen ist es ein Semikolon, und jede Zeile landet dann in einer einzigen Spalte. Importieren Sie die Datei stattdessen: auf der Registerkarte Daten über den Import aus Text/CSV, Datei auswählen, als Dateiursprung UTF-8 und als Trennzeichen Komma einstellen, dann laden.

Lesen Unity, Unreal oder Godot diese CSV?

Die CSV der Vorlage ist für Tabellenkalkulationen und den Import in Nodary gemacht. Jede Engine liest ihr eigenes Format: Aus derselben Tabelle exportiert die Übersetzungstabelle von Nodary CSV für Godot und Unity, gettext .po für Unreal und Godot, JSON für die meisten Engines und XLIFF für Übersetzungswerkzeuge.

Kann ich Sprachen hinzufügen?

Ja. Fügen Sie eine Spalte hinzu, die nach dem Sprachcode benannt ist, etwa ja oder pt-BR. Nodary erkennt Codes und Sprachnamen in den Spaltenköpfen, und seine Übersetzungstabelle kann auch selbst eine Spalte für eine Sprache anlegen.

Halten Sie die Texte des Spiels dort, wo das Team arbeitet.

Importieren Sie die Vorlage in Nodary, und die String-Tabelle liegt auf derselben Karte wie Design und Dialoge, mit dem Status jeder Übersetzung im Blick. Kostenlos mit zwei Mitgliedern, einem Projekt und zehn Dokumenten, ohne Kreditkarte.