Häufig gestellte Fragen

Nein. Es funktioniert mit React und Next.js, React Native und Expo, Flutter, Angular, Vue und Nuxt, Svelte und SvelteKit, Astro, Solid, Qwik, Lit, Ember, Electron und Tauri, einfachen HTML-Seiten, Rails-, Django- und Laravel-Vorlagen, Android-Layouts, Jetpack Compose und View-Code sowie iOS- und macOS-Apps in SwiftUI und UIKit. Es richtet die passende i18n-Bibliothek für jede ein: react-i18next, ngx-translate, vue-i18n oder @nuxtjs/i18n, svelte-i18n, ember-intl, Flutter’s gen-l10n, Rails I18n, Django’s gettext, Android-Ressourcen oder ein kleines Skript für statische Seiten.

Ja. localize-dev translate füllt die fehlenden Übersetzungen in den bereits vorhandenen Locale-Dateien auf, in jedem Stack: JSON (i18next, react-intl, vue-i18n, ngx-translate), Rails YAML, gettext .po, Flutter .arb, Android strings.xml, Apple String Catalogs und .strings sowie Browser-Erweiterungsnachrichten. Der Code wird nicht angefasst, bestehende Übersetzungen werden nicht geändert, und in CI wird ein Pull-Request geöffnet, sobald neue Schlüssel landen.

Nur Node.js 22 oder neuer, um die CLI auszuführen: npx localize-dev führt sie aus, ohne eine package.json zu Ihrem Projekt hinzuzufügen. Oder überspringen Sie lokale Ausführungen und verwenden Sie die GitHub Action, die auf den Maschinen von GitHub läuft.

Ja. localize-dev sync push lädt Ihre Quell-Locale-Dateien hoch und sync pull bringt die Arbeit der Übersetzer zurück, sodass maschinelle Übersetzungen, menschliche Überprüfung und Ihr Repository auf dem neuesten Stand bleiben.

Ihre App funktioniert weiter. Die Ausgabe ist die i18n-Bibliothek, die Ihr Framework bereits verwendet (react-i18next, vue-i18n, ngx-translate, Rails I18n, gettext, Android-Zeichenfolgenressourcen, Apple String Catalogs…) mit einfachen Locale-Dateien in Ihrem Repository. Es gibt keine localize.dev-Laufzeit, kein SDK und keinen Proxy, der entfernt werden müsste.

Ja. Verbinden Sie das Repository im Dashboard und wählen Sie „Vorschau-Pull-Request öffnen“: localize.dev lokalisiert den Standardzweig (bis zu 200 Zeichenfolgen, eine Sprache) und öffnet einen Pull Request von localize-dev/preview. Kein Workflow, Schlüssel oder Checkout erforderlich.

Ja. npx localize-dev check (oder die Action mit mode: check) schlägt fehl, wenn eine Änderung hartcodierten Text hinzufügt, eine Sprache Übersetzungen fehlen oder Englisch bearbeitet wurde und seine Übersetzungen nicht neu erstellt wurden, wobei jedes Problem im Pull Request kommentiert wird. Es läuft auf Ihrem Computer oder Runner, ohne API-Schlüssel.

Ja. Eine Auswahl wie n === 1 ? „Datei“ : „Dateien“ wird zu einer Pluralnachricht, und jede Sprache erhält die Formen, die sie benötigt: Polnisch vier, Arabisch sechs, Japanisch eins. Ein Satz mit zwei Zählungen („3 Dateien in 2 Ordnern“) erhält einen Plural pro Zählung, und Ordnungszahlen wie 1., 2. und 3. werden zu Ordnungszahl-Pluralen in den eigenen Formen jeder Sprache, in React, Next.js, Vue, Svelte, Astro, Ember, Angular und den anderen JavaScript-Frameworks. Flutter, Rails, Django, Laravel, Android und iOS erhalten Plurale in ihren eigenen Formaten (ARB, YAML, msgid_plural, trans_choice, <plurals>, String Catalog-Variationen); ihre Bibliotheken haben keine Ordnungszahlen.

