
PolyLingo vs DeepL API : lequel préserve mieux JSON et Markdown ?
By Robert M
PolyLingo vs DeepL API : lequel préserve mieux JSON et Markdown ?
DeepL propose un logiciel de traduction vraiment excellent. Son moteur de traduction neuronale est largement considéré comme l'un des meilleurs disponibles, et pour la prose simple, il est difficile à battre. Si vous traduisez des phrases, des paragraphes ou des documents écrits en texte continu, DeepL est un choix solide.
La question à laquelle ce post répond est plus restreinte : comment l'API DeepL fonctionne-t-elle lorsque votre contenu a une structure ? Lorsque vous devez traduire un fichier de localisation JSON sans toucher aux clés, ou un article de blog Markdown sans casser la syntaxe, ou une page HTML sans déformer les attributs ? Et comment cela se compare-t-il à PolyLingo pour ce cas d'utilisation spécifique ?
Comment l'API DeepL est construite
L'API de traduction de texte DeepL accepte du texte brut. C'est son format d'entrée natif. Chaque requête accepte jusqu'à 50 chaînes de texte qui sont traduites indépendamment, sans contexte partagé entre elles. Une seule langue cible peut être spécifiée par requête. Si vous avez besoin de cinq langues, vous faites cinq requêtes.
DeepL prend en charge la traduction de documents pour des formats comme PDF, Word, PowerPoint et HTML, mais cela passe par un point de terminaison de document séparé avec un flux différent : téléchargez le fichier, interrogez pour la fin, téléchargez le résultat. Il est conçu pour les documents bureautiques, pas pour les pipelines de contenu programmatiques.
Pour le HTML spécifiquement, il existe un paramètre tag_handling que vous pouvez définir sur html, ce qui indique à DeepL de traiter l'entrée comme du HTML et de tenter de préserver les balises. Cela fonctionne raisonnablement bien pour un balisage simple, mais c'est un drapeau optionnel que vous devez savoir définir, et cela ne s'étend pas au JSON ou au Markdown.
Pour le JSON, il n'y a pas de support natif. Le point de terminaison texte de DeepL ne sait pas ce qu'est une clé JSON. Si vous lui envoyez un objet JSON sérialisé, il traduira le contenu comme une chaîne et il n'y a aucune garantie que les clés, la structure ou les valeurs non chaînes survivent intactes. La bibliothèque R babeldown, qui enveloppe DeepL pour le contenu Markdown, a documenté des cas où DeepL mélange la ponctuation à l'intérieur des liens Markdown et du formatage, ce qui est une limitation connue du passage de texte structuré à travers un moteur de traduction de texte brut.
Ce n'est pas une critique de DeepL. C'est une description de ce pour quoi l'API a été conçue. Le cas d'utilisation principal de DeepL est la traduction de prose lisible par l'homme de haute qualité. C'est ce pour quoi il est optimisé et il est excellent dans ce domaine.
Où la différence apparaît en pratique
La différence devient visible dès que votre contenu n'est pas de la prose simple.
Considérez un fichier de localisation Next.js standard :
{
"nav": {
"home": "Home",
"about": "About us",
"contact": "Get in touch"
},
"hero": {
"title": "Welcome to our platform",
"subtitle": "Everything you need in one place"
}
}
Pour traduire cela avec l'API DeepL en cinq langues, vous devriez :
- Extraire chaque valeur de chaîne individuellement
- Faire une requête API séparée par langue (cinq langues, cinq requêtes)
- Reconstruire la structure JSON avec les valeurs traduites aux bons endroits
- Gérer les cas où la traduction a modifié la ponctuation ou introduit des caractères qui cassent la validité JSON
C'est une quantité non triviale de code de liaison. C'est aussi fragile. Toute déviation dans la sortie de traduction par rapport à ce que votre analyseur attend provoquera une erreur silencieuse ou une erreur d'exécution dans votre application.
Avec PolyLingo, vous envoyez l'objet tel quel avec format: "json" et recevez une version traduite de la structure complète pour chaque langue cible dans une seule réponse. Les clés restent intactes. L'imbrication est préservée. Les valeurs non chaînes sont laissées intactes. La sortie s'intègre directement dans votre projet.
curl -sS -X POST "https://api.usepolylingo.com/v1/translate" \
-H "Authorization: Bearer $POLYLINGO_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"content": "{\"nav\":{\"home\":\"Home\",\"about\":\"About us\"}}",
"format": "json",
"targets": ["fr", "de", "es", "ja", "nl"]
}'
Une requête. Cinq langues. Structure intacte.
Contenu Markdown
Le même schéma s'applique au Markdown. Le point de terminaison texte de DeepL n'a pas de notion de syntaxe Markdown. Envoyez-lui un article de blog et il traitera le tout comme une chaîne. Les titres peuvent survivre. Les blocs de code presque certainement pas, car le contenu à l'intérieur est susceptible d'être traité comme du texte traduisible. La syntaxe des liens peut être déformée, en particulier autour de la ponctuation aux limites du texte du lien.
Le drapeau de format markdown de PolyLingo indique au modèle de traiter la syntaxe Markdown comme structurelle plutôt que traduisible. Les titres restent des titres. Les blocs de code délimités sont laissés tels quels. Les URL des liens ne sont pas modifiées. Seul le contenu en prose change.
Pour un site de documentation ou un blog avec du contenu technique, la différence est significative. Un bloc de code corrompu dans un tutoriel n'est pas un problème mineur de présentation, c'est un tutoriel cassé.
La différence entre une requête et une par langue
Cela vaut la peine d'y insister car les implications de coût sont réelles.
L'API DeepL accepte une seule langue cible par requête. Pour traduire un contenu en dix langues, vous faites dix appels API. Pour un grand site ou un CMS avec des publications fréquentes, cela signifie dix fois plus de surcharge de requêtes, dix fois plus de latence à gérer, et dix fois plus de points de défaillance.
PolyLingo accepte un tableau de codes de langues cibles et renvoie toutes les traductions dans une seule réponse. Trente-six langues, c'est une requête, pas trente-six.
Pour les petits projets, la différence est gérable. À grande échelle, cela change l'architecture de la façon dont vous construisez votre pipeline de traduction.
Modèle de tarification
DeepL facture par caractère. Le plan API Free permet jusqu'à 500 000 caractères par mois, et les plans payants facturent selon la consommation de caractères. Comme vous faites une requête par langue, le nombre de caractères pour un contenu est multiplié par le nombre de langues cibles auxquelles vous l'envoyez dans des requêtes séparées.
PolyLingo facture par jeton et compte à la fois l'entrée et la sortie combinées pour toutes les langues dans une seule requête. La facturation est transparente et prévisible : le niveau gratuit inclut 50 000 jetons par mois, avec des plans payants à partir de 9 $ par mois pour 600 000 jetons.
Les deux modèles ne sont pas directement comparables sur une base coût par mot car ils utilisent des unités différentes, mais l'architecture d'une seule requête pour toutes les langues de PolyLingo signifie que vous ne multipliez pas linéairement votre nombre de requêtes par le nombre de langues cibles.
Où chacun convient
L'API DeepL est le bon choix lorsque :
- Votre contenu est de la prose simple sans exigences structurelles
- La qualité de traduction pour un texte lisible par l'humain est la principale préoccupation
- Vous traduisez en un petit nombre de langues et le volume de requêtes est faible
- Vous êtes déjà investi dans l'écosystème DeepL et utilisez leur glossaire ou leurs fonctionnalités de formalité
- Vous avez besoin de support pour une langue en dehors des 36 actuelles de PolyLingo (DeepL supporte plus de 100 langues)
PolyLingo est le bon choix lorsque :
- Votre contenu est JSON, Markdown ou HTML et la structure doit être préservée
- Vous devez traduire en plusieurs langues dans un seul appel API
- Vous construisez une intégration CMS ou un pipeline i18n où l'efficacité des requêtes est importante
- Vous souhaitez une interface cohérente pour tous les formats de contenu sans solutions spécifiques au format
- Vous souhaitez une facturation basée sur les jetons avec une allocation mensuelle prévisible
Résumé côte à côte
| PolyLingo | DeepL API | |
|---|---|---|
| Support natif JSON | Oui | Non |
| Support natif Markdown | Oui | Non |
| Support HTML | Oui | Oui (drapeau tag_handling) |
| Toutes les langues en une requête | Oui | Non, une langue par requête |
| Détection automatique du format de contenu | Oui | Non |
| Langues supportées | 36 | 100+ |
| Niveau gratuit | 50 000 jetons/mois | 500 000 caractères/mois |
| Unité de facturation | Jeton | Caractère |
| Traducteur web sans code | Oui | Oui (application web) |
DeepL dispose d'un catalogue de langues plus large et d'une expérience plus longue pour la qualité de traduction de prose. PolyLingo est conçu pour les flux de travail de contenu structuré où l'intégrité du format est non négociable.
Ils résolvent des problèmes adjacents. Le bon choix dépend de l'apparence réelle de votre contenu.
Essayez PolyLingo
Le niveau gratuit inclut 50 000 jetons par mois. Aucune carte de crédit requise. La documentation complète de l'API est disponible sur usepolylingo.com/docs.
curl -sS -X POST "https://api.usepolylingo.com/v1/translate" \
-H "Authorization: Bearer $POLYLINGO_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"content": "# Hello\n\nThis is **structured** content.",
"format": "markdown",
"targets": ["fr", "de", "es"]
}'