Come tradurre i file DITA senza conversione XLIFF

Stai cercando un modo per tradurre i tuoi file DITA senza il costante mal di testa delle conversioni manuali XLIFF? Se è così, sei nel posto giusto. DITA (Darwin Information Typing Architecture) è già lo standard di riferimento per l'efficienza e il riutilizzo dei contenuti, ma molti team di contenuti tecnici si ritrovano ancora intrappolati in un circolo vizioso: il ciclo di conversione XLIFF.

Se il tuo attuale flusso di lavoro di traduzione prevede l'esportazione di file DITA in XLIFF, l'invio di tali file a un'agenzia e la successiva reimportazione manuale nel tuo sistema, probabilmente stai perdendo più di un semplice tempo. Potresti mettere a rischio l'integrità stessa della documentazione per la quale hai lavorato così duramente.

In questo articolo parleremo delle insidie ​​tecniche della conversione manuale, dei costi nascosti della gestione dei delta e del motivo per cui il supporto DITA nativo rappresenta una svolta per i moderni team di documentazione. Una volta terminato di leggere questo articolo, sarai pronto a iniziare a ottimizzare i tuoi flussi di lavoro di traduzione DITA e ad adottare un processo più rapido, affidabile e notevolmente più conveniente. Andiamo subito al dunque!

La tassa XLIFF sulla documentazione tecnica

XLIFF (XML Localization Interchange File Format) è uno standard eccellente per molti aspetti, ma per gli utenti DITA spesso funge da intermediario, complicando più di quanto semplifichi. Spesso ci riferiamo a questo come alla tassa XLIFF: il costo nascosto di tempo, denaro e lavoro manuale necessari per far funzionare il formato. Ecco perché questo processo di conversione manuale potrebbe costare al tuo team più di quanto pensi.

1. La ripartizione del riutilizzo dei contenuti: Conrefs e Keyrefs

La vera genialità di DITA risiede nella sua capacità di fare riferimento a contenuti che spaziano su più argomenti. Quando si converte un file DITA in XLIFF, queste relazioni sofisticate vengono spesso appiattite o addirittura interrotte. In un file XLIFF standard, un riferimento al contenuto (conref) potrebbe apparire semplicemente come una stringa di testo statica.

Ciò crea un problema finanziario significativo: potresti ritrovarti a pagare per tradurre più volte la stessa nota di avvertenza o procedura di sicurezza perché lo strumento di conversione non è riuscito a riconoscerla come un'unica entità riutilizzabile. Ancora peggio, quando reimporti quel testo, potresti scoprire che i riferimenti ai contenuti globali sono stati sovrascritti da testo hard-coded, il che di fatto distrugge la tua architettura modulare e rende gli aggiornamenti futuri un incubo.

2. Tag corrotti ed errori di convalida

I file DITA sono regolati da rigidi DTD (Document Type Definitions) o schemi XML. Ogni volta che il tuo contenuto passa dal formato .dita al formato .xliff e viceversa, corri il rischio di creare quella che chiamiamo zuppa di tag.

Basta un traduttore che non ha familiarità con la struttura DITA per eliminare accidentalmente un attributo obbligatorio o per smarrire un tag di chiusura. Una singola parentesi mancante o un attributo fuori posto durante il viaggio di andata e ritorno possono compromettere l'intera build DITA-OT. Ci siamo passati tutti: è un venerdì pomeriggio e stai cercando di promuovere una versione, ma i tuoi tecnici dell'assistenza stanno setacciando migliaia di righe di codice per trovare un singolo errore di convalida.

3. L'incubo della gestione del Delta

I flussi di lavoro XLIFF manuali spesso costringono gli autori a smettere di essere creatori e a diventare gestori di file. Per risparmiare sui costi di traduzione, gli autori spesso cercano di identificare manualmente i delta (solo i file che sono cambiati dall'ultimo aggiornamento). Questo processo è notoriamente difficile per tre motivi:

• È soggetto a errori: la mancanza di un solo argomento aggiornato può comportare una documentazione non sincronizzata che confonde i clienti.
• Tecnicamente è faticoso: il tuo team finisce per passare ore a confrontare le versioni invece di scrivere nuovi contenuti utili.
• Manca il contesto: se una piccola modifica in un argomento influisce sul significato di un argomento correlato, una selezione delta manuale probabilmente non la rileverà.

Oltre il tag: l'importanza della protezione degli attributi

Uno degli aspetti più trascurati della lotta tra DITA e XLIFF è la gestione degli attributi XML. Per la profilazione e il filtraggio, DITA si basa in larga misura su attributi quali prodotto, piattaforma e pubblico. Si tratta di strumenti che consentono di pubblicare diverse versioni di un manuale dalla stessa fonte.

Quando si utilizza un flusso di lavoro DITA nativo, questi attributi sono protetti per impostazione predefinita. In MotaWord, il nostro sistema riconosce che un attributo di prodotto è un pezzo di metadati che non dovrebbe mai essere tradotto. In una conversione XLIFF standard, questi attributi vengono spesso eliminati (il che interrompe la pubblicazione condizionale) o esposti al traduttore. Se un traduttore vede pro_version e lo traduce in spagnolo come version_profesional, la logica di elaborazione condizionale non funzionerà più.

Perché Translate=No è un salvagente

L'attributo translate="no" è uno strumento essenziale per i redattori tecnici che hanno bisogno di mantenere coerenti frammenti di codice, istruzioni della riga di comando o nomi di marchi specifici in tutti i linguaggi. Un parser DITA nativo rispetta questo attributo a livello di motore. Nelle conversioni XLIFF manuali, queste istruzioni vengono spesso ignorate dai filtri utilizzati per creare il file XLIFF, il che comporta costosi e fastidiosi cicli di post-editing per correggere i contenuti tradotti in eccesso.

Il divario contestuale: perché i traduttori hanno difficoltà con XLIFF

La traduzione non è solo uno scambio di parole: è una questione di comprensione del contesto. Quando un argomento DITA viene convertito in un file XLIFF semplice, il traduttore vede spesso un elenco di stringhe isolate. Perdono la vista Mappa che conferisce struttura al progetto. Non riescono a vedere che un determinato titolo appartiene a una sezione specifica all'interno di un compito più ampio.

Utilizzando Native DITA Translation, il traduttore lavora all'interno di un sistema che comprende effettivamente la gerarchia DITA. Ciò offre diversi vantaggi per la qualità della documentazione:

• Fornisce maggiore chiarezza: il traduttore sa se una parola è un passaggio, un risultato o un prerequisito.
• Garantisce una terminologia coerente: il sistema verifica che un termine utilizzato in una shortdesc corrisponda allo stesso termine nel corpo dell'argomento.
• Mantiene l'integrità visiva: il flusso logico delle informazioni rimane intatto, il che è particolarmente importante quando si producono manuali tecnici complessi per hardware o software.

Un modo migliore: traduzione DITA nativa con MotaWord

Crediamo che i redattori tecnici debbano potersi concentrare sui contenuti, non dover combattere con i formati dei file. Ecco perché abbiamo lavorato per eliminare l'intermediario XLIFF attraverso un approccio nativo.

Confronto del flusso di lavoro

Il flusso di lavoro XLIFF manuale

• Richiede ore di esportazione e filtraggio dei file.
• Comporta un rischio elevato di appiattimento dei riferimenti di contenuto.
• Spesso si traduce in metadati corrotti o tradotti accidentalmente.
• Richiede un QA manuale approfondito dopo l'importazione dei file.
• Costi nascosti sostenuti a causa del lavoro manuale e delle stringhe duplicate.

Il flusso di lavoro DITA nativo con MotaWord

• Ci vogliono pochi minuti tramite il caricamento diretto dei tuoi file.
• Mantiene l'integrità del tuo conref protetta al 100%.
• Blocca o ignora automaticamente i metadati per mantenerli al sicuro.
• Fornisce file pronti per la compilazione nel momento in cui li scarichi.
• Utilizza la memoria di traduzione per garantire che tu paghi solo per i nuovi contenuti.

Carica i tuoi file grezzi .dita e .ditamap

Invece di esportazioni complesse, puoi semplicemente caricare i tuoi file DITA grezzi o l'intero progetto Ditamap. La nostra piattaforma è progettata per analizzare la struttura DITA in modo nativo. Riconosce la differenza tra titolo, corpo e descrizione abbreviata, garantendo che i metadati rimangano intatti e che la struttura rimanga solida.

Automazione invece di differenziazione manuale

Poiché MotaWord utilizza una memoria di traduzione integrata, non è più necessario perdere tempo a capire quali file sono stati modificati. Puoi caricare l'intero progetto e lasciare che il sistema faccia il grosso del lavoro:

• Il nostro sistema confronta l'intero Ditamap con le tue traduzioni precedenti.
• Identifica stringhe nuove o modificate in pochi secondi.
• Paghi solo per le nuove parole, usufruendo dei vantaggi economici dei delta senza dover affrontare alcun mal di testa manuale.

L'economia della documentazione pronta per la costruzione

Il vero costo nascosto della conversione XLIFF si riscontra nel ciclo di pubblicazione finale. In un flusso di lavoro manuale, la ricezione dei file tradotti rappresenta solo il punto intermedio. Devi ancora reimportare tutto nel tuo CCMS (Component Content Management System), eseguire una build di prova utilizzando DITA Open Toolkit ed eseguire il debug degli inevitabili errori XML.

Questa fase di controllo qualità della localizzazione può richiedere giorni o addirittura settimane di tempo da parte dello scrittore. Il supporto nativo DITA garantisce che i file scaricati siano pronti per l'uso. Poiché la struttura non è mai stata smontata per essere inserita in un contenitore XLIFF, non è necessario ricostruirla. Bastano pochi clic per passare dalla traduzione completata alla pubblicazione di un sito PDF o HTML.

Domande frequenti

1. Come tradurre i file DITA senza compromettere i conref?

Le piattaforme di traduzione DITA native come MotaWord elaborano i file nella loro struttura XML originale. Evitando la conversione in XLIFF, il sistema mantiene i puntatori ai riferimenti di contenuto (conref) e ai riferimenti chiave (keyref). Ciò garantisce che gli oggetti riutilizzabili vengano gestiti correttamente senza essere codificati nel testo tradotto.

2. Qual è il flusso di lavoro di traduzione DITA migliore per i piccoli team?

Il flusso di lavoro più efficiente per i team di piccole dimensioni è l'approccio Direct to DITA. Invece di investire in costosi middleware o di dedicare ore alle esportazioni XLIFF manuali, i piccoli team dovrebbero utilizzare una piattaforma che accetti direttamente i file .dita e .ditamap. Ciò riduce il sovraccarico tecnico ed elimina la necessità di un tecnico di localizzazione dedicato.

3. MotaWord supporta DTD DITA specializzati?

Sì. Poiché DITA consente la specializzazione (la creazione di tipi di elementi personalizzati), il nostro parser nativo è progettato per rispettare lo schema XML sottostante. I tag e gli attributi personalizzati sono protetti ed esclusi dal conteggio delle parole, a meno che non contengano contenuti traducibili.

4. DITA vs XLIFF per la traduzione: qual è il migliore?

Mentre XLIFF è un ottimo formato di interscambio per stringhe software generiche, DITA è migliore per la documentazione strutturata perché contiene più contesto in merito al riutilizzo dei contenuti. Tradurre DITA in modo nativo è quasi sempre meglio perché evita gli errori di andata e ritorno che sono comuni quando si converte tra due formati di file diversi.

5. Posso utilizzare la traduzione DITA nativa con il mio CCMS esistente?

Assolutamente. La maggior parte dei sistemi di gestione dei contenuti dei componenti, come IXIASOFT, Heretto o Oxygen Content Fusion, consentono di esportare pacchetti DITA grezzi. Puoi caricare questi pacchetti direttamente su MotaWord e poi ricaricare i risultati tradotti nel tuo CCMS senza passaggi di conversione intermedi.

6. Come ridurre i costi di traduzione DITA utilizzando la memoria di traduzione?

Caricando l'intero Ditamap su una piattaforma nativa, il sistema utilizza la memoria di traduzione (TM) per identificare le corrispondenze esatte dei tuoi progetti precedenti. Ti verrà fatturato solo il testo nuovo o modificato, il che riduce significativamente i costi dei progetti di documentazione tecnica a lungo termine.

7. Come gestire la localizzazione delle immagini DITA e gli href?

Quando carichi il tuo progetto DITA in modo nativo, il sistema riconosce i tag immagine e link. È possibile specificare se si desidera che i percorsi di queste immagini vengano aggiornati nelle cartelle localizzate (ad esempio, modificando un percorso da /images/en/ a /images/es/) o mantenuti esattamente come sono. In questo modo i tuoi link non si interromperanno mai nella versione tradotta.

Interrompi la conversione e inizia la sincronizzazione con MotaWord

Se il tuo attuale flusso di lavoro di traduzione ti sembra un ostacolo manuale che frena il tuo slancio, è probabile che sia giunto il momento di abbandonare la conversione XLIFF e passare a un flusso di lavoro DITA nativo. Eliminando questi passaggi manuali, si riduce il rischio di errori di documentazione e si velocizzano notevolmente i cicli di rilascio globali.

Dovresti investire la tua competenza nella creazione di contenuti di qualità, non nella gestione delle esportazioni di file. Pronto a scoprire quanto tempo e fatica puoi risparmiare sul tuo prossimo progetto? Puoi ottenere un preventivo immediato su MotaWord caricando oggi stesso i tuoi file .dita.

OYTUN TEZ - Direttore tecnico (CTO) presso MotaWord

Studioso di studi sulla traduzione con una tesi sulla traduzione automatica, esperto di tecnologia e ossessionato dai flussi di traduzione intelligenti e fluidi.