E EmDash CMS Everything Guides, use cases, plugins, templates
Deutsch

EmDash übersetzen

Auf dieser Seite

Die Admin-Oberfläche von EmDash ist übersetzbar. Für die Extraktion der Nachrichten wird Lingui verwendet, für die Nachverfolgung des Übersetzungsfortschritts Lunaria. Alle Übersetzungen liegen in PO-Dateien (gettext), eine pro Locale.

Übersetzungsstatus

Den aktuellen Fortschritt aller Locales finden Sie im Übersetzungs-Dashboard.

Wer kann übersetzen

Jede Übersetzung muss von einer Muttersprachlerin, einem Muttersprachler oder einer fließend sprechenden Person betreut werden. KI-generierte Übersetzungen werden akzeptiert, aber nur, wenn eine fließend sprechende Person jeden String prüft und ihn vor dem Einreichen im laufenden Admin-Bereich in der Vorschau ansieht. Unbeaufsichtigte maschinelle Ausgaben werden nicht akzeptiert. Siehe KI-gestützte Übersetzungen und Übersetzungen testen weiter unten.

Einen String unübersetzt zu lassen ist besser, als ihn falsch zu übersetzen. Eine falsche Übersetzung führt Benutzer in die Irre; der englische Fallback ist für sie nur unbequem.

Dateistruktur

Die Übersetzungskataloge liegen in packages/admin/src/locales/:

packages/admin/src/locales/
├── en/
│   └── messages.po    # English (source)
├── de/
│   └── messages.po    # German
└── ...

Jede .po-Datei enthält msgid/msgstr-Paare. Die msgid ist der englische Quelltext, die msgstr ist Ihre Übersetzung. Eine leere msgstr bedeutet „noch nicht übersetzt“ – Lingui greift zur Laufzeit auf Englisch zurück.

Strings übersetzen

  1. Sehen Sie im Übersetzungs-Dashboard nach, wo Arbeit nötig ist. Prüfen Sie offene PRs, um doppelte Arbeit zu vermeiden.

  2. Forken Sie das Repository und erstellen Sie einen Branch:

    git checkout -b i18n/de

  3. Öffnen Sie die PO-Datei Ihrer Locale (z. B. packages/admin/src/locales/de/messages.po).

  4. Tragen Sie die Übersetzungen ein. Jeder Eintrag sieht so aus:

    #: packages/admin/src/components/LoginPage.tsx:304
msgid "Sign in with Passkey"
msgstr ""

    Füllen Sie die msgstr aus:

    #: packages/admin/src/components/LoginPage.tsx:304
msgid "Sign in with Passkey"
msgstr "Mit Passkey anmelden"

  5. Testen Sie Ihre Übersetzungen (siehe unten).

  6. Öffnen Sie einen PR gegen main. Titelformat: i18n(de): add/update German translations.

    Beschränken Sie den PR auf die PO-Datei, ein Changeset und die Locale-Dateien, die unter Eine neue Sprache hinzufügen beschrieben sind. Eine Automatisierung kommentiert einen Übersetzungs-PR, der etwas anderes ändert.

Was übersetzt werden soll

  • Den msgstr-Wert jedes Eintrags.

Was NICHT übersetzt werden soll

  • msgid-Werte – das sind Lookup-Schlüssel.
  • Interpolations-Platzhalter wie {error}, {email}, {label} – behalten Sie sie exakt bei.
  • XML-artige Tags wie <0>, </0> – sie umschließen interaktive Elemente (Links, Buttons). Behalten Sie die Tags bei und übersetzen Sie den Text dazwischen.
  • Kommentare, die mit #: beginnen – das sind von Lingui hinzugefügte Quellverweise.

Interpolation und Tags

Einige Strings enthalten Platzhalter und Tags:

msgid "Authentication error: {error}"
msgstr "Authentifizierungsfehler: {error}"

msgid "Don't have an account? <0>Sign up</0>"
msgstr "Noch kein Konto? <0>Registrieren</0>"

msgid "If an account exists for <0>{email}</0>, we've sent a sign-in link."
msgstr "Falls ein Konto für <0>{email}</0> existiert, haben wir einen Anmeldelink gesendet."

Platzhalter ({error}, {email}) werden zur Laufzeit durch dynamische Werte ersetzt. Tags (<0>...</0>) umschließen React-Komponenten. Beide müssen in Ihrer Übersetzung genau so vorkommen wie im Quelltext – mit denselben Namen und derselben Verschachtelung.

Übersetzungen testen

  1. Kompilieren Sie die Demo und starten Sie sie:

    pnpm run locale:compile
pnpm build
pnpm --filter emdash-demo dev

  2. Wechseln Sie die Locale auf der Admin-Einstellungsseite und prüfen Sie, ob Ihre Übersetzungen im Kontext richtig aussehen.

