Vai al contenuto

Traduzioni

Visualizza come Markdown

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-<locale>.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:

Shell
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.