Internazionalizzazione e localizzazione di siti statici

L'internazionalizzazione e la localizzazione sono più che scrivere i tuoi contenuti in più lingue. È necessaria una strategia per determinare quale localizzazione inviare e un codice per farlo. Devi essere in grado di supportare non solo lingue diverse, ma regioni diverse con la stessa lingua. La tua interfaccia utente deve essere reattiva, non solo alle dimensioni dello schermo, ma anche a diverse lingue e modalità di scrittura. I tuoi contenuti devono essere strutturati, fino alla microcopia nella tua interfaccia utente e al formato delle tue date, per essere adattabili a qualsiasi lingua tu gli lanci. Fare tutto questo con un generatore di siti statici, come Eleventy, può renderlo ancora più difficile, perché potresti non avere un database, ma comunque un server. Si può fare tutto, però, ma ci vuole pianificazione.

Durante la creazione di chromeOS.dev, sapevamo che dovevamo renderlo disponibile a un pubblico globale. Assicurarsi che la nostra base di codice possa supportare più impostazioni locali (lingua, regione o combinazione delle due) senza la necessità di personalizzare ciascuna di esse, consentendo al contempo di eseguire la traduzione con la minor conoscenza possibile di quel sistema, sarebbe fondamentale per rendere questo accada. I nostri creatori di contenuti dovevano essere in grado di concentrarsi sulla creazione di contenuti e i nostri traduttori sulla traduzione di contenuti, con il minor lavoro possibile per inserire il loro lavoro nel sito e distribuirlo. Rispondere a queste esigenze a volte contrastanti è il cuore di ciò che serve per internazionalizzare le basi di codice e localizzare i siti.

Internazionalizzazione (i18n) e localizzazione (l10n) sono due facce della stessa medaglia. L'internazionalizzazione riguarda il modo in cui, nel nostro caso, il software viene progettato in modo da poter essere adattato a più lingue e regioni senza la necessità di modifiche ingegneristiche. La localizzazione, d'altra parte, consiste nell'adattare effettivamente il software per quelle lingue e regioni. L'internazionalizzazione può avvenire nell'intero stack del sito web; da HTML, CSS e JS per progettare considerazioni e costruire sistemi. La localizzazione avviene principalmente nella creazione di contenuti (sia in formato lungo che in microcopia) e nella gestione.

Nota : per i curiosi, i18n e l10n sono tipi di abbreviazioni noti come numeronimi. A11y, per accessibilità, è un altro numeronimo comune nello sviluppo web.

Internazionalizzazione (i18n)

Quando si calcola l'internazionalizzazione, ci sono generalmente tre elementi che devi considerare: come capire quale lingua e/o regione desidera l'utente, come assicurarsi che ottengano i contenuti nella loro localizzazione preferita e come adattare il tuo sito per adattarsi quelle differenze. Sebbene le specifiche di implementazione possano cambiare per i siti dinamici (che eseguono il rendering di una pagina quando un utente lo richiede) e per i siti statici (in cui le pagine vengono create prima di essere distribuite), i concetti di base dovrebbero rimanere gli stessi.

Determinazione della lingua e della regione dell'utente

La prima cosa da considerare quando si calcola l'internazionalizzazione è determinare come si desidera che gli utenti accedano al contenuto localizzato. Questa decisione diventerà fondamentale per il modo in cui configuri altri sistemi, quindi è importante deciderlo in anticipo e garantire che i compromessi funzionino bene per i tuoi utenti.

In generale, esistono tre modi di alto livello per determinare quale localizzazione offrire agli utenti:

1. Posizione dall'indirizzo IP;
2. Accept-Language header o navigator.languages ​​;
3. Identificatore nell'URL.

Molti sistemi finiscono per combinarne uno, due o tutti e tre quando decidono quale localizzazione servire. Mentre stavamo indagando, tuttavia, abbiamo riscontrato problemi con l'utilizzo di indirizzi IP e intestazioni Accept-Language che ritenevamo sufficientemente significativi da non essere presi in considerazione per noi:

• La lingua preferita di un utente spesso non è correlata alla sua posizione fisica, fornita dall'indirizzo IP. Solo perché qualcuno si trova fisicamente in America, ad esempio, non significa che preferirebbe il contenuto in inglese.
• L'analisi della posizione dagli indirizzi IP è difficile, generalmente inaffidabile e può impedire che il sito venga scansionato dai motori di ricerca.
• Le intestazioni Accept-Language spesso non vengono mai impostate in modo esplicito e forniscono solo informazioni sulla lingua, non sulla regione. A causa dei suoi limiti, questo può essere utile per stabilire un'ipotesi iniziale sul linguaggio, ma non è necessariamente affidabile.

