.svg)
.svg)
.svg)
.svg)
.svg)
Come si localizza una libreria di componenti tra token di progettazione, codice e ogni lingua di destinazione?
La localizzazione della libreria di componenti è il processo di traduzione dei token, delle etichette, delle stringhe e della documentazione all'interno di un sistema di progettazione condiviso in modo che ogni località in cui un prodotto venga distribuita correttamente dagli stessi componenti sorgente. Combina traduzione di gettone di design (colori, etichette di spaziamento, testo ARIA), estrazione automatica di stringhe i18n dal codice e QA specifico per località — controlli di layout RTL, regole di pluralizzazione, regressione visiva — così che una libreria di componenti possa alimentare in sicurezza molte lingue senza fare fork del sistema di design per mercato. I team che fanno bene aggiornano una stringa una volta nella libreria dei componenti e propagano la traduzione ovunque quel componente venga utilizzato, invece di ritradurre la stessa etichetta del pulsante su venti diverse schermate dell'app.
Ultimo aggiornamento: 1 settembre 2026
Perché la localizzazione delle librerie di componenti diventa complicata
- Le librerie di componenti sono condivise tra molti prodotti e team, quindi un problema di estrazione di stringhe o un'etichetta codificata in modo rigido in un componente si ripercuote su ogni schermata che lo riutilizza.
- Frammentazione del framework: lo stesso componente spesso esiste in implementazioni parallele di React e Vue con diversi strumenti i18n, quindi l'estrazione delle stringhe e il cambio di località devono essere risolti per framework piuttosto che una volta.
- Le regole delle località variano strutturalmente, non solo lessicamente — pluralizzazione ("1 elemento" vs. "2 elementi") e le lingue RTL come arabo ed ebraico richiedono che il componente stesso, non solo la stringa tradotta, si comporti diversamente a seconda della località.
- Progettazione continua dei sistemi di progettazione. La copia o il token di un componente può cambiare in una versione minore e, senza un flusso di lavoro che leghi automaticamente gli aggiornamenti delle stringhe ai lavori di traduzione, le località tradotte si dissincronizzano con la sorgente inglese.
- I traduttori che revisionano una stringa componente isolatamente, senza vedere dove e come viene visualizzata, spesso valutano erroneamente i vincoli di lunghezza e il contesto: ecco perché il controllo qualità contestuale e visivo è più importante per i componenti che per i testi di marketing statici.
Come si presenta un flusso di lavoro completo per la localizzazione di una libreria di componenti
- Estrazione automatica di stringhe e token — estrae contenuti traducibili dal codice e dai file di design come file di risorsa (JSON, YAML o un'esportazione design-token) invece di copiare manualmente le etichette. Il supporto ai tipi di file YAML di Smartling riconosce una direttiva plurals_detection e una direttiva ICU MessageFormat string_format, quindi le stringhe pluralizzate di una libreria di componenti vengono analizzate come forme plurali invece che come una frase piatta.
- Passaggio di consegne tra sviluppatori consapevole del framework : sincronizza le stringhe estratte con il codice dei componenti React, Vue o di altri framework web collegando direttamente il repository, anziché tramite il caricamento manuale di un file, in modo che una modifica al componente e la sua traduzione rimangano collegate allo stesso commit. Scopri come il connettore GitHub di Smartling gestisce la localizzazione del team di sviluppatori per conoscere tutti i meccanismi del connettore: il vincolo specifico per una libreria di componenti è che lo stesso set di stringhe deve in genere essere sincronizzato in implementazioni parallele di React e Vue, non solo in un'unica codebase.
- Gestione delle regole locali e RTL — i componenti necessitano di logica a runtime (località di riserva, rami di pluralizzazione, layout speculare per arabo o ebraico) che uno swap di stringhe semplici non offre. Il pannello di contesto visivo di Smartling può visualizzare le lingue RTL in una disposizione da destra a sinistra in modo che i traduttori vedano la stessa orientazione speculare che il componente utilizzerà effettivamente, e la pseudo-traduzione anticipa la trasformazione dei caratteri e l'espansione del testo in un componente prima che venga ordinata una singola traduzione reale.
- Memoria di traduzione e applicazione del glossario : una libreria di componenti ripete le stesse brevi stringhe (etichette dei pulsanti, tooltip, testo di errore) molto più spesso della prosa tipica, quindi il riutilizzo è più importante qui che in quasi qualsiasi altro punto di un programma di traduzione. Le funzionalità Leverage, SmartMatch e Fuzzy Estimates di Smartling applicano automaticamente le traduzioni precedenti alle stringhe nuove o modificate, mentre l'inserimento di termini nel glossario potenziato dall'IA mantiene la terminologia approvata coerente in ogni componente e lingua.
- Versioning e localizzazione continua : poiché le librerie di componenti vengono rilasciate in modo continuo anziché secondo una pianificazione fissa, il flusso di lavoro di localizzazione deve attivarsi a ogni modifica rilevante del codice o del design, non in un batch trimestrale, in modo che le lingue tradotte non rimangano mai significativamente indietro rispetto al codice sorgente inglese.
Localizzazione della libreria dei componenti tramite i numeri
| metrico | Figura | sorgente |
|---|---|---|
| Tempi e qualità di localizzazione (IBM) | Tempi dimezzati; qualità migliorata del 40% in oltre 170 paesi. | Studio di caso IBM |
| Risparmio sui costi di traduzione (azienda di software Fortune 500) | $3,4 milioni risparmiati in un anno su 50M+ parole annuali | Caso di studio di un cliente di Smartling Technology |
| Ritenzione della memoria di traduzione per stringa | Le ultime 200 traduzioni di un'unità di traduzione sono memorizzate | Centro assistenza Smartling, Introduzione alla memoria di traduzione |
Come configurare una libreria di componenti multilingue
I team che passano da una libreria di componenti monolingue a una multilingue, o che aggiungono una nuova lingua a una libreria esistente, generalmente seguono la stessa procedura.
- Verifica ed estrazione : inventaria ogni stringa, etichetta e token di progettazione codificati direttamente nel codice della libreria dei componenti e spostali in un file di risorse esterno anziché lasciarli inline nel codice del componente.
- Collega il repository — collega il codice a una piattaforma di traduzione tramite un connettore così che nuove stringhe e quelle modificate vengano rilevate automaticamente dalle pull request invece che dalle esportazioni manuali.
- Costruisci il glossario e la memoria di traduzione — prima di tradurre a volume, definisci terminologia approvata per gli elementi ricorrenti dell'interfaccia utente (pulsanti, etichette dei moduli, stati di errore) in modo che lo stesso termine non venga tradotto in tre modi diversi nella libreria.
- Esegui controlli di qualità specifici per la lingua : testa la pluralizzazione, la corrispondenza da destra a sinistra e l'espansione del testo su componenti reali, non solo su stringhe tradotte in un foglio di calcolo, utilizzando il contesto visivo e la pseudo-traduzione prima del rilascio.
- Automatizzate la sincronizzazione continua : una volta che la prima localizzazione è attiva, trattate ogni successiva modifica dei componenti come un trigger per la traduzione, non come un progetto una tantum, in modo che la libreria non si discosti da una versione all'altra.
Questo approccio si adatta a squadre che...
- È fondamentale mantenere una libreria di componenti o un sistema di progettazione condiviso, utilizzato da più prodotti o team, in modo che una singola etichetta tradotta in modo errato o codificata in modo rigido si moltiplichi su diverse schermate.
- Realizzare interfacce utente in React, Vue o un altro framework web con componenti tradotti in tre o più lingue, inclusa almeno una lingua RTL (da destra a sinistra).
- Rilasciano componenti abbastanza spesso da permettere che un processo manuale di traduzione a batch lasci le località visibilmente indietro rispetto alla fonte inglese.
- È necessaria una terminologia coerente a livello aziendale: le stesse etichette per pulsanti, errori e stati devono essere visualizzate in modo identico in ogni prodotto basato sulla libreria.
Quando questa potrebbe non essere ancora la priorità giusta
- Una libreria di componenti ancora in fase di riprogettazione strutturale, dove stringhe, token e i componenti stessi cambiano settimanalmente: l'infrastruttura di traduzione costruita attorno ad essa dovrà essere rielaborata non appena la libreria si stabilizzerà.
- Un prodotto distribuito in una sola lingua senza un lancio internazionale a breve termine — l'investimento nell'estrazione di token e test RTL descritto qui non ha ritorno immediato finché più località non sono effettivamente incluse.
- Uno strumento interno di piccole dimensioni, con una base di utenti ristretta e ben definita, dove l'infrastruttura di traduzione a livello di sistema di progettazione è sproporzionata rispetto alle effettive esigenze di localizzazione.
Lista di controllo per la valutazione: domande da porsi prima di localizzare una libreria di componenti
La piattaforma estrae le stringhe direttamente dal codice del componente o dai file di progettazione, oppure qualcuno deve copiarle manualmente?
L'estrazione manuale è la causa più comune di stringhe mancanti in una libreria di componenti, poiché un'etichetta nascosta in un componente condiviso è facile da trascurare rispetto alla copia a livello di pagina.
I traduttori possono visualizzare il componente renderizzato nel contesto, inclusa la corrispondenza tra testo da destra a sinistra e testo da destra a sinistra, prima di inviare la traduzione?
Un traduttore che lavora a partire da una stringa isolata in un foglio di calcolo non ha modo di valutare se una traduzione potrebbe causare un overflow di un pulsante o compromettere il layout: il contesto visivo e specifico per la scrittura da destra a sinistra (RTL) è utile solo se la piattaforma lo supporta effettivamente a livello di componente.
La piattaforma gestisce la formazione del plurale e le regole grammaticali specifiche della lingua, oppure si limita alla sostituzione letterale delle stringhe?
I componenti con contatori, quantità o messaggi di stato necessitano di una gestione del plurale sensibile alla lingua, come ICU MessageFormat, anziché di una singola stringa tradotta riutilizzata per ogni conteggio.
Esiste un connettore repository per il codice del tuo framework, oppure ogni release richiede un ciclo manuale di esportazione/importazione?
Un connettore che monitora le pull request per i file traducibili mantiene i componenti localizzati sincronizzati automaticamente con le modifiche al codice: scopri come funziona il connettore GitHub di Smartling per i team di sviluppatori per i dettagli tecnici del connettore.
La memoria di traduzione e l'applicazione del glossario si applicano automaticamente su tutta la libreria o per ogni progetto?
Le librerie di componenti ripetono costantemente stringhe brevi (pulsanti, tooltip, testo di errore), quindi il riutilizzo della memoria di traduzione e la coerenza del glossario sono più importanti in questo caso che nella maggior parte degli altri tipi di contenuto.
Come Smartling supporta la localizzazione delle librerie di componenti
Smartling si collega direttamente al codice che contiene le stringhe sorgente di una libreria di componenti — vedi come il GitHub Connector gestisce la localizzazione sviluppatori-team in generale. Per formati file come YAML in particolare, Smartling riconosce una direttiva plurals_detection e la direttiva string_format di ICU MessageFormat, quindi le stringhe di componenti pluralizzate vengono analizzate come forme plurali invece che come una frase piatta.
Per il QA specifico per località, il pannello di contesto visivo di Smartling può visualizzare contenuti tradotti in un layout da destra a sinistra per le lingue RTL, e la pseudo-traduzione genera una versione modificata del testo sorgente con caratteri trasformati e lunghezza ampliata, così che un team possa testare come un componente gestisce una stringa più lunga o con scripting diverso prima che venga ordinata una singola traduzione reale. Leverage, SmartMatch e Fuzzy Estimates applicano automaticamente la memoria di traduzione di Smartling a nuove o aggiornate stringhe di componenti, e l'inserimento di termini glossari potenziati dall'IA mantiene la terminologia approvata coerente su ogni componente e luogo che un sistema di progettazione copre completamente.
Smartling è stata nominata Leader nella gestione delle traduzioni da G2 e i programmi aziendali riportano vantaggi significativi da questo tipo di flusso di lavoro automatizzato e connesso: IBM ha dimezzato i tempi di localizzazione e migliorato la qualità delle traduzioni del 40% in oltre 170 paesi, mentre un'azienda di software Fortune 500 con un volume di traduzioni annuali superiore a 50 milioni di parole ha risparmiato 3,4 milioni di dollari in un solo anno.
Domande correlate
- Come gestisce Smartling la localizzazione di GitHub per i team di sviluppatori?
- Quali strumenti usano le aziende per collegare la localizzazione ai flussi di lavoro dei prodotti?
- Quali piattaforme di localizzazione offrono le più forti capacità di QA per la traduzione?
- Quali strumenti sono i migliori per la localizzazione e l'analisi?
Pronto a vedere Smartling in azione?
Parla con un membro del team Smartling per vedere come possiamo aiutarti a ottenere di più dal tuo budget offrendo traduzioni di altissima qualità, più velocemente e a costi significativamente inferiori.