Longa vojo al lingvoj
Mi pripensis ideon jam de sufiĉe longa tempo, kiu sonis interesa kaj ankaŭ defia: kio estus necesa por atingi plurlingvan subtenon por mia retprogramo kun kiel eble plej malmulte da prizorgado? Ankaŭ konsiderante kostojn kiel ĉefan limon (ĉi tiu retejo tute ne uzas reklamojn kaj tute ne uzas spurojn, do neniu envenanta enspezo ĉi tie), kiel aspektus valida solvo?
La plano
Ĉio komenciĝas kaj finiĝas per la uzota tradukilo. Danke al uzado de Ubuntu kiel unu el miaj ĉiutagaj ŝoforoj, mi iam malkovris agrablan malgrandan programon en la programvendejo nomata "Argos translate", kiu estas malfermfonteca traduko motoro konstruita laŭ la plej novaj ML-modeloj, similaj al tiuj, kiuj funkciigas DeepL . Se vi ne konas DeepL, tio estas bonega tradukilo senpage uzi en sia retejo.
Sed reen al Argos: rigardinte la rilatan deponejon, mi vidis, ke ekzistas ankaŭ OSS python-lib havebla, kiu bele taŭgus en mem-gastigita medio. Post ĉirkaŭludado dum mallonga tempodaŭro, mi decidis rigardi iujn tradukistojn per SaaS-ofertoj, ĉar la tuta transdona procezo de argotradukado ne efektiviĝis tiel bele kiel mi esperis.
Mi do ekis alian servon, Cloud Translations de GCP, kiu ofertas 500,000 signojn senpage monate kaj tiam ŝargas iom da mono por ĉiu 1,000,000.
Ĉio temas pri kaŝmemoro
Danke al la agordo de Next.js kun ISG (pliiga retejo-generacio) mi povas telefoni la tradukojn por ĉiu paĝo laŭpete, kio faciligas planadon sufiĉe multe, ĉar neniu sola deplojo kun ĉiuj tradukoj samtempe devas esti plenumita.
Tamen mi ne certis pri kiel trakti la kaŝmemoradon de la tradukitaj kordoj. Certe, la randa reto de Vercel (kie ĉi tiu PWA estas gastigita) povas absolute utiligi ĉi tiun taskon. Sed mi volis, ke la deplojoj estu sendependaj de la tradukoj. tial mi kreis unu ekstran tavolon de konservado per simpla ekzemplero de Firestore, ankaŭ gastigita ĉe GCP.
La plej granda defio estis analizi + anstataŭigi la blokan enhavon por ĉiu artikolo. Se vi ne scias. La blokita enhavo priskribas la efektivan korpon de la artikolo, kreita de mi en SMC. Post traduko, tiuj blokoj ne estas en simpla teksto sed prefere ĉiu enigita en specialan datuman strukturon por permesi la stokadon de semantikaj informoj aŭ metadatenoj. Fidinde detekti + traduki nur la koncernajn ĉenojn estis unu el la pli grandaj partoj de ĉi tiu efektivigo.
Unu viro, 12+ lingvoj
La subtenataj lingvoj (nuntempe) estas:
- "eo": angla
- "de": germana
- "fr": franca
- "es": hispana
- "eo": Esperanto
- "el": greka
- "ja": japano
- "ru": rusa
- "hi": hinda
- "li": hebrea
- "tr": turka
- "af": afrikansa
- "ar": araba
- "ko": korea
Por testi la malsamajn variantojn, simple metu la lingvan kodon post la baza url. Ekzemple: "https://flaming.codes/fr". Kaj jen ĝi!
Resumante mian efektivigon, la aranĝo aspektas jene:
- ĉiu paĝo statike konstruiĝas almenaŭ ĉiun 4 horojn, sed nur laŭpete; ĉi tio signifas, ke nova traduka laboro estas farita maksimume ĉiu 4 horoj por difinita retejo
- la tradukoj mem unue estas ŝarĝitaj de Firestore; nur se estas nenio havebla, la kordoj tradukiĝas + kaŝmemore en Firestore
Ĉi tiu aranĝo funkcias tiel bone, ke mi ne uzos iujn tradukojn laŭ klasika maniero, ekz. permane kreante json-dosierojn, kiuj konservas la ŝlosilajn valorojn-parojn. Mi uzos la Cloud Translation API por ĉio internaciigebla, farante ĝin plene dinamika. Danke al ĉi tiuj ŝanĝoj, la PWA havas ĉirkaŭ 430 paĝojn dum la verkado.
Ĉiu paĝo estas tradukita de la angla al 13 aliaj lingvoj, kiuj reprezentas la plej parolatajn kaj ankaŭ tiujn, kiuj troviĝas ĉirkaŭ la mondo inter ili. Ni vidu, kiel ĝi evoluos!
- Tom
