Ein Headless-Stack besitzt bereits sein Rendering, sodass Universally als Übersetzungsdienst fungiert, den Ihr Server aufruft, anstatt etwas, das vor Ihrer Website sitzt. Sie senden Text, Sie erhalten Text zurück und Sie entscheiden, wo er gespeichert und wann er aktualisiert wird.
Die API und die Schlüssel werden in Integration mit der API behandelt. Diese Seite befasst sich damit, welche Teile davon für ein entkoppeltes Frontend geeignet sind.
Welcher Endpunkt passt
Die Translator API hat zwei, die hier relevant sind, und Headless-Setups möchten normalerweise die erste:
/v1/translate/strings |
/v1/translate/html |
|
|---|---|---|
| Sie senden | bis zu 500 Zeichenketten pro Anfrage | eine gerenderte Seite |
| Sie erhalten zurück | eine Zuordnung von Quellzeichenkette zu Übersetzung | das übersetzte Dokument |
| Passt | Inhalte, die aus einem CMS als Felder stammen | serverseitig gerenderte Seiten, die Sie gerade zurückgeben wollten |
Mit dem Zeichenketten-Endpunkt bleibt Ihr CMS die Quelle der Wahrheit. Ziehen Sie die benötigten Felder, senden Sie die Werte, speichern Sie, was zurückkommt, unter denselben Schlüsseln. Nichts muss erraten, welcher Teil einer Seite Inhalt ist.
curl -X POST https://translator.universally.com/v1/translate/strings \
-H "X-API-Key: $UNIVERSALLY_KEY" \
-H "Content-Type: application/json" \
-d '{"strings":["Add to cart","Out of stock"],"targetLanguage":"es"}'
Die Antwort enthält die Übersetzungen plus einen Metadatenblock: stringsReceived, stringsTranslated, skippedStrings und limitReached. Lesen Sie limitReached bei jeder Antwort. Wenn es true ist, ist die Antwort teilweise.
Eine Zeichenkette, die nicht übersetzt wurde, fehlt in translations und wird nicht unverändert zurückgegeben. Suchen Sie jeden Schlüssel mit einem Fallback auf Ihren eigenen Quelltext (translations[s] ?? s), sonst rendern Sie undefined. Siehe Zeichenketten übersetzen.
Wiederholte Anfragen für bereits übersetzte Texte werden aus dem Speicher bedient und kosten nichts extra. Das Senden von fresh: true übersetzt erneut und gibt das Ergebnis zurück, ohne es zu speichern. Behalten Sie also Ihre eigene Kopie von allem, was Sie auf diese Weise erhalten: Eine spätere Anfrage ohne fresh gibt immer noch die gespeicherte Übersetzung zurück. Diese Aufrufe zählen auch nicht zu Ihrem Wortkontingent.
Behalten Sie den Schlüssel serverseitig
Der Projektschlüssel darf den Browser nicht erreichen. Alles in Frontend-JavaScript, in einem mobilen Bundle oder in einem Repository ist öffentlich, und der Schlüssel kann Ihr Wortkontingent aufbrauchen. Rufen Sie die API von Ihrem Server oder Build-Schritt auf und servieren Sie dann das gespeicherte Ergebnis an Clients. Siehe API-Schlüssel finden.
Was Ihnen gehört
Das WordPress-Plugin erledigt mehrere Dinge über den Aufruf eines Endpunkts hinaus. Über die API gehören sie Ihnen:
- Eine URL pro Sprache. Etwas muss
/es/pricing/an Ihr spanisches Rendering weiterleiten. Universally fängt keinen Datenverkehr ab. Siehe Subdomains und Unterverzeichnisse für die zu kopierende Struktur. - Speicherung und Invalidierung. Bewahren Sie Übersetzungen neben Ihren Inhalten auf und senden Sie eine Zeichenkette erneut, wenn sich die Quelle ändert. Die Übersetzung bei jeder Anfrage ist langsam und sinnlos.
- Der Sprachumschalter. Es wird kein Widget eingefügt, daher gehören das Markup und der Zustand Ihnen.
- hreflang und Sitemaps. Das WordPress-Plugin gibt hreflang-Alternativen aus; Ihr eigenes Frontend gibt seinen eigenen
<head>aus, sodass diese Links Teil der Integration sind. Siehe hreflang-Tags.
Was funktioniert noch ohne WordPress
Alles, was im Dashboard und nicht im Plugin lebt, gilt gleichermaßen für Ihre Inhalte:
- Glossaregeln, die bei der Übersetzung angewendet werden, sodass Markennamen auch im API-Pfad erhalten bleiben.
- Übersetzungen manuell bearbeiten, um eine bestimmte Zeichenkette zu korrigieren.
- Sprachvarianten und regionale Ausrichtung, da eine Variante anhand des von Ihnen gesendeten Sprachcodes ausgewählt wird.