Per questi motivi, abbiamo deciso che sarebbe stato meglio per noi non provare a dedurre la lingua o la regione prima che un utente arrivi sul nostro sito, ma piuttosto avere forti indicatori nei nostri URL. Avere indicatori forti ci consente anche di presumere che stiano ricevendo il sito nella lingua che desiderano dal solo URL di accesso, fornisce un modo semplice per condividere direttamente i contenuti localizzati senza preoccuparsi del reindirizzamento e fornisce un modo pulito per consentire gli utenti cambiano la loro lingua preferita.

Esistono tre modelli comuni per la creazione di identificatori negli URL:

1. Fornire domini diversi (di solito TLD o sottodomini per regioni e lingue diverse (ad esempio example.com e example.de , en.example.org e de.example.org );
2. Disporre di sottodirectory localizzate per i contenuti (ad es. example.com/en e example.com/de );
3. Offri contenuti localizzati in base ai parametri URL (ad es. example.com?loc=en e example.com?loc=de ).

Sebbene comunemente usati, i parametri URL non sono generalmente consigliati perché è difficile per gli utenti riconoscere la localizzazione (insieme a una serie di problemi di analisi e gestione). Abbiamo anche deciso che domini diversi non erano una buona soluzione per noi; il nostro sito è una Progressive Web App e ogni dominio, inclusi TLD e sottodomini, è considerato un'origine diversa, richiedendo di fatto una PWA separata per ogni localizzazione.

Abbiamo deciso di utilizzare le sottodirectory, che ci hanno fornito un vantaggio in quanto siamo in grado di localizzare solo la lingua ( example.com/en ) o la lingua e la regione ( example.com/en-US e example.com/en-GB ) secondo necessità mentre mantenimento di un'unica PWA. Abbiamo anche deciso che ogni localizzazione del nostro sito sarebbe stata inserita in una sottodirectory in modo che una lingua non fosse superiore a un'altra e che tutti gli URL, ad eccezione della sottodirectory, sarebbero stati identici in tutte le localizzazioni in base alla lingua di creazione, consentendo agli utenti di modificare facilmente localizzazioni senza dover tradurre gli URL.

Fornitura di contenuti localizzati

Una volta determinata una strategia per determinare la lingua e la regione di un utente, è necessario un modo per offrire loro in modo affidabile il contenuto giusto. Come minimo, ciò richiederà una qualche forma di informazioni archiviate, che si tratti di un cookie, di un archivio locale o di parte della logica personalizzata dell'app. Essere in grado di mantenere le preferenze di localizzazione di un utente è una parte importante dell'esperienza utente di i18n; se un utente ha identificato che desidera contenuti in tedesco e atterra su contenuti in inglese, dovresti essere in grado di identificare la sua lingua preferita e reindirizzarli in modo appropriato. Questo può essere fatto sul server, ma la soluzione che abbiamo scelto per chromeOS.dev è indipendente dall'hosting e dalla configurazione del server: abbiamo utilizzato i service worker. Il percorso dell'utente è il seguente:

• Un utente accede al nostro sito per la prima volta. Il nostro operatore di servizio non è installato.
• Qualunque sia la localizzazione su cui atterrano, la impostiamo come lingua preferita in IndexedDB. Per questo, presumiamo che stiano arrivando lì attraverso alcuni mezzi, social, referral o ricerca, che li hanno indirizzati in base ad altri contesti di localizzazione che non abbiamo. Se un utente arriva senza un set di localizzazione, lo impostiamo sull'inglese, poiché è la lingua principale del nostro sito. Abbiamo anche un selettore di lingua nel nostro piè di pagina per consentire a un utente di cambiare la propria lingua. A questo punto, il nostro service worker dovrebbe essere installato.
• Dopo l'installazione del Service Worker, intercettiamo tutte le richieste URL per la navigazione nel sito. Poiché le nostre localizzazioni sono basate su sottodirectory, possiamo identificare prontamente quale localizzazione viene richiesta. Una volta identificata, controlliamo se la pagina richiesta si trova in una sottodirectory localizzata, se la sottodirectory localizzata è in un elenco di localizzazioni supportate e se la sottodirectory localizzata corrisponde alle loro preferenze memorizzate in IndexedDB. Se non si trova in una sottodirectory localizzata o la sottodirectory localizzata corrisponde alle loro preferenze, serviamo la pagina; in caso contrario, eseguiamo un reindirizzamento 302 dal nostro operatore di servizio per la corretta localizzazione.

Abbiamo raggruppato la nostra soluzione nel plug-in Workbox, Reindirizzamento dell'internazionalizzazione di Service Worker. Il plug-in, insieme al relativo sottomodulo delle preferenze, può essere combinato per impostare e ottenere la preferenza della lingua di un utente e gestire il reindirizzamento quando combinato con il metodo registerRoute di Workbox e filtrando le richieste su request.mode === 'navigate' .

Un esempio completo e minimo si presenta così:

Codice Cliente

 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 } });

