Hosszú út a nyelvekhez
Már jó ideje rúgok egy ötletet, amely érdekesnek és kihívásnak is tűnt: mi szükséges a webalkalmazásom többnyelvű támogatásához a lehető legkevesebb karbantartással? A költségeket is fő korlátozásnak tekintve (ez a webhely nem jelenít meg hirdetéseket, és egyáltalán nem használ nyomkövetést, tehát itt nincs bejövő bevétel), hogy nézne ki egy érvényes megoldás?
A terv
Minden a használni kívánt fordítómotorral kezdődik és végződik. Az Ubuntu használatának köszönhetően a napi illesztőprogramok egyikeként egyszer felfedeztem egy szép kis alkalmazást az App Store-ban „Argos translate” néven, amely egy nyílt forráskódú fordítómotor, amely a legújabb ML-modellekre épül, amelyek hasonlóak a DeepL-hez. . Ha nem ismeri a DeepL-t, az nagyszerű fordító, amelyet ingyen használhat a weboldalán.
De visszatérve az Argosra: miután megnéztem a kapcsolódó tárat, láttam, hogy rendelkezésre áll egy OSS python-lib is, amely szépen elférne egy saját által üzemeltetett környezetben. Miután rövid ideig végigjátszottam, úgy döntöttem, hogy megnézek néhány fordítót a SaaS ajánlatokon keresztül, mivel az argos fordítás teljes részletfizetési folyamata nem igazán sikerült olyan szépen, mint reméltem.
Ezért elindítottam egy másik szolgáltatást, a Cloud Translations from GCP szolgáltatást, amely havonta 500 000 karaktert kínál ingyenesen, majd minden 1 000 000-ért pénzt kér.
A gyorsítótárról van szó
Köszönhetően a Next.js telepítésének ISG-vel (inkrementális webhelygenerálás), igény szerint hívhatom az egyes oldalak fordításait, ami meglehetősen leegyszerűsíti a tervezést, mivel nem kell egyetlen telepítést végrehajtani az összes fordítással egyszerre.
Még mindig nem voltam biztos abban, hogyan kell kezelni a lefordított húrok gyorsítótárát. Persze, a Vercel élhálózata (ahol ez a PWA található) abszolút kihasználhatja ezt a feladatot. De azt akartam, hogy a telepítések függetlenek legyenek a fordításoktól. ezért hoztam létre egy extra gyorsítótár-réteget egy egyszerű Firestore példányon keresztül, amelyet szintén a GCP tárolt.
A legnagyobb kihívás a blokk tartalmának elemzése + cseréje volt minden cikknél. Ha nem tudod. A blokk tartalma leírja a cikk tényleges törzsét, amelyet én hozok létre egy CMS-ben. A fordítás során ezek a blokkok nem egyszerű szövegben vannak, hanem mindegyik egy speciális adatstruktúrába van ágyazva, hogy lehetővé tegye a szemantikai információk vagy metaadatok tárolását. Csak a releváns karakterláncok megbízható észlelése + fordítása volt a megvalósítás egyik nagyobb része.
Egy ember, 12+ nyelven
A (jelenleg) támogatott nyelvek a következők:
- "en": angol
- "de": német
- "fr": francia
- "es": spanyol
- "eo": eszperantó
- "el": görög
- "ja": japán
- "ru": orosz
- "szia": hindi
- "he": héber
- "tr": török
- "af": afrikaans
- "ar": arab
- "ko": koreai
A különböző változatok teszteléséhez egyszerűen helyezze el a nyelvi kódot az alap URL után. Például: "https://flaming.codes/fr". És ez az!
Összefoglalva a megvalósításomat, a beállítás így néz ki:
- minden oldal statikusan felépül legalább 4 óránként, de csak igény szerint; ez azt jelenti, hogy egy adott webhelyen legfeljebb 4 óránként új fordítási munkát végeznek
- maguk a fordítások töltődnek be először a Firestore-ból; csak ha nincs elérhető információ, a húrokat lefordítják + gyorsítótárba helyezik a Firestore-ban
Ez a beállítás annyira jól működik, hogy nem használok klasszikus fordításokat, pl. a kulcs-érték párokat megőrző json fájlok manuális létrehozása. A Cloud Translation API-t mindenre felhasználom, amelyet nemzetközivé kell tenni, teljes dinamikussá téve azt. Ezeknek a változásoknak köszönhetően a PWA-nak mintegy 430 oldala van írás közben.
Minden oldal angolról 13 másik nyelvre kerül lefordításra, amelyek a legtöbbet beszélteket képviselik, valamint azokat, amelyek a világ minden táján találhatók közöttük. Lássuk, hogyan fog alakulni!
- Tom
