Localizzazione in Wisej.NET

Localizzazione in Wisej.NET, Modulo 1. GlobalDesk è un service desk scritto per un solo ufficio, e trasformarlo in un'applicazione che più uffici possono usare comincia con due lavori distinti.

L'inglese scritto nel codice è solo metà del problema. Comporre un importo mettendo il simbolo del dollaro davanti a un numero inchioda nel codice la convenzione di un solo paese, e nessun file di traduzione potrà mai rimediare. Qui Wisej.NET usa il modello standard di .NET: file di risorse, CultureInfo e ResourceManager.

Un nome di cultura unisce una lingua e una regione. L'inglese da solo indica soltanto la lingua, mentre inglese Stati Uniti, tedesco Germania e francese Canada aggiungono ciascuno le proprie convenzioni regionali. La lingua decide le parole che mostri, la cultura decide come vengono scritti date, numeri e importi.

I file di risorse si impilano. Una ricerca prova prima il file più specifico, poi il file della sola lingua e infine quello neutro. Siccome il file neutro è l'ultima fermata, deve essere completo: quello che manca lì non ha più niente su cui ricadere.

Nel codice questo significa dodici chiavi semantiche nel file di risorse neutro e un solo ResourceManager costruito dal nome base e dall'assembly. Un helper restituisce la chiave tra parentesi quadre quando non trova niente, così una lacuna appare come qualcosa che puoi leggere sullo schermo invece che come un'etichetta vuota che nessuno nota.

Ora la riscrittura. Un metodo mette le parole sullo schermo cercando ogni didascalia per chiave. Un secondo formatta una data, un numero e un importo con la cultura corrente nel momento in cui li mostra, il che lascia i valori memorizzati intatti e neutri.

All'esecuzione ogni didascalia si risolve tranne una, e quella compare come la sua chiave tra parentesi quadre. La lacuna è visibile invece che silenziosa. Aggiungi la chiave mancante e tutti e tre i valori di anteprima vengono formattati secondo la cultura con cui gira questa sessione.

Due browser su un solo processo server, uno in inglese e uno in tedesco, mostrano lo stesso codice, le stesse chiavi e lo stesso decimale memorizzato reso in due modi. Funziona perché la cultura appartiene alla sessione, e mai a un campo statico condiviso da tutti.

Lab uno: costruisci la dashboard di GlobalDesk su un file di risorse neutro, aggiungi l'helper di testo che segnala una chiave mancante, aggiungi il pannello di anteprima della cultura e scrivi la nota che separa i dati dalla presentazione.

Modulo 2: localizzare una schermata che è stata disegnata anziché scritta. L'editor clienti di GlobalDesk è stato disposto nel designer di Visual Studio, e il tedesco ha bisogno di parole diverse e, si scopre, di una geometria diversa.

Le didascalie che vivono solo nel designer sono irraggiungibili per un traduttore. Una didascalia tedesca non entra in un pulsante dimensionato su quella inglese. E allargare ogni pulsante per la lingua più lunga che potresti mai spedire rovina il layout per la lingua che la maggior parte dei tuoi utenti legge davvero.

Sei passi. Prima finisci il layout neutro. Metti a vero la proprietà Localizable del form. Scegli la lingua. Cambia solo ciò che differisce. Esegui l'applicazione con quella cultura. Poi riporta il designer al neutro prima di qualsiasi modifica strutturale, perché le modifiche strutturali appartengono soltanto al layout neutro.

Il codice generato dal designer conserva solo i valori neutri, e sono il dimensionamento automatico, l'ancoraggio e l'aggancio a fare il lavoro di layout. Testo, dimensione e posizione tedeschi finiscono invece nei file di risorse generati, ed è per questo che a un traduttore puoi consegnare dei file invece di un ambiente di sviluppo.

La cultura corrente appartiene alla sessione, mai a un campo statico. E siccome le risorse del designer vengono lette quando un controllo viene creato, cambiare la cultura non ridisegna una schermata che esiste già. L'editor va rimosso, eliminato e ricostruito prima di rileggere le sue risorse.

Decidi il livello prima di aggiungere la stringa. Testo, dimensione, posizione, colori e immagini che appartengono a una sola schermata disegnata stanno nelle risorse del designer di quella schermata. Tutto ciò che genera il codice, e tutto ciò che condividono più schermate, va invece nel file di risorse condiviso.