Pseudo-Sprache

EmDash liefert eine Pseudo-Locale mit, die alle eingebundenen Strings in akzentuierte Doppelgänger verwandelt – "Dashboard" wird zu "Ðàšĥƀöàřð" und so weiter. Jeder String, der bei aktiver Pseudo-Locale in normalem Englisch erscheint, hat entweder keinen t\…“-Wrapper oder stammt von außerhalb des Katalogs.

Zum Aktivieren fügen Sie Folgendes in die .env-Datei im Demo-Verzeichnis ein:

EMDASH_PSEUDO_LOCALE=1

Starten Sie anschließend den Dev-Server neu. Die Pseudo-Locale erscheint als Pseudo in der Sprachauswahl auf der Anmeldeseite und in den Einstellungen. Wechseln Sie zu ihr, um nicht eingebundene Strings auf einen Blick zu erkennen.

Eine neue Sprache hinzufügen

Wenn für Ihre Sprache noch keine PO-Datei existiert:

  1. Fügen Sie die Locale zu packages/admin/src/locales/locales.ts hinzu:

    export const LOCALES: LocaleDefinition[] = [
  { code: "en", label: "English", enabled: true },
  // ...
  {
    code: "vi",
    label: "Tiếng Việt",
    enabled: false,
    dateLocale: () => import("react-day-picker/locale/vi").then((m) => m.vi),
  },
];

    dateLocale lädt die Kalender- und Datumsformat-Lokalisierung für Ihre Sprache. Wählen Sie die passendste Datei in react-day-picker/locale, etwa pt für pt-PT, und verwenden Sie den in dieser Datei benannten Export. Lassen Sie sie nur weg, wenn Ihre Sprache den US-englischen Kalender verwendet.

    Das ist die einzige maßgebliche Quelle – lingui.config.ts, lunaria.config.ts und die Admin-Laufzeit leiten ihre Locale-Listen alle aus dieser Datei ab. Setzen Sie enabled: false, solange die Übersetzung noch in Arbeit ist. Ein Maintainer aktiviert die Locale, sobald sie ausreichend abgedeckt ist, um in der Admin-Oberfläche verwendet zu werden.

  2. Führen Sie die Extraktion aus, um die leere PO-Datei zu erzeugen:

    pnpm run locale:extract

    Dadurch wird packages/admin/src/locales/{your-locale}/messages.po mit allen übersetzungsbereiten Strings erstellt.

  3. Übersetzen und testen Sie anhand der obigen Schritte.

Übersetzungsstandards

Genauigkeit

Übersetzungen sollten den englischen Quelltext auf muttersprachlichem Niveau getreu wiedergeben. Fügen Sie keine Bedeutung hinzu, entfernen oder deuten Sie sie nicht um. Wenn ein Quell-String mehrdeutig ist, prüfen Sie den #:-Kommentar mit dem Speicherort der Quelldatei – lesen Sie den Komponentencode, um den Kontext zu verstehen.

Konsistenz

Verwenden Sie innerhalb Ihrer Locale einheitliche Terminologie. Wenn Sie „collection“ an einer Stelle als „Sammlung“ übersetzen, wechseln Sie andernorts nicht zu „Kollektion“. Wenn es für Ihre Sprache bereits Übersetzungen gibt, lesen Sie die bestehende PO-Datei durch, bevor Sie beginnen, damit Sie die etablierte Terminologie übernehmen.

Ton

Die Admin-Oberfläche verwendet einen direkten, professionellen Ton. Treffen Sie ihn in Ihrer Sprache – vermeiden Sie allzu förmliche oder allzu lockere Formulierungen.

KI-gestützte Übersetzungen

Sie dürfen Übersetzungen mit KI-Tools erzeugen, auch einen vollständigen ersten Durchgang, aber eine fließend sprechende Person muss das Ergebnis betreuen:

  • Eine fließend sprechende Person muss jeden String prüfen. KI-Tools machen subtile Fehler, die nur eine fließend sprechende Person bemerkt – falsches Register, unnatürliche Formulierungen, falsche Fachbegriffe.
  • Eine fließend sprechende Person muss die Übersetzungen in der laufenden Admin-Oberfläche in der Vorschau ansehen. KI-Tools kennen weder Layout-Einschränkungen noch den UI-Kontext.
  • Geben Sie die Verwendung von KI in der PR-Beschreibung an.
  • PRs mit unbeaufsichtigten maschinellen Übersetzungen werden geschlossen.

Teilweise Übersetzungen

Teilweise Übersetzungen sind willkommen. Sie müssen nicht jeden String in einem PR übersetzen – jeder Fortschritt hilft. Unübersetzte Strings greifen zur Laufzeit auf Englisch zurück.