Tradurre un’app: integrazione con Azure Translator

Salve lettore, in questo articolo ti voglio dare uno spunto su come potresti gestire le traduzioni di un’app utilizzando Azure Translator. Un problema che si pone nello sviluppo di un’app in Business Central è quello di gestire le traduzioni. Le proprietà Caption e Tooltip nonché i vari messaggi, errori, stringhe fisse di sistema devono essere gestiste con una lingua principale. Per produrre un file .xlf occorre inserire nel proprio file app.json la proprietà features:[“TranslationFile”].

Viene generata, quindi, una cartella Translations con un file NomeApp.g.xlf. Di default questo file viene generato con un source-language = en-US, ma è possibile cambiarlo manualmente con la lingua con cui abbiamo sviluppato l’app, ad esempio it-IT.

Ora, hai un file della lingua principale dell’app, puoi creare ulteriori file di lingua duplicando il file principale e creandone, ad esempio, altri con il formato NomeApp.LinguaDaTradurre.xlf (es. NomeApp.en-US.xlf). Fatto questo puoi cambiare i tag source-language e target-language, nel nostro esempio mettendo it-IT nel source language e nel target-language en-US.

Ora però dobbiamo tradurre questo nuovo file. Principalmente questa operazione va fatta manualmente, magari utilizzando qualche estensione di Visual Studio Code per agevolare l’editing del file (ad esempio NAB AL Tools). Ma se invece di modificare manualmente il file avessi un modo per tradurlo automaticamente? Chiaramente la traduzione potrebbe essere non il massimo, ma immagina di avere centinaia di caption da tradurre, uno strumento automatico che faccia il lavoro grosso non sarebbe male, vero?

A tal proposito Microsoft ci propone, tramite un account su Azure Portal, del servizio Azure Translator API. In sostanza l’idea sarebbe quella di dare in gestione al servizio un file .xlf a questo servizio e, tramite le due lingue source e target, leggere questo file e fare una chiamata alla API. Non voglio troppo dilungarmi su come attivare il servizio, se sei un po’ pratico di Azure Portal, sai che ci sono le risorse che possono essere attivate, tra quelle disponibile cerca Translator ed attivala. Una volta attivata avrai la chiave API che sarà quella che ti servirà quando dovrai utilizzare il tuo programma che utilizzerai per leggere e chiamare il servizio.

Infatti hai bisogno di un programma che faccia il lavoro di leggere il file e fare la chiamata API. In rete ci sono diversi esempi .NET in vari linguaggi, io ti propongo un programma scritto in TypeScript che è il linguaggio utilizzato per scrivere estensioni VS Code. L’idea è quella di non spostarsi dal proprio ambiente di lavoro (VS Code) quindi creeremo una piccola estensione casalinga da poter chiamare tramite la linea di comando dell’ambiente di sviluppo.

Per prima cosa, creiamo una funzione che chieda la chiave API

Dopodiché creiamo una funzione per leggere il workspace ed individuare i file .xlf da tradurre.

Dopo aver letto tramite il parser DOM XML tutto il file ed aver individuato le lingue source e target, abbiamo bisogno di salvare l’elenco di tutte le stringhe da tradurre in un formato appropriato. A tal proposito utilizzeremo tramite le chiamate REST il servizio, quindi creeremo un JSON con il formato simile a questo.

A questo scopo, creiamo una funzione che ci crei un JSON come sopra.

Ora possiamo passare alla API di Translator il JSON creato.

Non ci resta che analizzare la risposta JSON e rimettere le stringhe tradotte nel xlf.

Infine non ci resta che serializzare il DOM, lo salviamo e lo mostriamo in VS Code.

Abbiamo finito. Ora tutto quello che ci resta è pubblicare il programma TypeScript per generare un file VSIX da richiamare con VS Code. La parte di creazione di un’estensione di VS Code l’ho tralasciata, ma ti lascio un link alla guida ufficiale su come inizializzare un progetto per lo sviluppo di un’estensione VS Code. E poi ti lascio un altro link per generare un file VSIX da installare come estensione ed eventualmente distribuire al tuo team di lavoro.

L’estensione che ti ho mostrato è rigenerativa, pertanto se fai modifiche al file tradotto, rieseguendo il comando di traduzione automatica viene sovrascritto. A tal proposito ti consiglio di lavorare in combinazione con l’estensione che ti ho proposto NAB AL Tool. Questa estensione ha un comando che identifica le stringhe non tradotte, pertanto potresti modificare il programma passando al JSON solo le stringhe che hanno NAB: NEED TRANSLATION come descrizione. NAB AL Tool ha inoltre un’interessante editor visuale che ti permette di fare delle revisioni alle stringhe tradotte. 

Questa è un po’ la mia esperienza sul campo riguardo l’argomento traduzioni. Il risultato con questo metodo è buono, non è ottimale perché comunque ci si appoggia a un servizio di traduzione automatico (s’eppur cognitivo). Il grosso del lavoro è comunque svolto; si tratta, poi, di andare per eccezioni e verificare le stringhe di cui non abbiamo una traduzione ottimale.

Hai già lavorato con i file xlf? Quali sono le tue esperienze?

Lascia una risposta