Une pile headless possède déjà son rendu, donc Universally s'intègre comme un service de traduction que votre serveur appelle plutôt que quelque chose qui se place devant votre site. Vous envoyez du texte, vous recevez du texte, et vous décidez où il est stocké et quand il est actualisé.
L'API et les clés sont abordées dans Intégrer via l'API. Cette page explique quelles parties conviennent à un frontend découplé.
Quel point d'accès convient
L'API Translator API en a deux qui sont importantes ici, et les configurations headless préfèrent généralement la première :
/v1/translate/strings |
/v1/translate/html |
|
|---|---|---|
| Vous envoyez | jusqu'à 500 chaînes par requête | une page rendue |
| Vous recevez en retour | une carte de la chaîne source vers la traduction | le document traduit |
| Convient | du contenu provenant d'un CMS sous forme de champs | des pages rendues côté serveur que vous étiez sur le point de retourner |
Avec le point d'accès aux chaînes, votre CMS reste la source de vérité. Récupérez les champs dont vous avez besoin, envoyez les valeurs, stockez ce qui revient sous les mêmes clés. Rien n'a besoin de deviner quelle partie d'une page est du contenu.
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"}'
La réponse contient les traductions plus un bloc de métadonnées : stringsReceived, stringsTranslated, skippedStrings et limitReached. Lisez limitReached à chaque réponse. Quand il est true, la réponse est partielle.
Une chaîne qui n'a pas été traduite est absente de translations, pas retournée telle quelle. Recherchez chaque clé avec un fallback vers votre propre texte source (translations[s] ?? s), sinon vous rendrez undefined. Voir Traduire des chaînes.
Les requêtes répétées pour du texte déjà traduit sont servies depuis le stockage et ne coûtent rien de plus. Envoyer fresh: true traduit à nouveau et retourne le résultat sans le stocker, alors conservez votre propre copie de tout ce que vous obtenez de cette façon : une requête ultérieure sans fresh retournera toujours la traduction stockée. Ces appels ne comptent pas non plus dans votre total de mots.
Gardez la clé côté serveur
La clé du projet ne doit pas atteindre le navigateur. Tout ce qui se trouve dans le JavaScript frontend, dans un bundle mobile, ou dans un dépôt est public, et la clé peut dépenser votre total de mots. Appelez l'API depuis votre serveur ou votre étape de build, puis servez le résultat stocké aux clients. Voir Trouver votre clé API.
Ce que vous possédez
Le plugin WordPress fait plusieurs choses en plus d'appeler un point d'accès. Via l'API, ce sont les vôtres :
- Une URL par langue. Quelque chose doit router
/es/pricing/vers votre rendu espagnol. Universally n'intercepte pas le trafic. Voir Sous-domaines et sous-répertoires pour le format à copier. - Stockage et invalidation. Gardez les traductions à côté de votre contenu et renvoyez une chaîne lorsque la source change. Traduire à chaque requête est lent et inutile.
- Le sélecteur de langue. Aucun widget n'est injecté, donc le balisage et l'état vous appartiennent.
- hreflang et sitemaps. Le plugin WordPress émet des hreflang alternatifs ; votre propre front-end émet son propre
<head>, donc ces liens font partie de l'intégration. Voir les balises hreflang.
Ce qui fonctionne toujours sans WordPress
Tout ce qui vit dans le tableau de bord plutôt que dans le plugin s'applique à votre contenu de la même manière :
- Règles de glossaire, appliquées lors de la traduction, de sorte que les noms de marque soient également conservés dans le chemin de l'API.
- Modifier les traductions manuellement pour corriger une chaîne spécifique.
- Variantes linguistiques et ciblage régional, car une variante est choisie par le code de langue que vous envoyez.