Il caso commerciale della localizzazione a livello di blocco

C'è uno schema in ogni azienda che opera a livello transfrontaliero. La documentazione in inglese è solida. La versione tedesca è in ritardo di tre mesi. La versione giapponese è stata tradotta una volta, da un appaltatore, e nessuno l'ha più toccata. La versione brasiliana in portoghese non esiste ancora, anche se San Paolo è l'ufficio in più rapida crescita.

Tutti concordano che si tratta di un problema. Nessuno ha una buona soluzione. Finora, la localizzazione è stata trattata come un progetto, uno sforzo una tantum che si mette in preventivo, si esegue e poi si trascura tranquillamente fino alla prossima grande revisione.

Questo approccio è rotto. Ecco perché e cosa penso che funzioni davvero.

La traduzione non è localizzazione

Chiariamo la terminologia. La traduzione consiste nel prendere un testo in una lingua e produrre un testo equivalente in un'altra. La localizzazione consiste nel far funzionare le conoscenze in un mercato specifico. Si sovrappongono, ma non sono la stessa cosa.

Un documento tradotto si legge correttamente. Un documento localizzato si legge in modo naturale. Tiene conto del contesto culturale, delle normative regionali, degli strumenti locali e del modo in cui le persone in quel mercato lavorano.

Questa distinzione è importante perché la maggior parte delle piattaforme di documentazione trattano la localizzazione come un compito di traduzione. Si scrive in inglese, si preme un pulsante e si ottiene un risultato in francese. Fatto. Solo che non è fatto, perché..:

• Il team francese ha un processo di distribuzione diverso che il documento in inglese non contempla.
• I requisiti di conformità tedeschi aggiungono una fase di approvazione supplementare che non esiste altrove.
• l'ufficio giapponese utilizza uno strumento interno diverso per lo stesso flusso di lavoro
• I lettori portoghesi brasiliani hanno bisogno di un contesto sulle norme fiscali locali che non sono rilevanti altrove.

**Una traduzione diretta del documento inglese è tecnicamente corretta in tutti questi casi, e praticamente inutile in tutti gli altri.

Il problema della traduzione a livello di documento

La localizzazione tradizionale funziona a livello di documento. Lei ha un documento in inglese. Lo traduce interamente in tedesco. Quando la versione inglese cambia, invia l'intero documento per una nuova traduzione. Questo crea tre problemi:

1. È costoso

Se la sua guida onboarding ha 15 sezioni e lei cambia un paragrafo, pagherà per ritradurre tutte e 15 le sezioni. Moltiplicando questo dato per 8 lingue, ogni modifica diventa una conversazione di bilancio.

2. È lento

Inviare documenti completi per la traduzione richiede tempo. Anche con la moderna traduzione automatica, il ciclo di revisione di un documento completo è significativamente più lungo rispetto alla revisione di una singola sezione modificata. I team in altre lingue sono sempre in ritardo.

3. Non supporta i contenuti unici

Questo è il vero problema. Se la versione tedesca ha bisogno di una sezione extra sulla conformità DSGVO, dove va a finire? In un sistema di traduzione a livello di documento, qualsiasi contenuto aggiunto alla versione tedesca viene sovrascritto la volta successiva che qualcuno ritraduce dall'inglese. Il team tedesco impara in fretta: non aggiunga nulla, perché verrà cancellato.

Localizzazione a livello di blocco: un'architettura diversa

Rasepi non traduce documenti. Traduce blocchi: singoli paragrafi, titoli e sezioni, ognuno dei quali viene tracciato in modo indipendente con la propria identità e hash del contenuto.

Ecco cosa significa in pratica:

Quando modifica un singolo paragrafo in inglese, Rasepi rileva quale blocco è cambiato confrontando gli hash del contenuto SHA256. Solo quel blocco viene inviato per la traduzione tramite DeepL. Gli altri 14 blocchi del documento rimangono esattamente come erano. Il suo costo di traduzione si riduce fino al 94%.

Quando il traduttore tedesco deve aggiungere una sezione DSGVO, la aggiunge come nuovo blocco nella versione tedesca. Questo blocco esiste solo in tedesco. Non influisce sulla fonte inglese. Non viene sovrascritto quando l'inglese cambia. È contrassegnato come contenuto unico, in modo che tutti sappiano che è intenzionale.

Quando la versione giapponese ha bisogno di una struttura diversa, ad esempio un elenco numerato invece di punti elenco perché è la convenzione della scrittura tecnica giapponese, il traduttore può cambiare il tipo di blocco. Il sistema tiene traccia di questo come "adattamento della struttura" e lo conserva per gli aggiornamenti futuri.

Ogni versione linguistica diventa un documento di prima classe, non una copia ombra.

Come funziona, tecnicamente

Ogni blocco in Rasepi ha:

• Un UUID che persiste in tutte le modifiche e traduzioni
• Un hash del contenuto (SHA256) che cambia quando il testo viene modificato
• Un indice di posizione, in modo che i blocchi rimangano nel giusto ordine
• Un flag di cancellazione morbida**, in modo che la rimozione di un blocco in inglese non interrompa l'allineamento in altre lingue.

Quando viene creato un blocco di traduzione, viene memorizzato l'hash del contenuto del blocco sorgente. Ad ogni salvataggio, il sistema confronta gli hash. Se corrispondono, la traduzione è corrente. In caso contrario, la traduzione viene contrassegnata come obsoleta e solo quel blocco specifico necessita di attenzione.

Questo è il meccanismo alla base della riduzione dei costi del 94%. La maggior parte delle modifiche cambia una o due sezioni. Il resto del documento, in tutte le lingue, non viene toccato.

Contenuto unico per lingua

Qui le cose si differenziano veramente da qualsiasi altra piattaforma.

In Rasepi, ogni versione linguistica può contenere:

• Blocchi tradotti. Traduzioni dirette della lingua di partenza, monitorate per verificare l'obsolescenza.
• Blocchi unici.** Contenuto che esiste solo in quella lingua, aggiunto dal team locale.
• Blocchi adattati alla struttura.** Stesso contenuto di partenza, formattazione o tipo di blocco diversi.

Un singolo documento potrebbe avere questo aspetto nelle varie lingue:

Ogni team riceve esattamente la documentazione di cui ha bisogno. Senza compromessi. Nessuna soluzione. Nessuna limitazione unica per tutti.

Tracciamento della freschezza nelle varie lingue

Ogni versione linguistica traccia la propria freschezza in modo indipendente. La fonte inglese potrebbe ottenere un punteggio di 94 (recensione recente, tutti i link validi, alto numero di lettori). La versione francese potrebbe ottenere un punteggio di 71 (due blocchi obsoleti, un link rotto specifico per il contenuto francese). La versione giapponese potrebbe ottenere un punteggio di 88 (tutte le traduzioni sono aggiornate, ma i lettori sono in calo).

Questo monitoraggio della freschezza per lingua significa che:

• Sapere esattamente quali sono le lingue che necessitano di attenzione
• Le traduzioni obsolete vengono evidenziate automaticamente, non vengono scoperte per caso.
• Gli strumenti di intelligenza artificiale possono tenere conto della freschezza specifica della lingua quando servono le risposte.
• I dashboard mostrano la salute dei contenuti suddivisi per lingua, non solo per documento

Il caso aziendale

Le aziende che operano in più lingue devono affrontare una semplice realtà: la sua documentazione è una risorsa o una passività in ogni mercato che serve.

Se il suo team di Berlino lavora su una traduzione tedesca che è tre mesi indietro rispetto alla fonte inglese, sta prendendo decisioni basate su informazioni non aggiornate. Quando il suo ufficio di Tokyo non può aggiungere il contesto locale ai documenti condivisi perché il sistema di traduzione lo sovrascriverebbe, smette di usare il wiki e crea la propria documentazione ombra. Quando il suo team di San Paolo non dispone di documenti in portoghese, l'onboarding richiede il doppio del tempo.

Il costo non è solo quello della traduzione. E' anche:

• Minore onboarding nei mercati non anglosassoni
• Sforzo duplicato, in quanto i team mantengono una documentazione parallela negli strumenti locali.
• Silos di conoscenza che si formano quando il wiki ufficiale non è utile a tutti.
• Rischio di conformità** quando i requisiti specifici della regione non vengono catturati.
• Perdita di fiducia nel sistema di documentazione stesso

La localizzazione a livello di blocco risolve tutti questi problemi, non rendendo la traduzione più economica (anche se lo fa), ma rendendo ogni versione linguistica un documento vivo, curato e affidabile.

Iniziare

Se oggi gestisce un team multilingue su una qualsiasi piattaforma di documentazione, ecco un rapido controllo di base:

1. Scelga il suo documento più importante. Lo controlli in ogni lingua. Ogni versione è aggiornata?
2. Chieda ai suoi team non inglesi: si fidano dei documenti tradotti? Li utilizzano?
3. **I team mantengono wiki locali, pagine Notion o messaggi appuntati su Slack perché i documenti ufficiali non li servono?
4. Calcolare la spesa per le traduzioni. Quanto paga per ogni aggiornamento, e quanta parte di questa spesa è costituita dalla ritraduzione di contenuti che non sono cambiati?

Se le risposte sono scomode, non è l'unico. La maggior parte delle aziende non scopre il divario fino a quando non causa un problema reale: un problema di conformità, un'implementazione sbagliata, un nuovo assunto che ha trascorso due settimane seguendo istruzioni obsolete.

La conoscenza multilingue non è una cosa piacevole. Per qualsiasi azienda che opera a livello transfrontaliero, è la base del modo in cui i team si allineano, prendono decisioni e spediscono. La questione è se la sua piattaforma di documentazione la tratta in questo modo.

Ogni lingua merita di essere un cittadino di prima classe nella sua base di conoscenza. Non una copia. Non un'ombra. Un documento reale, curato e affidabile.

Ecco cosa offre Rasepi. Traduzione a livello di blocco, contenuti unici per lingua, monitoraggio indipendente della freschezza e una riduzione del 94% dei costi di traduzione. Tutto automatico. Tutto dal primo giorno.

Vedere la pubblicazione multilingue in azione →