In esecuzione in tedesco le didascalie vengono tagliate dentro una larghezza di pulsante misurata sull'inglese, finché non sovrascrivi la dimensione solo per il tedesco. È il browser a dimostrarlo, non la superficie di progettazione, perché la superficie di progettazione ti sta mostrando il layout neutro.

Cambiare la cultura della sessione mentre l'applicazione gira lascia in inglese l'editor aperto. Resta così finché l'azione di ricreazione non lo elimina e non ne costruisce uno nuovo, che a quel punto legge le sue risorse con la nuova cultura. È la regola del momento di creazione, vista dal vivo.

Lab due: rendi localizzabile l'editor clienti, aggiungi una variante tedesca con un override di dimensione e uno di posizione, evita che le didascalie vengano tagliate e dimostra la regola del momento di creazione.

Localizzazione in Wisej.NET, Modulo 3: il livello di risorse condiviso. È il testo che nessun controllo disegnato possiede, insieme alle etichette che Wisej.NET disegna da sé, dentro GlobalDesk.

Il Modulo 2 ha tradotto le didascalie sullo schermo. La conferma di salvataggio, i messaggi di validazione, la riga di stato e il risultato restituito da un servizio sono ancora letterali inglesi dentro il codice, e la localizzazione del designer non ne raggiunge nessuno, perché nessun controllo li possiede.

Il file di risorse neutro contiene ogni chiave. Il file tedesco gli sta accanto con esattamente le stesse chiavi e solo i valori tradotti. Una ricerca percorre la cultura più specifica, poi il file della sola lingua, poi quello neutro, e prende la prima corrispondenza che trova: è questo a rendere sicura una traduzione parziale.

Un solo ResourceManager, costruito dal nome base e dall'assembly, sta dietro a un piccolo helper che restituisce la chiave tra parentesi quadre invece di una stringa vuota quando un valore manca.

Tieni ogni frase intera. Memorizza la frase completa con un segnaposto e poi formattala per la cultura corrente, invece di concatenare nel codice frammenti tradotti.

Tre livelli, tre proprietari. Le risorse del designer portano il testo di una singola schermata. Il file di stringhe condiviso porta il testo di prodotto usato ovunque. E un file di risorse separato sovrascrive le etichette che Wisej.NET fornisce da sé, come i pulsanti di un dialogo standard.

Il servizio di salvataggio restituisce una chiave invece di una frase inglese, e l'editor è l'unico posto che trasforma un risultato in parole. La riga di log resta in una sola lingua di proposito, perché a uno sviluppatore che legge un log alle tre di notte un messaggio tradotto non serve a niente.

Eseguilo in inglese, poi in tedesco, poi apri una finestra di messaggio il cui pulsante di conferma arriva dal tuo override delle etichette di sistema e non dal valore predefinito del framework. Cancella una chiave dal file tedesco e la ricerca ricade sul valore neutro invece di lasciare il vuoto.

Quello che consegni è il file tedesco con chiavi identiche, una frase formattata da un segnaposto, un servizio che restituisce una chiave invece di prosa, un'etichetta di sistema Wisej sovrascritta e la nota che spiega i tre tipi di testo.

Lab tre: aggiungi il file di stringhe tedesco, formatta la frase con segnaposto per la cultura attiva, restituisci una chiave di risultato dal servizio di salvataggio e sovrascrivi un'etichetta di sistema.

Modulo 4. GlobalDesk ha ormai risorse tedesche, una variante tedesca nel designer e un'etichetta di sistema tedesca. Quello a cui non sa ancora rispondere è in quale lingua debba girare questa specifica sessione.

La cultura di una sessione può venire dalla preferenza del browser, da un valore fisso nella configurazione dell'applicazione, da un parametro nell'indirizzo o da un selettore che usa l'utente. Qualunque di questi vinca, decidila una volta sola all'inizio della sessione invece di ricavarla di nuovo in ogni schermata.

La proprietà della cultura corrente è la cultura della sessione corrente. Un campo statico che contiene una cultura sarebbe invece la cultura dell'intero processo server, e quindi di ogni altro utente collegato: è l'errore più costoso di tutta questa materia.

Impostare la cultura su automatico fa partire ogni sessione dalla preferenza del browser. Impostare un nome fisso inchioda un solo locale, il che va bene per una prova di test o per un prodotto venduto in un unico mercato. Il selettore assegna una cultura ottenuta per nome.