Codice del lavoratore di servizio

 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), );

Con la combinazione del codice lato client e dell'operatore di servizio, la localizzazione preferita degli utenti verrà impostata automaticamente quando accedono al sito per la prima volta e, se accedono a un URL che non è nelle loro localizzazioni preferite, saranno reindirizzato.

Adattamento dell'interfaccia utente del sito

C'è molto da fare per adattare correttamente le interfacce utente, quindi anche se non tutto sarà trattato qui, ci sono una manciata di cose più sottili che possono e dovrebbero essere gestite a livello di codice.

Citazioni in blocco

Un modello di progettazione comune prevede le virgolette racchiuse tra virgolette, ma sapevi che cosa viene utilizzato per tali virgolette varia con la localizzazione? Invece dell'hardcoding, usa open-quote close-quote per assicurarti che le virgolette corrette vengano utilizzate per la lingua corretta.

Formato data e numero

Sia le date che i numeri hanno un metodo, .toLocaleString per consentire la formattazione in base a una localizzazione (lingua e/o regione). I browser che supportano questi vengono forniti con tutte le localizzazioni disponibili, rendendolo facilmente utilizzabile lì, ma Node.js no. Fortunatamente, il modulo full-icu per Node consente di utilizzare tutti i dati di localizzazione disponibili. Per farlo, dopo aver installato il modulo, esegui il tuo codice con la variabile di ambiente NODE_ICU_DATA impostata sul percorso del modulo, ad esempio NODE_ICU_DATA=node_modules/full-icu .

Meta-informazione HTML

Ci sono tre aree nel tag HTML e nelle intestazioni che dovrebbero essere aggiornate ad ogni localizzazione:

• La lingua della pagina,
• Direzione di scrittura,
• Lingue alternative in cui è disponibile la pagina.

Il primo ad andare sull'elemento html con le proprietà dir e lang rispettivamente, ad esempio <html lang="en" dir-"ltr"> per l'inglese americano. La corretta impostazione di questi assicurerà il flusso di contenuti nella giusta direzione e consentirà ai browser di capire in quale lingua si trova la pagina, consentendo funzionalità aggiuntive come la traduzione del contenuto. Dovresti anche includere i link rel="alternate" per far sapere ai motori di ricerca che una pagina è stata completamente tradotta, quindi includere <link href="/es" rel="alternate" hreflang="es"> sulla nostra landing page in inglese sarà fai sapere ai motori di ricerca che questo ha una traduzione che dovrebbe cercare.

Design intrinseco

La localizzazione dei contenuti può presentare problemi di progettazione poiché traduzioni diverse occuperanno una quantità variabile di spazio sulla pagina. Alcune lingue, come il tedesco, hanno parole più lunghe che richiedono più spazio orizzontale o una disposizione del testo più tollerante. Altre lingue, come l'arabo, hanno caratteri più alti che richiedono più spazio verticale. Fortunatamente, ci sono una serie di strumenti CSS per rendere la spaziatura e il layout reattivi non solo alle dimensioni del viewport, ma anche al contenuto, il che significa che si adattano meglio a più lingue.

Ci sono un certo numero di unità CSS progettate specificamente per lavorare con i contenuti. Ci sono le unità em e rem che rappresentano rispettivamente la dimensione del carattere calcolata e la dimensione del carattere radice. Lo scambio di valori px di dimensioni fisse per queste unità può fare molto per rendere un sito più reattivo al suo contenuto. Poi c'è l'unità ch , che rappresenta la dimensione inline del glifo 0 (zero) in un font. Ciò ti consente di collegare elementi come width , ad esempio, direttamente al contenuto che contiene.

Queste unità possono quindi essere combinate con i potenti strumenti CSS esistenti per il layout, in particolare flexbox e grid, a componenti che si adattano alle loro dimensioni e i layout si adattano al loro contenuto. Migliorare quelli con proprietà logiche per bordi, margini e riempimento anziché proprietà fisiche fisiche fa sì che anche i layout e i componenti si adattino automaticamente alla modalità di scrittura. La potenza del web design intrinseco (coniato da Jen Simmons, le unità sensibili al contenuto e le proprietà logiche consentono di progettare e costruire interfacce in modo che possano adattarsi a qualsiasi linguaggio, non solo a qualsiasi dimensione dello schermo.

Localizzazione (l10n)

La forma più ovvia che assume la localizzazione è tradurre il contenuto da una lingua all'altra. In forme più sottili, le traduzioni non avvengono solo in base alla lingua, ma alla regione in cui si parla, ad esempio l'inglese parlato in americano rispetto all'inglese parlato nel Regno Unito, in Sud Africa o in Australia. Per avere successo qui, capire cosa tradurre e come strutturare i tuoi contenuti per la traduzione è fondamentale per il successo.

Strategia dei contenuti

Ci sono alcune parti di un progetto software che è importante localizzare e altre no. I nomi delle classi CSS, le variabili JavaScript e altre posizioni nella tua base di codice che sono strutturali, ma non rivolte all'utente, probabilmente non hanno bisogno di essere localizzate. Capire cosa deve essere localizzato e come strutturarlo si riduce alla strategia dei contenuti.

La strategia dei contenuti ha molte definizioni, ma qui significa la struttura del contenuto, la microcopia (le parole e le frasi utilizzate durante un progetto non legate a un contenuto specifico) e le relative connessioni. Per informazioni più dettagliate sulla strategia dei contenuti, consiglierei Content Strategy for Mobile di Karen McGrane e Designing Connected Content di Carrie Hane e Mike Atherton.

Per chromeOS.dev, abbiamo finito di codificare modelli di contenuto che descrivono la struttura del nostro contenuto. I modelli di contenuto non sono solo per contenuti simili ad articoli di lunga durata; dovrebbe esistere un modello di contenuto per qualsiasi entità che un utente potrebbe desiderare specificamente da te, come un autore, un documento o persino risorse multimediali riutilizzabili. I buoni modelli di contenuto includono pezzi indirizzabili individualmente, o pezzi, di un pezzo concettuale più ampio, mentre escludono pezzi che sono correlati tangenzialmente o possono essere referenziati da un altro modello di contenuto. Ad esempio, un modello di contenuto per un post di un blog può includere un titolo, una serie di tag, un riferimento a un autore, la data di pubblicazione e il corpo del post, ma non dovrebbe includere la stringa per i breadcrumb o il il nome e l'immagine dell'autore, che dovrebbe essere il proprio modello di contenuto. I modelli di contenuto non cambiano da localizzazione a localizzazione; sono la struttura del sito. Un'istanza di un modello di contenuto è legata a una localizzazione e tali istanze possono essere localizzate.

Tuttavia, i modelli di contenuto coprono solo una parte di ciò che deve essere localizzato. Il resto, i pulsanti "Leggi di più", il titolo del "Menu", il testo della dichiarazione di non responsabilità, è tutto microcopia. Anche la microcopia ha bisogno di struttura. Sebbene la creazione di modelli di contenuto possa sembrare naturale, soprattutto per i siti basati su modelli, i modelli di microcopia tendono a essere meno ovvi e spesso vengono trascurati accidentalmente scrivendo ciò che è necessario direttamente in un modello.

Costruendo modelli di contenuto e microcopia e applicandoli, tramite un sistema di gestione dei contenuti, l'assegnazione o la revisione, sei in grado di garantire che la localizzazione possa concentrarsi sulla localizzazione.

Localizza valori, non chiavi

I modelli di contenuto e microcopia di solito generano strutture simili agli oggetti in una base di codice; che si tratti di voci di database, oggetti JSON, YAML o Front Matter. Non localizzare le chiavi degli oggetti! Se la tua microcopia del testo di ricerca si trova in un oggetto di microcopy in microcopy.search.text , non inserirla in un oggetto di microcopie in microcopie.chercher.texte . Le chiavi nei moduli devono essere trattate come identificatori indipendenti dalla localizzazione in modo che possano essere utilizzate in modo affidabile in modelli riutilizzabili e su cui fare affidamento in una base di codice. Ciò significa anche che le chiavi degli oggetti non devono essere visualizzate agli utenti finali come contenuto o microcopia.

Configurazione statica del sito

Per chromeOS.dev, abbiamo utilizzato Eleventy (11ty) con Nunjucks come generatore di siti statici, ma questi consigli per la configurazione di un generatore di siti statici dovrebbero essere applicabili alla maggior parte dei generatori di siti statici. Laddove qualcosa è specifico, verrà richiamato.

Struttura delle cartelle

I generatori di siti statici che compilano in base alla struttura delle cartelle sono particolarmente efficaci nel supportare il metodo i18n della sottodirectory. 11ty supporta anche una cascata di dati con dati globali e un mezzo per generare pagine dai dati attraverso l'impaginazione, quindi la combinazione di questi tre concetti produce una struttura di cartelle di base simile alla seguente:

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

Al livello superiore, c'è una directory per contenere le pagine di un sito, qui chiamata pages . Annidato all'interno, c'è una cartella _data contenente file di dati globali. Questa cartella è importante quando si parla di aiutanti in seguito. Quindi, c'è una cartella _generated . Abbiamo un certo numero di pagine che, invece di avere il proprio contenuto, sono generate da contenuti esistenti, piccole quantità di microcopie o una combinazione di entrambi. Pensa a una home page, una pagina di ricerca o una pagina di destinazione di una sezione del blog. Poiché queste pagine sono altamente basate su modelli, memorizziamo i modelli nella cartella _generated e li costruiamo da lì invece di avere singoli file HTML o Markdown per ciascuno. Queste cartelle sono precedute da un trattino basso per indicare che non generano pagine direttamente sotto di esse, ma vengono utilizzate per creare pagine altrove.

Quindi, le sottodirectory l10n! Ogni directory deve essere denominata per il tag della lingua BCP47 (più comunemente, codice locale) per la localizzazione che contiene: ad esempio, en per l'inglese o en-US per l'inglese americano. Nella codebase di chromeOS.dev, spesso ci riferiamo anche a questi come locali . Queste cartelle diventeranno le sottodirectory di localizzazione, segmentando il contenuto in una localizzazione. La cascata di dati di 11ty consente ai dati di essere disponibili per ogni file in una directory e per i suoi figli se il file si trova nella radice di una directory e ha lo stesso nome della directory (chiamati file di dati di directory). 11ty utilizza un oggetto restituito da questo file o una funzione che restituisce un oggetto e lo inserisce nelle variabili rese disponibili per la creazione di modelli, quindi abbiamo accesso ai dati qui per tutto il contenuto di quella localizzazione.

Per aiutare nella manutenibilità di questi file, abbiamo scritto un helper chiamato l10n-data , parte del nostro scaffolding statico del sito, che sfrutta questa struttura di cartelle per creare una cascata di dati localizzati, consentendo la localizzazione dei dati in modo frammentario. Lo fa memorizzando i dati in una directory di dati specifica per la locale, directory _data in essa (caricata nel file di dati della directory). Se guardi nella nostra directory dei dati delle impostazioni locali in inglese, ad esempio, vedrai modelli di microcopia come locale.json che definisce il codice della lingua e la direzione di scrittura che verrà quindi renderizzata nel nostro HTML, newsletter.yml che definisce la microcopia necessaria per il nostro iscrizione alla newsletter e un file microcopy.yml che include una microcopia generale utilizzata in più punti del sito che non si adatta a un file più specifico. Ovunque venga utilizzata una qualsiasi di questa microcopia, la estraiamo da questi dati resi disponibili tramite 11ty iniettando variabili di dati nei nostri modelli da utilizzare.

La microcopia tende ad essere la più difficile da gestire, mentre il resto del contenuto è per lo più semplice. Inserisci i tuoi contenuti, spesso file Markdown o HTML, nella sottocartella localizzata. Per i generatori di siti statici che funzionano sulla struttura delle cartelle, il nome del file e la struttura delle cartelle del contenuto verranno generalmente mappati 1:1 all'URL finale per quel contenuto, quindi un file Markdown su en/web/pwas.md verrebbe restituito a un URL en/web/pwa . Seguendo il nostro principio di localizzazione "valori, non chiavi", abbiamo deciso di non localizzare i nomi dei file di contenuto (e quindi i percorsi), rendendo più facile per noi tenere traccia dello stato di localizzazione dello stesso file tra le diverse impostazioni locali e per consentire agli utenti di conoscerlo sono sulla pagina giusta tra diverse località.

I18n Aiutanti

Oltre al contenuto e alla microcopia, abbiamo riscontrato la necessità di scrivere una serie di moduli di supporto per semplificare il lavoro con il contenuto localizzato. 11ty ha un concetto chiamato filtro che consente di modificare il contenuto prima di essere renderizzato. Abbiamo finito per costruirne quattro per aiutare con la creazione di modelli i18n.

Il primo è un filtro data. Abbiamo standardizzato l'avere tutte le date nel nostro contenuto scritte come valore di data YAML perché le scriviamo principalmente in YAML e diventano disponibili nei nostri modelli come timestamp UTC completo. Quando si utilizza il modulo e la configurazione full-icu , la stringa della data (contenuto modificato), insieme al codice locale per il contenuto sottoposto a rendering, possono essere passati direttamente a Date.toLocaleString (con opzioni di formattazione opzionali) per eseguire il rendering di una data localizzata. Date.toLocaleDateString può essere utilizzato facoltativamente se si desidera solo la parte della data quando non vengono passate opzioni di formattazione, anziché la data e l'ora completamente localizzate.

Il secondo filtro è qualcosa che abbiamo chiamato localURL . Questo prende un URL locale (contenuto in corso di modifica) e la locale in cui dovrebbe trovarsi l'URL e li scambia. Cambia, ad esempio, /en/linux in /es/linux .

Gli ultimi due filtri riguardano il recupero delle informazioni localizzate dal solo codice locale. Il terzo sfrutta il modulo iso-639-10 per trasformare un codice locale nel nome della lingua nella lingua madre. Questo lo usiamo principalmente per il nostro selettore di lingua. Il quarto utilizza il modulo iso-i18n-countries per recuperare un elenco di paesi in quella lingua. Questo lo utilizziamo principalmente per la creazione di moduli con elenchi di paesi.

Oltre ai filtri, 11ty ha un concetto chiamato raccolte che è un raggruppamento di contenuti. 11ty rende disponibili un certo numero di raccolte per impostazione predefinita e può persino creare raccolte a partire dai tag. In un sito multilingue, abbiamo scoperto che volevamo creare raccolte personalizzate. Abbiamo finito per creare una serie di funzioni di supporto per creare raccolte basate sulla localizzazione. Questo ci consente di fare cose come avere raccolte di tag specifiche per posizione o raccolte di sezioni del sito senza dover filtrare i nostri modelli rispetto a tutto il contenuto del nostro sito.

Il nostro ultimo e più critico aiuto sono stati i dati globali del nostro sito. Basandosi sulla struttura della sottodirectory basata sul codice locale, questa funzione determina dinamicamente quali localizzazioni supporta il sito. Crea una variabile globale, site , che include la proprietà l10n , contenente tutto il contenuto specifico della microcopia e della localizzazione da {{locale-code}}.11tydata.js . Contiene anche una proprietà delle languages che elenca tutte le impostazioni locali disponibili come un array. Infine, la funzione genera un file JavaScript che descrive in dettaglio quali lingue sono supportate dal sito e singoli file per ogni voce in {{locale-code}}.11tydata.js , digitato per localizzazione, il tutto progettato per essere importato dagli script del nostro browser. Il pesante sollevamento di questo file lega il nostro sito statico al nostro JavaScript front-end con l'unica fonte di verità che sono le informazioni sulla localizzazione di cui abbiamo già bisogno. Ci consente inoltre di generare pagine a livello di codice in base alle nostre localizzazioni eseguendo il loop su site.l10n . Questo, combinato con le nostre raccolte specifiche per la localizzazione, ci consente di utilizzare l'impaginazione di 11ty per creare home page localizzate e pagine di destinazione delle notizie senza mantenere pagine HTML separate per ciascuna.

Conclusione

Ottenere l'internazionalizzazione e la localizzazione corrette può essere difficile; capire in che modo le diverse strategie e influiscono sulla complessità è fondamentale per renderlo più semplice. Scegli una strategia i18n che si adatta perfettamente a siti statici, sottodirectory, quindi crea strumenti per automatizzare parti di i18n e i10n dal contenuto prodotto. Crea contenuti solidi e modelli di microcopia. Sfrutta i service worker per la localizzazione indipendente dal server. Collega tutto insieme a un design che risponde non solo alle dimensioni dello schermo, ma anche ai contenuti. Alla fine avrai un sito che i tuoi utenti di tutte le località adoreranno, che può essere mantenuto da autori e traduttori come se fosse un semplice sito con una sola lingua.