Internaționalizare și localizare pentru site-uri statice

Internaționalizarea și localizarea înseamnă mai mult decât scrierea conținutului în mai multe limbi. Aveți nevoie de o strategie pentru a determina ce localizare să trimiteți și de cod pentru a face acest lucru. Trebuie să puteți accepta nu doar limbi diferite, ci și regiuni diferite cu aceeași limbă. Interfața dvs. de utilizare trebuie să răspundă, nu doar la dimensiunea ecranului, ci și la diferite limbi și moduri de scriere. Conținutul dvs. trebuie să fie structurat, până la microcopie din interfața dvs. de utilizare și formatul datelor dvs., pentru a fi adaptabil la orice limbă pe care o aruncați. Făcând toate acestea cu un generator de site static, cum ar fi Eleventy, poate îngreuna și mai mult, deoarece este posibil să nu aveți o bază de date, totuși un server. Totuși, totul poate fi făcut, dar este nevoie de planificare.

Când construim chromeOS.dev, știam că trebuie să-l facem disponibil unui public global. Ar fi esențial să ne asigurăm că baza noastră de cod ar putea suporta mai multe locații (limbă, regiune sau combinație a celor două) fără a fi nevoie să le codificăm personalizat pe fiecare, permițând în același timp ca traducerea să se realizeze cu cât mai puține cunoștințe ale sistemului respectiv, ar fi esențială. asta se intampla. Creatorii noștri de conținut trebuiau să se poată concentra pe crearea de conținut, iar traducătorii noștri pe traducerea conținutului, cu cât mai puțină muncă posibilă pentru a-și introduce munca pe site și implementată. Obținerea corectă a acestor seturi de nevoi, uneori conflictuale, este esenta a ceea ce este nevoie pentru a internaționaliza bazele de cod și pentru a localiza site-urile.

Internaționalizarea (i18n) și localizarea (l10n) sunt două fețe ale aceleiași monede. Internaționalizarea se referă la modul în care, în cazul nostru, software-ul este proiectat astfel încât să poată fi adaptat pentru mai multe limbi și regiuni fără a fi nevoie de modificări de inginerie. Localizarea, pe de altă parte, se referă la adaptarea efectivă a software-ului pentru acele limbi și regiuni. Internaționalizarea poate avea loc în întreaga stivă de site-uri web; de la HTML, CSS și JS la considerente de proiectare și construirea de sisteme. Localizarea are loc mai ales în crearea de conținut (atât copie în formă lungă, cât și microcopie) și management.

Notă : Pentru cei curioși, i18n și l10n sunt tipuri de abrevieri cunoscute sub numele de numeronime. A11y, pentru accesibilitate, este un alt numeronim comun în dezvoltarea web.

Internaționalizare (i18n)

Când îți dai seama de internaționalizare, în general există trei elemente pe care trebuie să le iei în considerare: cum să-ți dai seama ce limbă și/sau regiune dorește utilizatorul, cum să te asiguri că primește conținut în localizarea preferată și cum să-ți adaptezi site-ul pentru a se adapta la acele diferențe. În timp ce specificul implementării se poate modifica pentru site-urile dinamice (care redă o pagină atunci când un utilizator o solicită) și site-urile statice (unde sunt create paginile înainte de a fi implementate), conceptele de bază ar trebui să rămână aceleași.

Determinarea limbii și regiunii utilizatorului

Primul lucru pe care trebuie să îl luați în considerare atunci când înțelegeți internaționalizarea este să determinați cum doriți ca utilizatorii să acceseze conținutul localizat. Această decizie va deveni fundamentală pentru modul în care configurați alte sisteme, așa că este important să decideți acest lucru din timp și să vă asigurați că compromisurile funcționează bine pentru utilizatorii dvs.

În general, există trei modalități de nivel înalt de a determina ce localizare să fie oferită utilizatorilor:

1. Locație de la adresa IP;
2. Accept-Language antet sau navigator.languages ​​;
3. Identificator în URL.