Iscriviti una volta sola all'evento di cambio cultura e lascia che sia un unico handler a fare tutto il lavoro di riparazione. Riapplica le didascalie che arrivano dalle risorse, riformatta la data, il numero e l'importo e ricostruisce l'editor localizzato nel designer, così ogni tipo di testo resta coerente.

Quattro tipi di testo, quattro destini diversi. I controlli creati dopo il cambio si adeguano da soli. Le didascalie già sullo schermo vanno riapplicate. I valori formattati vanno ricalcolati. Le schermate localizzate nel designer vanno ricreate, perché le loro risorse sono state lette quando sono state costruite.

Viene scelto il tedesco, e il titolo, la navigazione e le tre anteprime formattate cambiano tutti. L'editor resta in inglese finché non parte la chiamata di ricreazione. Quello scarto, tra le parti che si adeguano subito e quelle che non lo fanno, è il difetto che questo modulo esiste per prevenire.

Un parametro di lingua nell'indirizzo apre una sessione in tedesco mentre il browser successivo resta in inglese. Due culture vive nello stesso processo nello stesso momento sono esattamente il comportamento che un campo di cultura statico distruggerebbe per entrambe.

Lab quattro: imposta la cultura su automatico, aggiungi il selettore della lingua, scrivi l'handler di cambio cultura che riapplica le didascalie e riformatta i valori, e ricrea l'editor.

Localizzazione in Wisej.NET, Modulo 5. GlobalDesk parla già arabo. Questo modulo fa in modo che si legga come l'arabo, che è un problema di layout più che di traduzione.

Il Modulo 4 ha finito le parole. Una sessione araba comincia comunque dal bordo sbagliato dello schermo, così l'occhio cade sull'ultima cosa invece che sulla prima. E le didascalie tedesche vengono già tagliate dentro un pannello misurato sull'inglese.

Due proprietà, due compiti diversi. La proprietà RightToLeft cambia la direzione dentro un controllo, ed è così che si ribaltano il testo e il suo allineamento. La proprietà RightToLeftLayout specchia i figli diretti di un contenitore, ed è così che si ribalta la disposizione stessa.

Una sola impostazione decide per tutta l'applicazione. Configurare la direzione su automatico la deriva dalla cultura della sessione, così nessuna schermata deve testare da sé un nome di cultura. Un test del genere in una schermata è un test che qualcuno dimenticherà di aggiungere alla schermata successiva.

La specchiatura viene bene solo se il layout è libero di muoversi. Aggancio, ancoraggio, dimensionamento automatico, un layout a contenitore e dimensioni minime sensate sostituiscono le posizioni fisse in pixel. E un'eccezione deliberata da sinistra a destra mantiene leggibile qualcosa come un codice cliente, perché un identificatore non è prosa.

Poi mettilo alla prova sul serio: testo corto, una traduzione decisamente più lunga, una finestra stretta, una cultura da destra a sinistra e contenuto misto, come un'etichetta araba accanto a un codice prodotto latino. Ognuno di questi casi rompe un'assunzione diversa.

Nel browser il selettore sceglie l'arabo, la direzione dell'applicazione segue la cultura della sessione e una sola proprietà del contenitore specchia la dashboard. Qui niente è stato globale: la direzione, come la cultura, appartiene solo a questa sessione.

Il giro pseudo-localizzato mette allo scoperto ciò che l'inglese nascondeva, e il layout ricostruito smette di tagliare. La griglia dei contatti viene verificata e il suo comportamento messo a verbale invece che dato per scontato, perché una griglia ha regole di colonna e di allineamento tutte sue da controllare.

Lab cinque: aggiungi l'arabo con la direzione automatica, specchia entrambe le schermate con i figli che ereditano, aggiungi un'eccezione da sinistra a destra commentata, rendi il layout a prova di taglio e scrivi la lista di test a cinque casi.

Modulo 6. GlobalDesk ha già quattro file di risorse. La lingua da aggiungere qui è l'italiano, e farlo con due schede dell'editor affiancate significa confrontare a occhio gli elenchi di chiavi, mentre il traduttore madrelingua italiano non può nemmeno aprire la soluzione.

A questo punto si rompono tre cose: confrontare i file a occhio, rispondere a quanta traduzione manca ancora e consegnare le stringhe a qualcuno che non ha mai aperto un file di risorse e non dovrebbe doverlo fare.

Uno strumento di gestione delle risorse mette le chiavi sulle righe e ogni lingua sulle colonne, così una lacuna è una cella vuota invece di qualcosa che devi accorgerti di notare. Wisej.NET memorizza il testo in file di risorse .NET standard, quindi non serve nessun supporto speciale.

