Questo non è solo un blog contro lo stigma su HIV, ma è un lavoro nato e cresciuto grazie alle persone della comunità WordPress che hanno condiviso la propria competenza tecnica con me. Quindi mi sento in dovere di ricambiare, mettendo a disposizione l’esperienza su come ho fatto a creare un blog multilingua senza plugin dedicati.
Primi ostacoli
Quando io e Alessandro “Gifter” abbiamo scelto WordPress per gestire il sito, pensavamo già a un blog multilingua – italiano e inglese ma abbiamo dovuto rinunciare perché nessun servizio o plugin esterno rispondeva a tutte le nostre esigenze.
Ci siamo messi a studiare WPML, Polylang, TranslatePress o altre soluzioni, ma nulla ci convinceva specialmente considerando le mie necessità di blogger con disabilità visiva e poi Gifter, che ha gli occhi funzionanti ma non ha sufficienti conoscenze tecniche per darmi davvero una mano.
Una configurazione MultiSite o una doppia installazione WordPress potevano essere due strade percorribili in alternativa, ma alla fine avrebbero portato più manutenzione e le abbiamo accantonate.
Lasciamo comunque stare i problemi, al momento sono acqua passata e preferisco dedicare la mia energia all’esperienza positiva perché WordPress, nel tempo, è migliorato sensibilmente e ci ha offerto delle possibilità che fino a poco prima non riuscivamo a immaginare.
Editor a blocchi
Presente dal 2018 solo per la gestione dei contenuti, l’editor a blocchi Gutenberg si è evoluto negli anni diventando il sistema predefinito per costruire e modificare l’intero sito web senza bisogno di saper scrivere codice.
Pur avendo molte meno funzioni rispetto ad altri prodotti già consolidati nel mondo WordPress, questo editor risponde alla mia esigenza più importante, l’accessibilità digitale – ne parlerò meglio al WordPress Accessibility Day 2024 dove ci sarà anche la persona che mi ha insegnato a progettare pagine intere usando solo i blocchi.
Blog multilingua: la struttura di base
Evito di entrare in dettaglio su come funziona l’editor a blocchi perché non è questo il focus del post, mi limito però a dire che ogni pagina o articolo su WordPress si compone del contenuto ma anche del template, cioè il “vestito” che oltre all’aspetto visivo comprende gli elementi di contorno, comuni per ogni parte di un sito web: menu, testata, piè di pagina, barre laterali…
Quindi se voglio far parlare in inglese alcuni post e pagine, la base è costruire dei template compatibili: una testata che parla in italiano l’altra in inglese, e così per ogni elemento comune – menu compreso.
Purtroppo non si possono duplicare i template quindi bisogna andare avanti col copia-incolla manuale dei singoli blocchi sul template nuovo, e relativa traduzione; operazione che, fatta una volta, è fatta per sempre.
Header-english e header-italian, sidebar-english e sidebar-italian, e così via. Con questi si costruiscono i template post-english e post-italian, page-english e page-italian, io raccomando di attribuire a ogni template dei nomi esplicativi in modo da sapere quale usare e dove.
Per i contenuti invece avremo due “home”, due “chi siamo”, due “pagina eventi”… Una su cui gira il template pagina o post italiano, l’altra quello inglese, da cambiare manualmente in fase di stesura o pubblicazione di ogni articolo o sezione.
Il flusso di lavoro è complicato? Probabile, ma l’avventura non è finita qui. D’altronde “blog multilingua gratuito senza plugin” va poco d’accordo con “semplicità”, sta al blogger scegliere se investire i soldi o il tempo e la pazienza. Io e Gifter abbiamo scelto la seconda opzione.
La sfida continua
Per gestire il multilingua in modo coerente italiano e inglese devono avere ciascuno le proprie categorie e, se possibile, anche tag. Noi abbiamo deciso di chiamarle “italian” e “international” e gli articoli verranno pubblicati in una categoria o l’altra a seconda della lingua in cui sono scritti.
Successivamente arriva la fase più delicata: ogni sezione va gestita con un blocco potentissimo, “Query Loop”.
Il suo ruolo è filtrare i contenuti a seconda di criteri stabiliti nelle impostazioni del blocco stesso: filtro per autore, categorie, tag, post personalizzati o addirittura parole chiave. E nel caso in cui si abbiano (come nel nostro blog) storie a puntate, si può istruire il blocco a visualizzare i titoli in ordine alfabetico.
Quindi mi sono impegnata a impostare i Query Loop da Italian sulle pagine italiane e da International sull’inglese, in modo che non si crei confusione nell’archiviazione dei contenuti.
Ricerca, pagina di errore e archivi
I template funzionavano, i contenuti erano organizzati ma alcune condizioni creavano problemi:
- la ricerca forniva risultati in italiano e inglese, intestazione e piè pagina erano in italiano. Confusione per i lettori.
- La pagina di errore (404 pagina non trovata) era in italiano.
- gli archivi (autore, categorie e tag) avevano il template standard in italiano e non c’era verso di farli funzionare in inglese.
Per il motore di ricerca abbiamo chiesto a uno sviluppatore esterno che ci ha fornito un codice in grado di filtrare i risultati a seconda dei template: se la pagina è italiana mostra solo risultati in italiano, se è in inglese solo l’inglese.
Poi per gli errori di “pagina non trovata” ho usato una “intelligenza artificiale” che mi ha creato alcune righe di codice secondo le istruzioni che gli ho fornito:
Crea un plugin WordPress che gestisca le pagine 404: se la lingua del browser è italiana trasferiscimi sulla pagina 404-it, se la lingua del browser è diversa portami su 404-en.
Su ciascuna delle soluzioni ho anche aggiunto un’istruzione che cambiasse la lingua di WordPress dipendentemente da quella dei post, in quanto lasciare quella preimpostata significava che le voci artificiali leggessero i contenuti in italiano se erano in inglese, o viceversa.
Potevo io, web creator con disabilità visiva, consentire che il mio stesso blog si portasse dietro un errore di accessibilità così grave? Il calzolaio con le scarpe rotte, anche no. Allora ho creato, sempre con l’aiuto del chatbot, altri script per controllare l’autore e la categoria del post, e la lingua dell’interfaccia.
Nel tempo mi sono accorta che se lato utente gli errori venivano mostrati nella lingua giusta, il sistema di monitoraggio malfunzionamenti non li contava. Niente da fare, modo o maniera andava cambiato tutto.
Invece sugli archivi delle categorie e tag avevo perso la speranza, tanto da compiere una scelta drastica: evitare di mostrarli come link negli articoli e togliere le tassonomie dall’indicizzazione sui motori di ricerca, così da scongiurare ogni tipo di inconveniente.
IntelliBuilder e gli shortcode
Chiudere una falla e crearne quattro, situazione decisamente infelice. Per invertire quella tendenza ho cercato per giorni un plugin di blocchi “condizionati”: mostra o nascondi uno o più blocchi se si verifica questo o quell’evento.
Intelli-Builder era uno di questi e sembrava soddisfare l’esigenza: se il browser è di una lingua, mostra o nascondi il contenuto.
Anche questa volta però le prove sul campo hanno fallito e mi stavo arrendendo all’evidenza di un problema senza soluzione, finché è accaduta una fortunata coincidenza.
Per lavoro leggevo alcune righe di codice e ho notato delle analogie tra il programma che avevo in mano e gli shortcode, un metodo usato da WordPress per modificare “al volo” il comportamento di un post, aggiungendo o eliminando contenuto.
Anche in questo caso mi sono messa al tavolo con la cosiddetta “intelligenza artificiale” e ho iniziato a inviare domande:
- conosci gli shortcode di WordPress?
- Sai creare un plugin che nasconda il contenuto in presenza di uno shortcode?
- Posso verificare la lingua del browser con lo shortcode? E cambiare la lingua di WordPress?
- Crea un plugin che registri due shortcode, “ita” ed “eng”: il contenuto racchiuso in Ita deve essere mostrato se la lingua del browser è italiana e devi mettere WordPress in italiano. Quello racchiuso in “eng” deve essere visibile se il browser parla una lingua diversa da italiano, e devi cambiare la lingua di WordPress in inglese.
- L’ultima fase: aggiungere un parametro wp=”1″ (predefinito) che insieme al contenuto che viene mostrato, cambia la lingua di WordPress. Se WP=”0″ si limita a far vedere o nascondere il contenuto, senza cambiare la lingua di WordPress.
Questi shortcode sembrano aver risolto i problemi di incoerenza linguistica, quindi gradualmente verranno usati nelle pagine archivio e quella di errore.
Conclusione
WordPress multilingua gratuito senza plugin? Obiettivo parzialmente raggiunto. C’è voluto un paio di personalizzazioni nel codice e le ho inserite come plugin per comodità mia, ma volendo si può installare un componente che si chiama WpCode e copiare il generatore di shortcode direttamente lì.
Gratis? Parlando di soldi tradizionali, né io né Gifter abbiamo speso un centesimo; ma volessimo quantificare in euro il tempo impiegato a cercare, studiare e sperimentare anche rischiando di perdere tutto? Il WordPress multilingua senza plugin ci sarebbe costato miliardi e siamo orgogliosi di tirarli fuori. Soprattutto io che nemmeno pensavo più di avere così tanto tempo e pazienza nel portafoglio.
Lascia un commento