PolyLingo vs DeepL API: kumpi säilyttää JSONin ja Markdownin paremmin?

DeepL tekee aidosti erinomaista käännösohjelmistoa. Sen neuroverkkopohjaista käännöskonetta pidetään laajalti yhtenä parhaista saatavilla olevista, ja tavallisen proosan kääntämisessä sitä on vaikea päihittää. Jos käännät lauseita, kappaleita tai jatkuvana tekstinä kirjoitettuja dokumentteja, DeepL on vahva valinta.

Tämän postauksen kysymys on kapeampi: miten DeepL API toimii, kun sisältösi on rakenteellista? Kun sinun täytyy kääntää JSON-lokalisointitiedosto koskematta avaimiin, tai Markdown-blogikirjoitus rikkomatta syntaksia, tai HTML-sivu ilman että attribuutit menevät sekaisin? Ja miten se vertautuu PolyLingoon juuri tässä käyttötapauksessa?

Miten DeepL API on rakennettu

DeepL:n tekstikäännös-API hyväksyy tavallisen tekstin. Se on sen natiivisyöttöformaatti. Jokainen pyyntö hyväksyy enintään 50 tekstijonoa, jotka käännetään itsenäisesti ilman jaettua kontekstia niiden välillä. Vain yksi kohdekieli voidaan määrittää per pyyntö. Jos tarvitset viisi kieltä, teet viisi pyyntöä.

DeepL tukee myös dokumenttien käännöstä PDF-, Word-, PowerPoint- ja HTML-muodoille, mutta se tapahtuu erillisen dokumenttipäätepisteen kautta eri prosessilla: tiedoston lataus, valvonta valmistumisesta, tuloksen lataus. Se on suunniteltu toimistodokumenteille, ei ohjelmallisille sisältöputkille.

HTML:lle on olemassa tag_handling-parametri, jonka voi asettaa arvoksi html, jolloin DeepL käsittelee syötteen HTML:nä ja yrittää säilyttää tageja. Tämä toimii kohtuullisesti yksinkertaisessa merkinnässä, mutta se on valinnainen lippu, joka pitää tietää asettaa, eikä se laajene JSONiin tai Markdowniin.

JSONille ei ole natiivituen. DeepL:n tekstipäätepiste ei tiedä, mikä JSON-avain on. Jos lähetät sille sarjoitetun JSON-objektin, se kääntää sisällön merkkijonona eikä ole takeita, että avaimet, rakenne tai ei-merkkijonot säilyvät ehjinä. Babeldown R-kirjasto, joka käärii DeepL:ää Markdown-sisällölle, on dokumentoinut tapauksia, joissa DeepL sekoittaa välimerkit Markdown-linkkien ja muotoilun sisällä, mikä on tunnettu rajoitus rakenteellisen tekstin läpiviennissä tavallisen tekstin käännöskoneen kautta.

Tämä ei ole kritiikki DeepL:lle. Se kuvaa, mihin API on suunniteltu. DeepL:n ydinkäyttötapaus on korkealaatuinen ihmisen luettavan proosan käännös. Siihen se on optimoitu ja siinä se on erinomainen.

Missä ero käytännössä näkyy

Ero tulee näkyviin heti, kun sisältösi ei ole pelkkää proosaa.

Otetaan esimerkki tavallisesta Next.js-lokalisointitiedostosta:

{
  "nav": {
    "home": "Home",
    "about": "About us",
    "contact": "Get in touch"
  },
  "hero": {
    "title": "Welcome to our platform",
    "subtitle": "Everything you need in one place"
  }
}

Kääntääksesi tämän DeepL API:lla viiteen kieleen sinun pitäisi:

Erottaa jokainen merkkijonoarvo erikseen
Tehdä erillinen API-pyyntö per kieli (viisi kieltä, viisi pyyntöä)
Koota JSON-rakenne uudelleen käännetyillä arvoilla oikeissa paikoissa
Käsitellä tilanteet, joissa käännös on muuttanut välimerkkejä tai lisännyt merkkejä, jotka rikkovat JSON:n validiteetin

Tämä on ei-triviaali määrä liimakoodia. Se on myös hauras. Mikä tahansa poikkeama käännöksen tulosteessa parserisi odotuksista aiheuttaa hiljaisen virheen tai ajonaikaisen virheen sovelluksessasi.

PolyLingon kanssa lähetät objektin sellaisenaan format: "json" ja saat takaisin käännetyn version koko rakenteesta jokaiselle kohdekielelle yhdessä vastauksessa. Avaimet säilyvät koskemattomina. Sisäkkäisyys säilyy. Ei-merkkijonoarvot jätetään rauhaan. Tuloste on suoraan käytettävissä projektissasi.

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"]
  }'

Yksi pyyntö. Viisi kieltä. Rakenne ehjänä.

Markdown-sisältö

Sama kaava pätee Markdowniin. DeepL:n tekstipäätepisteellä ei ole käsitystä Markdown-syntaksista. Lähetä sille blogikirjoitus, niin se käsittelee koko asian merkkijonona. Otsikot saattavat säilyä. Koodilohkot tuskin säilyvät, koska niiden sisältö käsitellään todennäköisesti käännettävänä tekstinä. Linkkisyntaksi voi mennä sekaisin, erityisesti linkkitekstin rajojen välimerkkien kohdalla.

