L’introduzione del nuovo editor ha modificato molti dei meccanismi non solo di utilizzo ma anche di sviluppo su WordPress, e tra di questi l’internazionalizzazione Gutenberg, ovvero quel processo grazie il quale determinate stringhe presenti all’interno del CMS possono essere tradotte nelle varie lingue installate e supportate dal nostro sito.
Ma facciamo un salto nel passato, prima di Gutenberg lo sviluppatore WordPress era abituato ad utilizzare il comando: load_theme_textdomain( 'domain' ); per caricare i file .mo contenenti le stringhe di traduzione, per poi andarle a richiamare attraverso la sintassi _e( 'String to translate', 'domain' ) per poterla visualizzare (ed eventuali funzioni alternative come __ per l’utilizzo nelle stringhe ad esempio o _n per i plurali). Questi due meccanismi non sono cambiati con Gutenberg, ma procedendo alla vecchia maniera gli eventuali file .pot generati da poEdit, eazyPo, wp-cli etc. non comprenderanno le nuove stringhe utilizzate all’interno dei file javascript. Come fare quindi?
L’internazionalizzazione di Gutenberg attraverso l’utilizzo di gettext
Per rendere il nostro file javascript traducibile dobbiamo prima di tutto utilizzare la sintassi gettext anche all’interno di essi, come fatto fino ad ora per i file php, includendo però nel file:
var __ = wp.i18n.__;
In secondo luogo andremo a dire a WordPress che questo file contiene delle stringhe da tradurre. Dovremo quindi includere, all’interno del file php di inclusione, la seguente action:
// Set translated strings.
if ( function_exists( 'wp_set_script_translations' ) ) {
wp_set_script_translations( 'domain-gutenberg', 'domain' );
}
L’hook registrerà wp_set_script_translation solo se lo script sarà già stato caricato, per cui consiglio l’utilizzo dell’hook enqueue_block_editor_assets anche in questo caso oltre che per il caricamento del javascript principale. Nell’esempio domain-gutenberg è il nome del file javascript principale, così come definito in wp_enqueue_script, mentre domain è il textdomain impostato con load_theme_textdomain (nel caso di temi) o load_plugin_textdomain (nel caso di plugin).
Fatto questo potremo passare alla creazione del nostro file .pot.
La generazione del file domain.pot
Per generare il file .pot utilizzeremo la riga di comando, se non lo avete già fatto, procedete quindi all’installazione di wp-cli.
A questo punto ci recheremo all’interno della directory del tema o del plugin e lanceremo il seguente comando:
wp i18n make-pot . languages/domain.pot
anvendo cura di sostituire “domain” con il textdomain impostato attraverso load_theme_textdomain o load_plugin_textdomain. In questo modo all’interno della directory languages verrà creato il nuovo file domain.pot comprensivo delle stringhe definite all’interno dei file javascript… ma ovviamente non è finita qui.
L’aggiornamento del file domain_it-IT.po
Carichiamo quindi il nostro file di traduzione domain_it-IT.po sul nostro editor .po preferito, aggiorniamo il catalogo dal file .pot appena generato e traduciamo le nuove stringhe provenienti dal file javascript. Il file .po sarà ora aggiornato con la traduzione delle nuove stringhe provenienti dal file javascript, potremo quindi compilare il .mo e copiarli entrambi in wp-content/languages/plugin.
La creazione del file json di traduzione
L’ultimo passaggio è quello di convertire il file delle stringhe in json. Rechiamoci quindi nella directory in cui risiede il file .po e lanciamo il seguente comando:
wp i18n make-json domain-it_IT.po --no-purge
Il sistema dovrebbe rispondere con “Success: Created 1 file.”, e non potrà passarci inosservato che il nome del nuovo file .json contiene al suo interno una stringa md5. Nessun problema, è corretto che sia così.
A questo punto il procedimento sarà concluso ed il vostro tema o il vostro plugin facente uso delle impostazioni documento di Gutenberg o di una nuova sidebar o un blocco personalizzato saranno correttamente tradotti nella lingua impostatata su WordPress.
Lascia un commento