Quello che lo strumento scrive è un normale file di risorse italiano, la colonna nuova del progetto: esattamente le chiavi del file neutro, i valori tradotti, un commento su quelle che erano ambigue e una voce lasciata vuota di proposito, per poter dimostrare il fallback.

Il giro stesso ha una forma. Aggiungi la lingua, filtra sulle sole voci non tradotte, scrivi una bozza dei valori, marca il nome del prodotto come invariante così nessuno lo traduce, poi rivedi. In questo giro la revisione si guadagna il posto: la bozza aveva scambiato due segnaposto.

La traduzione automatica produce una bozza, non un risultato. Rivedi terminologia, segnaposto, punteggiatura, acceleratori da tastiera e nomi di prodotto, e leggi la differenza nel controllo di versione prima di consegnare il giro, esattamente come per qualsiasi altra modifica all'applicazione.

Fidati del filtro, poi verificalo per conto tuo. Salta le chiavi invarianti, confronta ogni ricerca fatta nella colonna italiana con il valore neutro ed elenca ogni chiave che sta ancora ricadendo sull'inglese, invece di dare per scontato che quella colonna sia completa.

Con l'applicazione in esecuzione nella cultura italiana, quella appena tradotta, le didascalie arrivano dal file di risorse italiano, mentre la data, la quantità e l'importo vengono formattati per la cultura attiva nel momento in cui sono mostrati. Sono due meccanismi separati che fanno due lavori separati.

Uno sviluppatore e due lingue possono vivere nell'editor. Un team con più lingue vuole lo strumento di gestione delle risorse. I traduttori che non sono sviluppatori hanno bisogno di un giro di esportazione e importazione, oppure di un servizio di gestione delle traduzioni.

Lab sei: completa una colonna italiana senza nessuna chiave non tradotta, commenta tre chiavi ambigue, marca le invarianti, rivedi la differenza del file di risorse e scrivi la nota sul flusso di lavoro.

Localizzazione in Wisej.NET, Modulo 7, il capstone. GlobalDesk parla già due lingue. Quello che chiede la produzione è una domanda diversa: se mentre lo fa si comporta in modo prevedibile.

Quattro domande a cui l'applicazione deve rispondere sempre allo stesso modo. Da dove arriva una certa stringa. Quale cultura è attiva in questo momento. Che cosa succede quando una chiave manca. E che cosa fa un cambio di lingua alle schermate già aperte.

Separa prima il testo per proprietario. Le tue stringhe di prodotto. Le etichette di sistema che fornisce Wisej.NET, sovrascritte in un file di risorse tutto loro. E il testo diagnostico, che resta in una sola lingua per gli sviluppatori, perché un log lo legge il team e non il cliente.

Un servizio di localizzazione centralizza queste scelte senza sostituire niente di quello che .NET già fa. Un solo ResourceManager. Una ricerca che restituisce la chiave tra parentesi quadre invece di niente. E una formattazione che legge la cultura corrente a ogni chiamata, invece di catturarla una volta e tenersela.

Poi porta la lingua fuori dalla schermata e fuori dal modello. Tieni la data come data e l'importo come decimale, restituisci uno stato come valore di enumerazione invece che come parola tradotta, e lascia che sia il servizio a trasformare tutto questo nella didascalia che l'utente legge alla fine.

Qui testare è una matrice scritta, non un'occhiata a una schermata. Neutro, tradotto, una regione che ricade sulla sua lingua, una chiave mancante, valori formattati, un cambio a runtime, stringhe lunghe di proposito, da destra a sinistra e le etichette di sistema del framework.

Il giro pseudo-localizzato allunga ogni valore e lo mette tra parentesi quadre. Tutto ciò che continua a mostrare inglese normale non è mai arrivato a un file di risorse, e tutto ciò che viene tagliato con il testo più lungo verrà tagliato anche in tedesco. Entrambe le scoperte arrivano gratis dallo stesso giro.

La dimostrazione sono quattro prove: didascalie tedesche accanto a valori formattati dalla cultura, un dialogo di sistema Wisej nella stessa lingua, una chiave mancante che ricade in modo visibile sulla propria chiave e infine il layout da destra a sinistra specchiato.

Lab sette: costruisci il servizio di localizzazione, restituisci valori invece di parole dal dominio, produci il set pseudo-localizzato, completa la matrice di test e pubblica mantenendo le cartelle delle culture.