PolyLingon markdown-formaattilippu ohjaa mallia käsittelemään Markdown-syntaksin rakenteellisena, ei käännettävänä. Otsikot pysyvät otsikoina. Aidot koodilohkot säilyvät sellaisenaan. Linkkien URL-osoitteita ei muuteta. Vain proosasisältö muuttuu.

Dokumentaatiosivustolla tai teknistä sisältöä sisältävässä blogissa ero on merkittävä. Korruptoitunut koodilohko tutoriaalissa ei ole pieni esitysongelma, vaan rikkinäinen opas.

Yksi pyyntö vs yksi per kieli -ero

Tähän kannattaa kiinnittää huomiota, koska kustannusvaikutukset ovat todellisia.

DeepL:n API hyväksyy vain yhden kohdekielen per pyyntö. Kääntääksesi sisällön kymmeneen kieleen teet kymmenen API-kutsua. Suurelle sivustolle tai usein julkaisevalle CMS:lle se tarkoittaa kymmenkertaisia pyyntöjä, kymmenkertaisia viiveitä hallittavaksi ja kymmenkertaisia virhekohtia.

PolyLingo hyväksyy kohdekielikoodien taulukon ja palauttaa kaikki käännökset yhdessä vastauksessa. Kolmekymmentäkuusi kieltä on yksi pyyntö, ei kolmekymmentäkuusi.

Pienissä projekteissa ero on hallittavissa. Suuremmassa mittakaavassa se muuttaa arkkitehtuuria, jolla rakennat käännösputkesi.

Hinnoittelumalli

DeepL veloittaa merkkimäärän mukaan. API Free -suunnitelma sallii enintään 500 000 merkkiä kuukaudessa, ja maksulliset suunnitelmat laskuttavat merkkikulutuksen mukaan. Koska teet yhden pyynnön per kieli, sisällön merkkimäärä kerrotaan kohdekielten lukumäärällä eri pyynnöissä.

PolyLingo veloittaa tokeneista ja laskee yhdistetyn syötteen ja tulosteen kaikkien kielten osalta yhdessä pyynnössä. Laskutus on läpinäkyvää ja ennustettavaa: ilmaisessa tasossa on 50 000 tokenia kuukaudessa, maksulliset suunnitelmat alkavat 9 dollarista kuukaudessa 600 000 tokenilla.

Mallit eivät ole suoraan vertailukelpoisia kustannus per sana -perusteella, koska ne käyttävät eri yksiköitä, mutta PolyLingon yhden pyynnön kaikille kielille -arkkitehtuuri tarkoittaa, ettet kerro pyyntömäärääsi lineaarisesti kohdekielten lukumäärällä.

Missä kukin sopii

DeepL API on oikea valinta, kun:

Sisältösi on pelkkää proosaa ilman rakenteellisia vaatimuksia
Käännöksen laatu ihmisen luettavalle tekstille on ensisijainen
Käännät pieneen määrään kieliä ja pyyntöjen määrä on pieni
Olet jo investoinut DeepL-ekosysteemiin ja käytät heidän sanasto- tai muodollisuusominaisuuksiaan
Tarvitset tukea kielelle, jota PolyLingo ei vielä tue (DeepL tukee yli 100 kieltä)

PolyLingo on oikea valinta, kun:

Sisältösi on JSONia, Markdownia tai HTML:ää ja rakenne on säilytettävä
Tarvitset käännöksen usealle kielelle yhdellä API-kutsulla
Rakennat CMS-integraatiota tai i18n-putkea, jossa pyyntötehokkuus on tärkeää
Haluat yhdenmukaisen käyttöliittymän kaikille sisältöformaateille ilman formaattikohtaisia kiertoteitä
Haluat token-pohjaisen laskutuksen ennustettavalla kuukausilisenssillä

Vierekkäinen yhteenveto

	PolyLingo	DeepL API
Natiivituki JSONille	Kyllä	Ei
Natiivituki Markdownille	Kyllä	Ei
HTML-tuki	Kyllä	Kyllä (`tag_handling`-lippu)
Kaikki kielet yhdessä pyynnössä	Kyllä	Ei, yksi kieli per pyyntö
Sisällön formaatin automaattitunnistus	Kyllä	Ei
Tuetut kielet	36	100+
Ilmainen taso	50 000 tokenia/kuukausi	500 000 merkkiä/kuukausi
Laskutusyksikkö	Token	Merkki
Kooditon verkkokääntäjä	Kyllä	Kyllä (verkkosovellus)

DeepL:llä on laajempi kielivalikoima ja pidempi kokemus proosan käännösten laadusta. PolyLingo on tarkoitettu rakenteellisten sisältötyönkulkujen tarpeisiin, joissa formaatin eheys on ehdoton.

Ne ratkaisevat vierekkäisiä ongelmia. Oikea valinta riippuu siitä, miltä sisältösi todellisuudessa näyttää.

Kokeile PolyLingoa

Ilmainen taso sisältää 50 000 tokenia kuukaudessa. Ei luottokorttia vaadita. Täysi API-dokumentaatio löytyy osoitteesta 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"]
  }'

Hanki API-avaimesi

PolyLingo vs DeepL API: Kumpi säilyttää JSON:n ja Markdownin paremmin?