Multe sisteme ajung să combină unul, doi sau toate trei atunci când decid ce locație să servească. Totuși, pe măsură ce investigam, am găsit probleme cu utilizarea adreselor IP și a antetelor Accept-Language care le-am considerat suficient de importante pentru a le elimina din considerare pentru noi:

• Limba preferată a unui utilizator adesea nu se corelează cu locația fizică pe care o furnizează adresa IP. Doar pentru că cineva se află fizic în America, de exemplu, nu înseamnă că ar prefera conținut în limba engleză.
• Analiza locației din adresele IP este dificilă, în general nesigură și poate împiedica accesarea cu crawlere a site-ului de către motoarele de căutare.
• Antetele Accept-Language nu sunt adesea setate în mod explicit și oferă doar informații despre limbă, nu despre regiune. Din cauza limitărilor sale, acest lucru poate fi util pentru a stabili o presupunere inițială despre limbaj, dar nu este neapărat de încredere.

Din aceste motive, am decis că ar fi mai bine pentru noi să nu încercăm să deducem limba sau regiunea înainte ca un utilizator să ajungă pe site-ul nostru, ci mai degrabă să avem indicatori puternici în adresele URL. Având indicatori puternici, de asemenea, ne permite să presupunem că primesc site-ul în limba pe care o doresc numai din adresa URL de acces, oferă o modalitate ușoară de a partaja conținutul localizat direct, fără a avea grija de redirecționare și oferă o modalitate curată de a permite utilizatorii își schimbă limba preferată.

Există trei modele comune pentru crearea identificatorilor în adrese URL:

1. Furnizați domenii diferite (de obicei TLD-uri sau subdomenii pentru diferite regiuni și limbi (de exemplu, example.com și example.de , en.example.org și de.example.org );
2. Să aibă subdirectoare localizate pentru conținut (de ex. example.com/en și example.com/de );
3. Difuzați conținut localizat pe baza parametrilor URL (de exemplu, example.com?loc=en și example.com?loc=de ).

Deși sunt utilizați în mod obișnuit, parametrii URL nu sunt, în general, recomandați, deoarece utilizatorilor le este dificil să recunoască localizarea (împreună cu o serie de probleme de analiză și management). De asemenea, am decis că diferitele domenii nu sunt o soluție bună pentru noi; site-ul nostru este o aplicație web progresivă și fiecare domeniu, inclusiv TLD-urile și subdomeniile, sunt considerate o origine diferită, necesitând efectiv un PWA separat pentru fiecare localizare.

Am decis să folosim subdirectoare, care ne-au oferit un bonus de a putea localiza numai pe limbă ( example.com/en ) sau limbă și regiune ( example.com/en-US și example.com/en-GB ) după cum este necesar menținerea unui singur PWA. De asemenea, am decis că fiecare localizare a site-ului nostru va locui într-un subdirector, astfel încât o limbă să nu fie ridicată deasupra alteia și că toate adresele URL, cu excepția subdirectorului, să fie identice în toate localizările bazate pe limba de creație, permițând utilizatorilor să schimbe cu ușurință. localizări fără a fi nevoie să traduceți adrese URL.

Difuzarea de conținut localizat

Odată ce a fost stabilită o strategie pentru determinarea limbii și a regiunii unui utilizator, aveți nevoie de o modalitate de a le oferi în mod fiabil conținutul potrivit. Cel puțin, aceasta va necesita o anumită formă de informații stocate, fie într-un cookie, un anumit spațiu de stocare local sau o parte din logica personalizată a aplicației dvs. Capacitatea de a păstra preferințele de localizare ale unui utilizator este o parte importantă a experienței utilizatorului i18n; dacă un utilizator a identificat că dorește conținut în germană și aterizează pe conținut în limba engleză, ar trebui să puteți identifica limba preferată și să-l redirecționați în mod corespunzător. Acest lucru se poate face pe server, dar soluția cu care am mers pentru chromeOS.dev este găzduirea și configurarea serverului agnostică: am folosit lucrători de service. Călătoria utilizatorului este după cum urmează:

• Un utilizator vine pentru prima dată pe site-ul nostru. Lucrătorul nostru de service nu este instalat.
• Indiferent de localizarea pe care aterizează, am stabilit-o ca limbă preferată în IndexedDB. Pentru aceasta, presupunem că aterizează acolo prin anumite mijloace, fie sociale, de referință sau de căutare, care i-au direcționat pe alte contexte de localizare pe care nu le avem. Dacă un utilizator ajunge fără un set de localizare, îl setăm la engleză, deoarece aceasta este limba principală a site-ului nostru. Avem, de asemenea, un comutator de limbă în subsolul nostru pentru a permite unui utilizator să-și schimbe limba. În acest moment, lucrătorul nostru de service ar trebui să fie instalat.
• După ce lucrătorul de service este instalat, interceptăm toate solicitările URL pentru navigarea pe site. Deoarece localizările noastre se bazează pe subdirectoare, putem identifica cu ușurință ce localizare este solicitată. Odată identificată, verificăm dacă pagina solicitată se află într-un subdirector localizat, verificăm dacă subdirectorul localizat se află într-o listă de localizări acceptate și verificăm dacă subdirectorul localizat se potrivește cu preferințele lor stocate în IndexedDB. Dacă nu se află într-un subdirector localizat sau subdirectorul localizat se potrivește cu preferințele lor, vom servi pagina; altfel facem o redirecționare 302 de la lucrătorul nostru de service pentru localizarea corectă.

Am inclus soluția noastră în pluginul Workbox, Service Worker Internationalization Redirect. Pluginul, împreună cu sub-modulul de preferințe, poate fi combinat pentru a seta și a obține preferința de limbă a unui utilizator și pentru a gestiona redirecționarea atunci când este combinat cu metoda registerRoute de la Workbox și cu cererile de filtrare la request.mode === 'navigate' .

Un exemplu complet, minimal arată astfel:

Cod client

 import { preferences } from 'service-worker-i18n-redirect/preferences'; window.addEventListener('DOMContentLoaded', async () => { const language = await preferences.get('lang'); if (language === undefined) { preferences.set('lang', lang.value); // Language determined from localization user landed on } });

Codul lucrătorului de serviciu

 import { StaleWhileRevalidate } from 'workbox-strategies'; import { CacheableResponsePlugin } from 'workbox-cacheable-response'; import { i18nHandler } from 'service-worker-i18n-redirect'; import { preferences } from 'service-worker-i18n-redirect/preferences'; import { registerRoute } from 'workbox-routing'; // Create a caching strategy const htmlCachingStrategy = new StaleWhileRevalidate({ cacheName: 'pages-cache', plugins: [ new CacheableResponsePlugin({ statuses: [200], }), ], }); // Array of supported localizations const languages = ['en', 'es', 'fr', 'de', 'ko']; // Use it for navigations registerRoute( ({ request }) => request.mode === 'navigate', i18nHandler(languages, preferences, htmlCachingStrategy), );

Cu combinația dintre codul clientului și codul de serviciu, localizarea preferată a utilizatorilor va fi setată automat atunci când accesează site-ul prima dată și, dacă navighează la o adresă URL care nu se află în localizările lor preferate, vor fi redirecționat.

Adaptarea interfeței utilizator a site-ului

Există o mulțime de lucruri care merg în adaptarea corectă a interfețelor cu utilizatorul, așa că, deși nu totul va fi acoperit aici, există o mână de lucruri mai subtile care pot și ar trebui gestionate programatic.

Citate blockquote

Un model obișnuit de design este acela de a avea ghilimele blocate între ghilimele, dar știați că ce se folosește pentru acele ghilimele diferă în funcție de localizare? În loc de codificare, folosiți open-quote close-quote pentru a vă asigura că sunt folosite ghilimele corecte pentru limba corectă.

Format de dată și număr

Atât datele, cât și numerele au o metodă, .toLocaleString pentru a permite formatarea bazată pe o localizare (limbă și/sau regiune). Browserele care le acceptă sunt livrate cu toate localizările disponibile, făcându-l ușor de utilizat acolo, dar Node.js nu. Din fericire, modulul full-icu pentru Node vă permite să utilizați toate datele de localizare disponibile. Pentru a face acest lucru, după instalarea modulului, rulați codul cu variabila de mediu NODE_ICU_DATA setată la calea către modul, de exemplu NODE_ICU_DATA=node_modules/full-icu .

Metainformații HTML

Există trei zone în eticheta și antetele dvs. HTML care ar trebui actualizate cu fiecare localizare:

• Limba paginii,
• Direcția de scriere,
• Limbi alternative în care pagina este disponibilă.

Primul care accesează elementul html cu proprietățile dir și, respectiv, lang , de exemplu <html lang="en" dir-"ltr"> pentru engleza SUA. Setarea corectă a acestora va asigura fluxul de conținut în direcția corectă și poate permite browserelor să înțeleagă în ce limbă este pagina, permițând funcții suplimentare, cum ar fi traducerea conținutului. De asemenea, ar trebui să includeți linkuri rel="alternate" pentru a informa motoarele de căutare că o pagină a fost tradusă complet, astfel încât includerea <link href="/es" rel="alternate" hreflang="es"> pe pagina noastră de destinație în limba engleză va informați motoarele de căutare că aceasta are o traducere pe care ar trebui să o caute.

Design intrinsec

Localizarea conținutului poate prezenta provocări de design, deoarece traducerile diferite vor ocupa o cantitate variată de spațiu pe pagină. Unele limbi, cum ar fi germana, au cuvinte mai lungi care necesită mai mult spațiu orizontal sau o împachetare a textului mai îngăduitoare. Alte limbi, cum ar fi arabă, au caractere mai înalte care necesită mai mult spațiu vertical. Din fericire, există o serie de instrumente CSS pentru a face spațierea și aspectul să răspundă nu doar la dimensiunea ferestrei de vizualizare, ci și la conținut, ceea ce înseamnă că se adaptează mai bine la mai multe limbi.

Există o serie de unități CSS concepute special pentru lucrul cu conținut. Există unitățile em și rem care reprezintă dimensiunea fontului calculată și, respectiv, dimensiunea fontului rădăcină. Schimbarea valorilor px de dimensiune fixă ​​pentru aceste unități poate contribui în mare măsură la a face un site mai receptiv la conținutul său. Apoi este unitatea ch , reprezentând dimensiunea în linie a glifului 0 (zero) într-un font. Acest lucru vă permite să legați lucruri precum width , de exemplu, direct de conținutul pe care îl conține.

Aceste unități pot fi apoi combinate cu instrumente CSS existente și puternice pentru aspect, în special flexbox și grid, la componente care se adaptează la dimensiunea lor, iar layout-urile se adaptează la conținutul lor. Îmbunătățirea celor cu proprietăți logice pentru chenare, margini și umplutură în loc de proprietăți fizice fizice face ca acele aspecte și componente să se adapteze automat și la modul de scriere. Puterea designului web intrinsec (inventat de Jen Simmons, unități care știe conținutul și proprietăți logice permite ca interfețele să fie proiectate și construite astfel încât să se poată adapta la orice limbă, nu la orice dimensiune a ecranului.

Localizare (l10n)

Cea mai evidentă formă pe care o ia localizarea este traducerea conținutului dintr-o limbă în alta. În forme mai subtile, traducerile au loc nu numai în funcție de limbă, ci și de regiunea în care este vorbită, de exemplu, engleza vorbită în americană versus engleza vorbită în Regatul Unit, Africa de Sud sau Australia. Pentru a avea succes aici, este esențial să înțelegeți ce să traduceți și cum să vă structurați conținutul pentru traducere.

Strategia de conținut

Există unele părți ale unui proiect software care sunt importante de localizat și altele care nu. Numele claselor CSS, variabilele JavaScript și alte locuri din baza de cod care sunt structurale, dar nu sunt orientate către utilizator, probabil că nu trebuie să fie localizate. Înțelegerea a ceea ce trebuie localizat și a modului de structurare a acestuia se rezumă la strategia de conținut.

Strategia de conținut are o mulțime de definiții, dar aici înseamnă structura conținutului, microcopie (cuvintele și frazele folosite în cadrul unui proiect care nu sunt legate de un anumit conținut) și conexiunile dintre acestea. Pentru informații mai detaliate despre strategia de conținut, aș recomanda Content Strategy for Mobile de Karen McGrane și Designing Connected Content de Carrie Hane și Mike Atherton.

Pentru chromeOS.dev, am ajuns să codificăm modele de conținut care descriu structura conținutului nostru. Modelele de conținut nu sunt doar pentru conținut de tip articol lung; ar trebui să existe un model de conținut pentru orice entitate pe care un utilizator o poate dori în mod special de la tine, cum ar fi un autor, un document sau chiar materiale media reutilizabile. Modelele de conținut bune includ bucăți care pot fi adresate individual sau fragmente ale unei piese conceptuale mai mari, excluzând în același timp părțile care sunt legate tangențial sau care pot fi referite dintr-un alt model de conținut. De exemplu, un model de conținut pentru o postare de blog poate include un titlu, o serie de etichete, o referință la un autor, data publicării și corpul postării, dar nu ar trebui să includă șirul pentru breadcrumbs sau numele și imaginea autorului, care ar trebui să fie propriul model de conținut. Modelele de conținut nu se schimbă de la localizare la localizare; sunt structura site-ului. O instanță a unui model de conținut este legată de o localizare, iar acele instanțe pot fi localizate.

Cu toate acestea, modelele de conținut acoperă doar o parte din ceea ce trebuie localizat. Restul - butoanele dvs. „Citiți mai multe”, titlul „Meniu”, textul de declinare a răspunderii – toate acestea sunt microcopie. Microcopie are nevoie de structură, de asemenea. În timp ce modelele de conținut pot fi create natural, în special pentru site-urile bazate pe șabloane, modelele de microcopiere tind să fie mai puțin evidente și sunt adesea trecute cu vederea accidental prin scrierea a ceea ce este necesar direct într-un șablon.

Prin construirea de conținut și modele de microcopiere și prin aplicarea acestora - printr-un sistem de management al conținutului, prin liniște sau revizuire - vă puteți asigura că localizarea se poate concentra pe localizare.

Localizați valori, nu chei

Modelele de conținut și de microcopie generează de obicei structuri asemănătoare obiectelor dintr-o bază de cod; fie că este vorba de intrări în baza de date, obiect JSON, YAML sau Front Matter. Nu localizați cheile obiectelor! Dacă aveți microcopie text de căutare localizată într-un obiect de microcopy la microcopy.search.text , nu o puneți într-un obiect de microcopie la microcopie.chercher.texte . Cheile din module ar trebui tratate ca identificatori agnostici de localizare, astfel încât să poată fi utilizate în mod fiabil în șabloane reutilizabile și să se poată baza pe o bază de cod. Aceasta înseamnă, de asemenea, că cheile obiectelor nu ar trebui să fie afișate utilizatorilor finali ca conținut sau microcopie.

Configurare statică a site-ului

Pentru chromeOS.dev, am folosit Eleventy (11ty) cu Nunjucks ca generator de site-uri static, dar aceste recomandări pentru configurarea unui generator de site-uri static ar trebui să fie aplicabile pentru majoritatea generatoarelor de site-uri statice. Acolo unde ceva este specific de 110, acesta va fi chemat.

Structura folderului

Generatoarele statice de site care se compilează pe baza structurii de foldere sunt deosebit de bune pentru a suporta metoda subdirectorului i18n. 11ty acceptă, de asemenea, o cascadă de date cu date globale și un mijloc de a genera pagini din date prin paginare, astfel încât combinarea acestor trei concepte generează o structură de bază a folderelor care arată astfel:

 . └── pages ├── _data ├── _generated └── {{locale-code}} ├── {{locale-code}}.11tydata.js ├── _data └── [...content]

La un nivel superior, există un director pentru a păstra paginile unui site, numit aici pages . Imbricat în interior, există un folder _data care conține fișiere de date globale. Acest folder este important atunci când vorbim despre ajutoare în continuare. Apoi, există un folder _generated . Avem o serie de pagini care, în loc să aibă propriul conținut, sunt generate din conținutul existent, cantități mici de microcopie sau o combinație a ambelor. Gândiți-vă acasă la o pagină de pornire, la o pagină de căutare sau la pagina de destinație a unei secțiuni de blog. Deoarece aceste pagini sunt foarte modelate, stocăm șabloanele în folderul _generated și le construim de acolo, în loc să avem fișiere HTML sau Markdown individuale pentru fiecare. Aceste foldere sunt prefixate cu un caracter de subliniere pentru a indica faptul că nu scot pagini direct sub ele, ci mai degrabă sunt folosite pentru a crea pagini în altă parte.

În continuare, subdirectoarele l10n! Fiecare director ar trebui să fie numit pentru eticheta de limbă BCP47 (mai frecvent, codul local) pentru localizarea pe care o conține: de exemplu, en pentru engleză sau en-US pentru engleză americană. În baza de cod chromeOS.dev, adesea ne referim la acestea și ca localități . Aceste foldere vor deveni subdirectoarele de localizare, segmentând conținutul la o localizare. Cascada de date a lui 11ty permite ca datele să fie disponibile pentru fiecare fișier dintr-un director și copiii acestuia, dacă fișierul se află la rădăcina unui director și este numit la fel ca și directorul (numit fișiere de date director). 11ty folosește un obiect returnat din acest fișier sau o funcție care returnează un obiect și îl injectează în variabilele puse la dispoziție pentru șablon, astfel încât avem acces la datele aici pentru tot conținutul acelei localizări.

Pentru a ajuta la întreținerea acestor fișiere, am scris un ajutor numit l10n-data , parte a schelei noastre statice, care profită de această structură de foldere pentru a construi o cascadă de date localizate, permițând datelor să fie localizate fragmentat. Face acest lucru prin stocarea datelor într-un director de date specific localității, directorul _data în el (încărcat în fișierul de date director). Dacă vă uitați în directorul nostru de date locale în limba engleză, de exemplu, veți vedea modele de microcopiere precum locale.json , care definește codul limbii și direcția de scriere, care vor fi apoi redate în HTML, newsletter.yml , care definește microcopia necesară pentru înscrierea la buletin informativ și un fișier microcopy.yml care include o microcopie generală utilizată în mai multe locuri de pe site, care nu se încadrează într-un fișier mai specific. Oriunde este folosită oricare dintre aceste microcopii, o extragem din aceste date puse la dispoziție prin injectarea a 110 de variabile de date în șabloanele noastre pentru a le folosi.

Microcopie tinde să fie cel mai greu de gestionat, în timp ce restul conținutului este în mare parte simplu. Puneți conținutul dvs., adesea fișiere Markdown sau HTML, în subdosarul localizat. Pentru generatorii de site-uri statice care lucrează cu structura de foldere, numele fișierului și structura de foldere a conținutului se vor mapa de obicei 1:1 la adresa URL finală pentru acel conținut, astfel încât un fișier Markdown la en/web/pwas.md va fi afișat la o adresă URL en/web/pwa . Urmând principiul nostru de localizare „valori, nu chei”, am decis că nu vom localiza numele fișierelor de conținut (și, prin urmare, căile), făcându-ne mai ușor să ținem evidența stării de localizare a aceluiași fișier în diferite locații și pentru ca utilizatorii să știe. sunt pe pagina potrivită între diferite locații.

I18n Ajutoare

Pe lângă conținut și microcopie, am constatat că trebuie să scriem o serie de module de ajutor pentru a face lucrul cu conținut localizat mai ușor. 11ty are un concept numit filtru care permite modificarea conținutului înainte de a fi randat. Am ajuns să construim patru dintre ele pentru a ajuta la modelarea i18n.

Primul este un filtru de dată. Am standardizat ca toate datele din conținutul nostru să fie scrise ca valoare de dată YAML, deoarece le scriem în mare parte în YAML și devin disponibile în șabloanele noastre ca marcaj de timp UTC complet. Când utilizați modulul full-icu și configurația, șirul de date (conținutul în curs de schimbare), împreună cu codul local pentru conținutul redat, poate fi transmis direct la Date.toLocaleString (cu opțiuni de formatare opționale) pentru a reda o dată localizată. Date.toLocaleDateString poate fi utilizat opțional în schimb dacă doriți doar porțiunea de dată când nu sunt transmise opțiuni de formatare, în locul datei și orei complet localizate.

Al doilea filtru este ceva pe care l-am numit localURL . Aceasta necesită o adresă URL locală (conținutul în curs de modificare) și locația în care ar trebui să fie adresa URL și le schimbă. Se schimbă, de exemplu, /en/linux în /es/linux .

Ultimele două filtre sunt despre preluarea informațiilor localizate numai din codul local. Al treilea folosește modulul iso-639-10 pentru a transforma un cod local într-un nume de limbă în limba maternă. Acesta îl folosim în principal pentru selectorul nostru de limbi. Al patrulea folosește modulul iso-i18n-countries pentru a prelua o listă de țări în limba respectivă. Acesta îl folosim în principal pentru a construi formulare cu liste de țări.

Pe lângă filtre, 11ty are un concept numit colecții, care este o grupare de conținut. 11ty pune la dispoziție un număr de colecții în mod implicit și poate chiar să construiască colecții din etichete. Într-un site multilingv, am descoperit că dorim să construim colecții personalizate. Am ajuns să construim o serie de funcții de ajutor pentru a construi colecții bazate pe localizare. Acest lucru ne permite să facem lucruri cum ar fi să avem colecții de etichete specifice locației sau colecții de secțiuni de site fără a fi nevoie să filtram șabloanele noastre împotriva întregului conținut de pe site-ul nostru.

Ultimul și cel mai important ajutor al nostru au fost datele globale ale site-ului nostru. Bazându-se pe structura subdirectoarelor bazată pe codul local, această funcție determină dinamic ce localizări acceptă site-ul. Acesta creează o variabilă globală, site , care include proprietatea l10n , care conține tot conținutul specific de microcopie și localizare din {{locale-code}}.11tydata.js . Conține, de asemenea, o proprietate de languages care listează toate localurile disponibile ca o matrice. În cele din urmă, funcția emite un fișier JavaScript care detaliază ce limbi sunt acceptate de site și fișiere individuale pentru fiecare intrare în {{locale-code}}.11tydata.js , introdus pe localizare, toate concepute pentru a fi importate de scripturile browserului nostru. Greutatea acestui fișier leagă site-ul nostru static de JavaScript-ul nostru front-end, singura sursă de adevăr fiind informațiile de localizare de care avem deja nevoie. De asemenea, ne permite să generăm în mod programatic pagini pe baza localizărilor noastre prin bucla peste site.l10n . Acest lucru, combinat cu colecțiile noastre specifice pentru localizare, ne permite să folosim paginarea lui 11ty pentru a crea pagini de destinație de acasă și de știri localizate, fără a menține pagini HTML separate pentru fiecare.

Concluzie

Internaționalizarea și localizarea corectă poate fi dificilă; înțelegerea modului în care diferitele strategii și afectează complexitatea este esențială pentru a face acest lucru mai ușor. Alegeți o strategie i18n care se potrivește firesc pentru site-uri statice, subdirectoare, apoi construiți instrumente pe baza acesteia pentru a automatiza părți ale i18n și i10n din conținutul produs. Creați conținut robust și modele de microcopiere. Folosiți lucrătorii de servicii pentru localizare independentă de server. Leagă totul împreună cu un design care răspunde nu doar la dimensiunea ecranului, ci și la conținut. În cele din urmă, veți avea un site pe care utilizatorii dvs. din toate locațiile îl vor adora și care poate fi întreținut de autori și traducători ca și cum ar fi un simplu site cu o singură localitate.