# Traduzioni Blockstudio include le proprie traduzioni nella cartella `languages`. WordPress le usa quando la lingua del sito o quella del profilo utente corrisponde a una di esse. Il funzionamento è lo stesso se Blockstudio viene eseguito come plugin, plugin obbligatorio o pacchetto Composer. ## Lingue disponibili Blockstudio include traduzioni per le lingue WordPress registrate nel suo `languages/locales.json` incluso, comprese le varianti regionali e formali/informali. L’inglese (`en_US`) è la lingua sorgente e non richiede un file di traduzione. L’elenco combina le lingue supportate da WordPress in GlotPress con le varianti disponibili nella traduzione del core WordPress API. Le traduzioni esistenti in tedesco (`de_DE`) e in tedesco formale (`de_DE_formal`) sono state mantenute. Le traduzioni aggiuntive sono state generate con l’IA usando GPT-6 Luna e contrassegnate come generate automaticamente nelle intestazioni `.po`. Superano i controlli automatici di completezza e formato, ma non sono state tutte revisionate da madrelingua. Le correzioni sono benvenute. Le traduzioni includono i controlli dei campi nell’editor a blocchi, la pagina di amministrazione, la tela, la sovrapposizione degli strumenti di sviluppo e i messaggi degli endpoint REST. Le etichette e i testi di aiuto nei vostri file `block.json` appartengono al vostro tema o plugin e usano il relativo dominio di testo. Selezionate la lingua in **Impostazioni > Generali > Lingua del sito** oppure scegliete una lingua personale nel vostro profilo WordPress. Blockstudio usa automaticamente la lingua selezionata. Non aggiunge lingue al selettore della lingua di WordPress: una lingua deve essere disponibile anche nella vostra installazione di WordPress. Sul vostro sito non sono necessarie richieste all’IA, abbonamenti per le traduzioni o impostazioni aggiuntive di runtime. ## Sostituire una traduzione I file di traduzione in `wp-content/languages/plugins` hanno la precedenza su quelli inclusi, sia per le stringhe PHP (`blockstudio-de_DE.mo` o `blockstudio-de_DE.l10n.php`) sia per gli script (un file per ogni handle di script, ad esempio `blockstudio-de_DE-blockstudio-blocks.json`). ## Contribuire a una traduzione Ogni lingua è un file `.po` che potete modificare con qualsiasi editor di testo o con uno strumento di traduzione come Poedit. Correzioni e nuove traduzioni sono benvenute tramite pull request. 1. Per aggiungere una lingua, copiate `languages/blockstudio.pot` in `languages/blockstudio-.po`, ad esempio `blockstudio-fr_FR.po`, e impostate le intestazioni `Language` e `Plural-Forms`. Per migliorare una lingua, modificate il relativo file `.po` esistente. 2. Traducete le stringhe. Mantenete nella traduzione i segnaposto come `%1$s`. 3. Eseguite `npm run i18n`. Il comando genera i file `.mo`, `.l10n.php` e `.json` che WordPress carica. 4. Includete il file `.po` insieme ai file generati nel commit e aprite una pull request. Se non potete eseguire `npm`, potete aprire una pull request contenente solo il file `.po`. I file generati possono essere aggiunti prima del merge. ## Generare le traduzioni mancanti Chi mantiene il progetto può generare le voci mancanti con un Codex CLI autenticato. È un comando di sviluppo facoltativo, che WordPress non esegue: ```bash npm run i18n:translate -- --dry-run npm run i18n:translate ``` Il modello predefinito è `gpt-6-luna`. Per lavorare su una lingua, usate `npm run i18n:translate -- --locale fr_FR`. Il comando estrae le stringhe sorgente più recenti, completa le traduzioni mancanti e poi compila i file `.mo`, `.l10n.php` e `.json` per ogni script. A Codex vengono inviati solo le stringhe dell’interfaccia pubblica, il relativo contesto e le forme esistenti, non i contenuti del sito o i dati degli utenti. Le traduzioni esistenti e non vuote non vengono mai sostituite. I gruppi completati vengono salvati, quindi eseguendo di nuovo il comando dopo un’interruzione si riprende il lavoro mancante. Prima del salvataggio vengono convalidati segnaposto come `%1$s`, il markup HTML, gli identificatori tecnici e le forme plurali richieste. Le voci contrassegnate come fuzzy e i plurali sorgente modificati sono lasciati alla revisione di un traduttore. Se il modello richiesto non è disponibile, non viene usato un modello alternativo. `npm run i18n:locales` aggiorna esplicitamente l’elenco delle lingue e le regole per i plurali da WordPress/GlotPress. `npm run i18n:coverage` verifica che tutte le lingue nell’elenco incluso nel repository siano complete. Né i controlli di copertura né la CI normale usano l’IA o scaricano dati sulle lingue. Consultate il README del repository per le opzioni di elaborazione in batch, concorrenza e ripristino. ## Stringhe traducibili nel codice - PHP: usate le funzioni WordPress con il dominio di testo `blockstudio`, ad esempio `__( 'Invalid block.', 'blockstudio' )`. - JavaScript: importate `__` da `@/utils/__` e passate una stringa letterale, ad esempio `__( 'Add row' )`. Una stringa assemblata a runtime non può essere tradotta, quindi usate una stringa letterale per ogni variante. - Un nuovo bundle di script con stringhe traducibili deve avere una voce in `scripts/i18n.ts` e una chiamata a `wp_set_script_translations()` con lo stesso handle e `Translations::script_path()`. Dopo aver modificato le stringhe, eseguite `npm run i18n`. Aggiorna `languages/blockstudio.pot` e ogni file `.po`. Le nuove stringhe restano in inglese finché un traduttore o `npm run i18n:translate` non le traduce. La CI esegue `npm run i18n:check` e `npm run i18n:coverage`, che rifiutano file compilati non aggiornati, problemi di estrazione o copertura incompleta delle lingue. La generazione resta un'azione esplicita del responsabile della manutenzione.