Es wird erneut übersetzt. localize.lock.json speichert einen Fingerabdruck jeder Quellnachricht, sodass eine bearbeitete Nachricht bei der nächsten Ausführung oder dem nächsten Pull Request in jeder Sprache neu erstellt wird und localize-dev check fehlschlägt, solange eine Übersetzung veraltet ist. Schlüssel, die kein Code mehr verwendet, werden gemeldet, und localize-dev prune entfernt sie.

Ja. localize-dev content übersetzt Markdown- und MDX-Dateien in eine Kopie pro Sprache (intro.es.md oder die i18n-Ordner von Docusaurus), wobei Codeblöcke, Links, MDX-Importe und Komponenten exakt wie geschrieben beibehalten werden. Nur Dokumente, die seit ihrer letzten Übersetzung bearbeitet wurden, werden erneut gesendet.

Ja. Führen Sie es vom Stammverzeichnis mit --workspaces aus oder setzen Sie workspaces: true in der GitHub Action, und jede App wird mit ihren eigenen Locale-Dateien in einem Pull Request lokalisiert. Gemeinsam genutzte Bibliotheken ohne Dev- oder Start-Skript bleiben unberührt. Um nur eine App zu lokalisieren, setzen Sie stattdessen working_directory: apps/web in der Action.

In Next.js, SvelteKit und Nuxt werden Seiten auf dem Server in der Sprache des Besuchers gerendert. Für statische HTML-Websites aktivieren Sie htmlPages und localize.dev schreibt eine übersetzte Kopie jeder Seite pro Sprache, verknüpft mit hreflang, damit jede Sprache indiziert werden kann.

Nur die zu übersetzenden Zeichenfolgen werden mit ihrem Dateipfad und ihrem Speicherort (die Komponente und das Element wie ein Button oder eine Überschrift) als Kontext an die localize.dev API gesendet. Ganze Dateien werden nie gesendet. Das Umschreiben erfolgt lokal (oder auf Ihrem eigenen CI-Runner), und Scans und Offline-Läufe berühren nie das Netzwerk.

Nein. Die Übersetzung läuft auf dem gehosteten localize.dev-Modell für jeden Plan, einschließlich des kostenlosen Plans. Erstellen Sie einen API-Schlüssel, führen Sie localize-dev login aus, und Sie sind fertig.

Nein. Wenn Ihre App noch keine hat, fügt der Pull-Request die richtige hinzu (Lockfile enthalten), erstellt ein Modul, das jede Locale-Datei lädt und die Sprache auswählt, und integriert sie in Ihre Einstiegsdatei. Rechts-nach-links-Sprachen stellen auch die Seitenrichtung ein. Apps, die bereits i18next, vue-i18n oder svelte-i18n verwenden, behalten ihre eigene Einrichtung bei.

Bestehende t(), und $_()-Aufrufe bleiben unverändert, und Schlüssel, die bereits in en.json vorhanden sind, werden wiederverwendet, wenn der Text übereinstimmt (bei kurzen Texten wie "Post", wenn auch die Übersetzungen übereinstimmen). Es ist sicher, auf halb lokalisertem Code auszuführen.

Es übersetzt mit Kontext. Jeder String erreicht das Modell mit seiner Datei, Komponente und seinem Element, sodass "Post" auf einem Button auf Deutsch zu "Veröffentlichen" wird und "Post" als Titel einer Karte zu "Beitrag" wird, jeweils mit eigenem Schlüssel; identische Texte teilen sich einen Schlüssel nur, wenn ihre Übersetzungen übereinstimmen. Ihr Glossar und Ihre Stilhinweise halten Produktbegriffe und den Ton konsistent, einschließlich eines formellen oder informellen "Sie" pro Sprache, und Pluralformen erhalten jede Form, die jede Sprache benötigt. Laravel- und Django-Kataloge werden nach dem englischen Text selbst benannt, sodass dort ein Text eine Übersetzung hat.

