'N Lang pad na tale
Ek skop nou al 'n geruime tyd 'n idee wat interessant sowel as uitdagend geklink het: wat sou nodig wees om meertalige ondersteuning vir my web-app met so min moontlik onderhoud te bewerkstellig? Oorweeg die koste ook as 'n hoofbeperking (hierdie webwerf bied geen advertensies nie en gebruik geen spoorsny nie, dus geen inkomende inkomste hier nie), hoe sal 'n geldige oplossing daar uitsien?
Die plan
Alles begin en eindig met die vertaal-enjin om te gebruik. Danksy die gebruik van Ubuntu as een van my daaglikse bestuurders, het ek een keer 'n lekker klein app in die app store ontdek met die naam "Argos translate", wat 'n open source-vertaal-enjin is wat gebaseer is op die nuutste ML-modelle wat soortgelyk is aan dié wat DeepL aandryf. . As u DeepL nie ken nie, is dit 'n uitstekende vertaler om gratis op hul webwerf te gebruik.
Maar terug na Argos: nadat ek die verwante bewaarplek bekyk het, het ek gesien dat daar ook 'n OSS-python-lib beskikbaar is, wat mooi sou pas in 'n omgewing wat self aangebied word. Nadat ek vir 'n kort tydjie rondgespeel het, het ek besluit om deur SaaS-aanbieders na sommige vertalers te kyk, aangesien die hele afbetalingsproses van argos-vertaling nie regtig so mooi uitwerk soos ek gehoop het nie.
Daarom begin ek 'n ander diens, Cloud Translations van GCP, wat 500,000 karakters gratis per maand aanbied en dan geld vra vir elke 1.000.000.
Dit gaan alles oor caching
Danksy die instelling van Next.js met ISG (inkrementele werfgenerering) kan ek die vertalings vir elke bladsy op aanvraag noem, wat die beplanning baie vereenvoudig, aangesien geen enkele implementering met alle vertalings gelyktydig gedoen moet word nie.
Ek was nogtans nie seker oor hoe om die caching van die vertaalde snare te hanteer nie. Sekerlik, Vercel se randnetwerk (waar hierdie PWA aangebied word) kan hierdie taak absoluut benut. Maar ek wou hê dat die ontplooiings onafhanklik van die vertalings moes wees. daarom het ek een ekstra laag caching geskep via 'n eenvoudige Firestore-instansie, wat ook op GCP aangebied word.
Die grootste uitdaging was ontleding + vervanging van die blokinhoud vir elke artikel. As jy nie weet nie. Die blokinhoud beskryf die werklike deel van die artikel wat deur my in 'n CMS geskep word. By die vertaling is die blokke nie in gewone teks nie, maar eerder in 'n spesiale datastruktuur om die semantiese inligting of metadata te stoor. Een van die grootste dele van hierdie implementering was om net die betrokke snare betroubaar op te spoor + te vertaal.
Een man, 12+ tale
Die tale (tans ondersteun) is:
- "af": Engels
- "de": Duits
- "fr": Frans
- "es": Spaans
- "eo": Esperanto
- "el": Grieks
- "ja": Japannees
- "ru": Russies
- "hallo": Hindi
- "hy": Hebreeus
- "tr": Turks
- "af": Afrikaans
- "ar": Arabies
- "ko": Koreaans
Om die verskillende variante te toets, plaas die taalkode eenvoudig na die basis url. Byvoorbeeld: "https://flaming.codes/fr". En dit is dit!
Die opsomming van my implementering lyk soos volg:
- elke bladsy word minstens elke 4 uur staties gebou, maar slegs op aanvraag; dit beteken dat 'n nuwe vertaalwerk hoogstens elke 4 uur vir 'n gegewe webwerf gedoen word
- die vertalings self word eers vanaf Firestore gelaai; net as daar niks beskikbaar is nie, word die snare in Firestore vertaal + geberg
Hierdie opstelling werk so goed dat ek geen vertalings op 'n klassieke manier sal gebruik nie, bv. maak handmatig json-lêers wat die sleutelwaardes-pare behou. Ek sal die Cloud Translation API gebruik vir alles wat geïnternasionaliseer moet word, en dit volledig dinamies maak. Danksy hierdie veranderinge het die PWA ongeveer 430 bladsye op die oomblik geskryf.
Elke bladsy word vertaal uit Engels in 13 ander tale, wat die meeste gepraat word, sowel as dié wat regoor die wêreld tussen hulle geleë is. Kom ons kyk hoe dit sal ontwikkel!
- Tom
