Vai al contenuto principale

​
Panoramica

Le app di Twenty sono scritte in inglese: le stringhe nel tuo sorgente e nel manifest sono il testo sorgente in inglese, en è la locale di origine da cui traduci da, e qualsiasi locale lasciata non tradotta usa quella come fallback. La tua app ha due tipi di testo traducibile, e entrambi passano attraverso lo stesso catalogo locales/:
  • Etichette del manifest — nomi di oggetti e campi, titoli delle viste, voci di menu e altre stringhe dichiarate nei metadati della tua app.
  • Stringhe dei componenti front-end — il testo dell’interfaccia utente visualizzato dai componenti front-end React.
Contrassegni le stringhe traducibili, le estrai in cataloghi per ciascuna lingua, traduci tali cataloghi e la build offre la lingua corretta per l’ utente corrente — senza configurazioni aggiuntive.

​
Contrassegnare le stringhe del front-component.

Importa gli helper di traduzione da twenty-sdk/front-component:

​
Quando usare quale

  • Trans — testo statico in JSX. Usa le prop message e values per l’interpolazione, come in Trans message="Hi {name}" values={{ name }}; l’interpolazione direttamente nei figli non è estraibile staticamente.
  • useTranslate().t — stringhe dinamiche all’interno di un componente. Esegue nuovamente il rendering quando l’utente cambia lingua. Preferiscilo all’interno del rendering.
  • t(...) (importato direttamente) — traduzione immediata utilizzabile ovunque, inclusi gestori di eventi, helper e ambito del modulo — non solo all’interno del rendering.
  • msg(...) — un descrittore lazy per le stringhe dichiarate come dati (costanti, configurazione). Risolvilo in seguito con t(descriptor).

​
Contesto

Passa context per distinguere stringhe di origine identiche che vengono tradotte in modo diverso:
Le stringhe contestuali compaiono nei cataloghi delle impostazioni locali come un gruppo indicizzato dal loro contesto: "\<context>": { "\<message>": "\<translation>" }. Le etichette del manifest sono contestuali per costruzione — ognuna porta con sé il ruolo di metadato che svolge (objectMetadata.labelSingular, fieldMetadata.label, view.name, …), quindi la stessa parola può essere tradotta in modo diverso come nome di oggetto e come nome di vista.

​
Estrazione e traduzione

Esegui il comando di estrazione dalla directory della tua app:
L’estrazione raccoglie sia le etichette del manifest sia le stringhe t()/msg()/Trans dal tuo sorgente front-component in locales/\<locale>.json, indicizzate per stringa sorgente. Inserisci le traduzioni:
Le stringhe prive di contesto sono voci piatte; le stringhe contestuali — inclusa ogni etichetta del manifest — sono annidate sotto la loro chiave di contesto. I segnaposto come {name} vengono sostituiti in fase di esecuzione — mantienili nella traduzione. Qualsiasi stringa lasciata vuota ripiega sul testo di origine.

​
Come funziona

twenty app build compila i cataloghi e fornisce la lingua corretta per l’ utente corrente: le etichette del manifest vengono risolte lato server e i cataloghi dei componenti front-end sono inclusi in ogni bundle di componenti. In fase di esecuzione, un componente legge le impostazioni locali dal proprio contesto di esecuzione (la lingua corrente dell’host) e risolve ogni stringa rispetto al proprio catalogo, ripiegando sul testo di origine quando manca una traduzione. Cambiare lingua nell’host esegue nuovamente il render delle stringhe Trans e useTranslate().t in tempo reale. Le etichette del manifest vengono compilate a ogni sincronizzazione — twenty app build, twenty app apply e anche il monitoraggio continuo di twenty app dev — quindi modificare un file di locale e sincronizzare è sufficiente per visualizzare il nuovo testo. I cataloghi dei componenti front-end sono inclusi in ogni bundle di componenti al momento della compilazione, quindi modificare uno di essi richiede comunque di rieseguire twenty app build (e di effettuare nuovamente il deployment).

​
Recupero delle traduzioni

twenty app pull riscrive le traduzioni pubblicate di un’applicazione in locales/. Un catalogo pubblicato è indicizzato tramite l’ID del messaggio, quindi pull recupera il formato leggibile solo per le stringhe di cui può vedere l’origine: le etichette dei metadati recuperati e le stringhe t()/msg()/Trans dei componenti front-end presenti nel progetto. Tutto il resto viene mantenuto così com’è in locales/compiled/\<locale>.json, indicizzato tramite l’ID del messaggio. La build unisce quei file nel catalogo (una voce in locales/\<locale>.json ha la precedenza su una compilata con lo stesso id), twenty app translations extract li lascia invariati, e ogni pull li riscrive, quindi si riducono man mano che una parte maggiore del codice sorgente dell’app viene aggiunta all’albero. Non modificarli manualmente; traduci in locales/\<locale>.json. Un progetto senza una cartella locales/ non indica nulla sulle traduzioni, quindi una sincronizzazione da esso lascia invariato tutto ciò che l’app ha già pubblicato. Per rimuovere intenzionalmente le traduzioni pubblicate, mantieni la cartella ed elimina i file delle impostazioni locali al suo interno: una cartella locales/ che non compila in alcuna impostazione locale è una dichiarazione esplicita e la sincronizzazione esegue la rimozione di conseguenza. I figli di testo di Trans possono estendersi su più righe — gli spazi bianchi vengono compressi nello stesso modo in cui JSX li comprime, quindi entrambe queste varianti vengono estratte con la chiave Welcome back: