Kai projektuoji svetainę ar aplikaciją, kuri turi veikti keliomis kalbomis, turinys tampa tikru galvos skausmu. Viena kalba – dar nieko, bet kai reikia valdyti tą patį turinį lietuviškai, angliškai, vokiškai ir dar keliais variantais, pradedi svajoti apie paprastesnius laikus. Čia ir ateina į pagalbą Prismic CMS – headless turinio valdymo sistema, kuri daugiakalbį turinį tvarko gana elegantiškai.
Kodėl headless CMS daugiakalbiam projektui
Prismic priklauso headless CMS kategorijai, o tai reiškia, kad jis neturi savo frontend’o – tiesiog teikia turinį per API. Skamba paprasta, bet šis požiūris turi didžiulę reikšmę daugiakalbiam turiniui. Tradicinės CMS, kaip WordPress ar Drupal, dažnai reikalauja įvairių pluginų ir workaround’ų, kad normaliai veiktų su keletu kalbų. Prismic šią funkciją turi iš dėžės.
Kas man patinka – nebereikia galvoti apie tai, kaip frontend’as atvaizduos turinį. Gali naudoti React, Vue, Next.js, Nuxt ar net vanilla JavaScript. Prismic tiesiog duoda JSON’ą, o tu su juo darai ką nori. Tai ypač patogu, kai dirbi su komanda, kur frontend ir backend developeriai dirba atskirai, arba kai vienas projektas turi kelias platformas – web, mobile app, digital signage.
Kaip Prismic tvarko kalbas
Prismic daugiakalbės funkcijos veikia per tai, ką jie vadina „locales”. Sukuri pagrindinę kalbą (master locale) ir tada pridedi papildomas. Kiekvienas content type’as automatiškai tampa prieinamas visose sukonfigūruotose kalbose. Tai nėra kažkoks rocket science, bet implementacija tikrai patogi.
Praktiškai tai atrodo taip: sukuri dokumentą anglų kalba, ir Prismic automatiškai sukuria tuščius to paties dokumento variantus kitoms kalboms. Tuomet content editoriai gali užpildyti kiekvieną kalbos versiją atskirai. Svarbu suprasti, kad kiekviena kalbos versija yra atskiras dokumentas su savo ID, bet jie susieti tarpusavyje per „alternate languages” ryšį.
Štai kaip tai atrodo kode, kai nori gauti dokumentą su visomis jo kalbų versijomis:
const document = await client.getByUID('page', 'homepage', {
lang: 'lt-lt'
});
// Gauni visas alternatyvias kalbas
const alternateLanguages = document.alternate_languages;
Vienas dalykas, kurį reikia žinoti iš anksto – Prismic nenaudoja standartinių ISO kalbų kodų. Jie naudoja lowercase formatą su brūkšneliu, pvz., „en-us”, „lt-lt”, „de-de”. Tai gali būti šiek tiek neįprasta, jei esi įpratęs prie „en_US” ar „en-GB” formatų, bet greitai pripranti.
Struktūros kūrimas su custom types
Prismic dirba su custom types – tai kaip blueprint’ai tavo turiniui. Sukuri custom type’ą, apibrėži laukus, ir tada gali kurti neribotą kiekį dokumentų pagal tą šabloną. Kai dirbi su daugiakalbiu turiniu, svarbu suprasti, kad custom type struktūra yra ta pati visoms kalboms – keičiasi tik turinys.
Pavyzdžiui, jei kuri blog post custom type’ą su laukais „title”, „author”, „content” ir „featured_image”, visi šie laukai bus prieinami visose kalbose. Bet čia ir slypi vienas niuansas – ne viskas turėtų būti verčiama. Pavyzdžiui, autoriaus vardas greičiausiai lieka tas pats, o featured_image gali būti bendras arba skirtingas priklausomai nuo konteksto.
Prismic leidžia konfigūruoti, kurie laukai yra „shared” tarp kalbų. Tai daroma per API, ne per UI, kas šiek tiek nepatogu, bet suteikia daugiau kontrolės. Praktiškai dažniausiai shared būna media laukai ir ID tipo laukai, o tekstiniai laukai lieka lokalūs kiekvienai kalbai.
Content Relationships tarp kalbų
Dalykas, kuris gali sukelti painiavos – tai kaip veikia content relationships daugiakalbėje aplinkoje. Tarkime, turi blog post’ą, kuris turi relationship lauką į „Author” dokumentą. Kai sukuri anglišką blog post’ą ir susieji jį su anglišku author dokumentu, lietuviškoje versijoje tas ryšys nepersikeičia automatiškai į lietuvišką author versiją.
Tai reiškia, kad content editoriai turi rankiniu būdu pasirinkti teisingą kalbos versiją kiekvienam relationship’ui. Skamba kaip papildomas darbas, bet iš tikrųjų tai suteikia lankstumo – kartais nori, kad ryšys būtų į kitą kalbą, pavyzdžiui, jei autor’iaus profilis egzistuoja tik vienoje kalboje.
Kodas, kuris ištraukia susijusį turinį su teisinga kalba:
const blogPost = await client.getByUID('blog_post', 'my-post', {
lang: 'lt-lt',
fetchLinks: ['author.name', 'author.bio']
});
// Jei author relationship nurodo į kitą kalbą,
// gali reikėti papildomo query
if (blogPost.data.author.lang !== 'lt-lt') {
const authorLT = await client.getByID(
blogPost.data.author.id,
{ lang: 'lt-lt' }
);
}
Routing ir URL struktūra
Kai kuri daugiakalbę svetainę, vienas iš pirmųjų klausimų – kaip organizuoti URL’us. Prismic čia neprimetą jokio sprendimo, kas yra ir gerai, ir blogai. Gerai, nes turi visišką kontrolę. Blogai, nes turi viską implementuoti pats.
Populiariausi URL struktūros variantai daugiakalbėms svetainėms:
- Subdomain’ai: en.example.com, lt.example.com
- Path’ai: example.com/en/, example.com/lt/
- Query parametrai: example.com?lang=en (mažiau SEO friendly)
- Atskiri domain’ai: example.com, example.lt
Dažniausiai naudojamas path’ų metodas, nes jis paprasčiausias implementuoti ir SEO friendly. Su Next.js tai gali atrodyti taip:
// pages/[lang]/[uid].js
export async function getStaticProps({ params, locale }) {
const client = createClient();
const page = await client.getByUID('page', params.uid, {
lang: locale || 'en-us'
});
return {
props: { page }
};
}
Svarbu nepamiršti hreflang tagų SEO optimizavimui. Prismic suteikia alternate_languages informaciją, kurią gali panaudoti generuojant šiuos tagus:
Praktiniai iššūkiai ir sprendimai
Dirbant su Prismic daugiakalbiam projektui, susiduri su keletu praktinių problemų, kurias verta žinoti iš anksto.
Fallback turinys: Kas nutinka, kai lietuviška versija dar neparašyta, bet svetainė jau live? Prismic neturi built-in fallback mechanizmo. Tai reiškia, kad turi implementuoti patys. Paprasčiausias būdas – tikrinti, ar dokumentas egzistuoja reikiama kalba, jei ne – rodyti anglišką versiją su disclaimer’iu.
async function getPageWithFallback(uid, preferredLang, fallbackLang = 'en-us') {
try {
return await client.getByUID('page', uid, { lang: preferredLang });
} catch (error) {
if (error.message.includes('No documents found')) {
return await client.getByUID('page', uid, { lang: fallbackLang });
}
throw error;
}
}
Preview funkcionalumas: Prismic turi preview režimą, bet su daugiakalbiu turiniu reikia papildomai pasirūpinti, kad preview veiktų teisingoje kalboje. Tai reiškia, kad preview resolver’yje turi tikrinti dokumento kalbą ir redirect’inti į teisingą URL.
Sitemap generavimas: Kai turi kelias kalbas, sitemap tampa šiek tiek komplikuotesnis. Geriausias būdas – generuoti atskirą sitemap kiekvienai kalbai arba vieną su visomis kalbomis, bet su teisingais hreflang annotations.
Content editorių workflow: Vienas iš didžiausių iššūkių nėra techninis – tai organizacinis. Kaip užtikrinti, kad content editoriai žino, kurios kalbų versijos jau užpildytos, o kurios dar laukia? Prismic UI rodo, ar kalbos versija egzistuoja, bet nerodo, ar ji pilnai užpildyta. Čia gali padėti custom dashboard’as arba paprastas script’as, kuris tikrina tuščius laukus.
Integracijos su translation management sistemomis
Jei dirbi su profesionaliais vertėjais arba naudoji translation management sistemas (TMS) kaip Phrase, Lokalise ar Crowdin, Prismic neturi native integracijos. Tai gali būti deal breaker’is dideliems projektams, kur vertimo workflow yra kritinis.
Tačiau galima sukurti custom integraciją per Prismic API. Pagrindinis workflow’as atrodytų taip:
- Eksportuoji turinį iš Prismic JSON formatu
- Konvertuoji į TMS palaikomą formatą (dažniausiai XLIFF ar JSON)
- Siunti į TMS vertimui
- Gauni išverstą turinį
- Importuoji atgal į Prismic per API
Prismic Writing Room API leidžia programiškai kurti ir atnaujinti dokumentus, tad techniškai tai įmanoma, bet reikia nemažai custom kodo. Jei vertimo workflow yra labai svarbus, verta apsvarstyti CMS, kurios turi native TMS integraciją, kaip Contentful ar Sanity.
Kas veikia gerai ir kur dar yra erdvės tobulėti
Po kelių projektų su Prismic daugiakalbiam turiniui, galiu pasakyti, kad sistema veikia solidžiai, bet nėra be trūkumų. Kas tikrai patinka – tai paprasta pradžia. Pridedi kalbas, ir viskas tiesiog veikia. Nereikia jokių pluginų ar sudėtingų konfigūracijų. Content editorių sąsaja intuitivi, ir dauguma žmonių greitai supranta, kaip dirbti su skirtingomis kalbų versijomis.
Prismic Slice Machine – jų komponentų bibliotekos įrankis – taip pat gerai veikia su daugiakalbiu turiniu. Galima kurti reusable content blokus, kurie automatiškai veikia visose kalbose. Tai labai patogu, kai turi sudėtingus puslapius su daug skirtingų sekcijų.
Tačiau yra dalykų, kurie galėtų būti geresni. Jau minėjau TMS integracijų trūkumą. Taip pat trūksta geresnio content completion tracking’o – būtų super, jei UI aiškiai rodytų, kuri kalbos versija yra 100% užpildyta, o kuri tik 60%. Dabar tai reikia tikrinti rankiniu būdu arba rašyti custom script’us.
Dar vienas dalykas – bulk operacijos. Jei nori atnaujinti tam tikrą lauką visose kalbų versijose, turi daryti tai rankiniu būdu kiekvienai kalbai atskirai arba naudoti API. Būtų patogu turėti UI funkciją „update all language versions” bent jau shared laukams.
Bet apskritai, Prismic yra solid pasirinkimas daugiakalbiam projektui, ypač jei dirbi su moderniomis frontend technologijomis ir nori turėti kontrolę virš viso rendering proceso. Jis nėra pigiausias variantas rinkoje (kainos pradeda augti su daugiau locale’ų ir content editorių), bet už tą kainą gauni stabilią sistemą su geru developer experience. Jei tavo projektas nereikalauja super sudėtingo vertimo workflow’o ir gali susitvarkyti su keliais minėtais apribojimais, Prismic tikrai verta apsvarstyti. Pradėti lengva, dokumentacija gera, o community aktyvus – tai svarbu, kai 3 val. nakties kažkas neveikia ir reikia atsakymų.