Die obige Workflow-Datei und ein Repository-Geheimnis, LOCALIZEDEV_API_KEY. Sie verwendet das integrierte GITHUB_TOKEN mit Schreibzugriff auf Inhalte und Pull Requests, hält einen Pull Request pro Branch auf dem neuesten Stand, anstatt bei jedem Push eine neue zu öffnen, und überspringt eigene Branches und Pull Requests von Forks, deren Token schreibgeschützt ist.

Sie sind ein starker erster Entwurf mit korrekten Platzhaltern und konsistenten Schlüsseln. Für regulierte oder markenkritische Texte weisen Sie pro Sprache einen Prüfer zu: Sie erhalten eine E-Mail, wenn ein Lauf abgeschlossen ist, genehmigen oder korrigieren jede Übersetzung auf der Registerkarte "Überprüfen", und Korrekturen fließen in den offenen Pull Request und jeden späteren Lauf ein. Immer wiederkehrende Korrekturen werden mit einem Klick zu Glossarbegriffen. Das Modell markiert auch Übersetzungen, bei denen es sich nicht sicher ist, mit seiner Begründung, sodass Prüfer mit diesen beginnen.

Einzigartiger UI-Text zur Übersetzung. Ein String zählt einmal, egal in wie viele Sprachen er übersetzt wird. Die Übersetzung von „Bestellung aufgeben“ in 10 Sprachen zählt als 1, nicht als 10. Text, der bereits einen Schlüssel hat, wird nie wieder gesendet.

Der Lauf stoppt, bevor etwas geschrieben wird, und erklärt Ihnen den Grund, sodass Ihr Code nie halb umgeschrieben wird. Führen Sie ein Upgrade durch oder warten Sie, bis das Kontingent am Ende Ihres 30-tägigen Zeitraums zurückgesetzt wird, und führen Sie ihn erneut aus. Das Dashboard zeigt das Datum an.

Nein. Scans und --offline-Läufe funktionieren vollständig auf Ihrem Rechner und rufen niemals die API auf. Sie benötigen dafür überhaupt keinen Schlüssel.

Nein. Die Action funktioniert mit jedem Plan, einschließlich Kostenlos. Fügen Sie Ihren API-Schlüssel als Repository-Geheimnis hinzu, und sie öffnet bei jedem Push einen Pull Request, innerhalb der 3/5/unbegrenzt Sprachen Ihres Plans.

Ja. Der Playground führt dieselbe Engine für eine Komponente oder Seite aus, die Sie einfügen (React, Vue, Svelte, Angular, Astro, Flutter, Rails, Django, Laravel, Android, iOS oder HTML), kein Konto erforderlich.

Löschen Sie Ihren persönlichen Arbeitsbereich im Dashboard → Einstellungen. Dadurch wird Ihr Konto gelöscht: Ihr Login, verknüpfte GitHub- und Google-Anmeldungen sowie Teammitgliedschaften, und Sie werden auf jedem Gerät abgemeldet. Wenn Sie Team-Arbeitsbereiche besitzen, löschen Sie diese zuerst. Strings, die in diesem Zeitraum verwendet wurden, zählen weiterhin, wenn Sie sich mit derselben E-Mail erneut anmelden.

Ja. Senden Sie eine E-Mail an support@uselocalize.dev von der Adresse auf Ihrem Konto, und wir senden es Ihnen. Die Datenschutzrichtlinie listet auf, was wir speichern.

Senden Sie eine E-Mail an support@uselocalize.dev mit den ausgeführten Schritten und den beobachteten Ergebnissen. Für Sicherheitsprobleme senden Sie bitte eine E-Mail, anstatt die Details öffentlich zu posten.