Quando si sviluppa un’applicazione che potrebbe essere usata in diverse parti del mondo, occorre prevedere una localizzazione dell’interfaccia. Se tratta quindi di mostrare componenti, messaggi e altre parti del programma nella giusta lingua. Certo, ci sono molti altri problemi da affrontare quando si parla di localizzazione, ma l’interfaccia e’ quello che, a mio avviso, tra tutti richiede il maggior tempo per gestito.

Non esiste un metodo universalmente riconosciuto e usato per fare tutto questo in .NET, anche se ci sono strumenti e pattern più o meno complessi il cui uso e’ pertinente a determinate situazioni.

WINFORM – LA VIA FACILE

L’articolo MSDN relativo e’ questo: Walkthrough: Localizing Windows Forms.
In pratica, se occorre localizzale label, menu e altri elementi di un form, il compito e’ semplice e viene fatto tutto grazie all’editor di Visual Studio. Si disegna la propria finestra e si impostano tutte le etichette standard, quelle che devono apparire di default. Si passano poi a definire le traduzioni per un certo linguaggio impostando la proprieta’ Language del form e modificando le etichette dei controlli. Il sistema, in fase di esecuzione dell’applicativo, provvedera’ a selezionare uno dei linguaggi personalizzati basandosi su quello del sistema. Se invece si vuole impostare una lingua, occorre agire su Thread.CurrentThread.CurrentUICulture. Tutto funziona grazie ad un file di risorse, creato automaticamente dall’editor, per ogni finestra  / controllo che localizzo con questo medoto.
Approccio molto simile per ottenere delle stringhe localizzate, utili per MessageBox e altre informazioni da mostrare all’utente. Si crea un file delle risorse (quello di default e quelli specifici per le lingue gestite), si inseriscono in questi file le coppie chiave/valore (nel valore c’e’ il testo tradotto) e poi da codice si usa un ResourceManager, legato al file delle risorse creato, per ottenere i valori delle chiavi richieste in base alla cultura corrente.
Pro di questo metodo l’estrema facilita’ di implementazione e la scrittura di poco codice, contro il fatto che occorre ricompilare e ridistribuire il progetto ad ogni cambiamento dei testi e che le risorse localizzate non risiedono in un unico punto ma sono sparse all’interno dell’applicazione.

Per localizzare anche i componenti che mostrano date e valute, occorre agire su Thread.CurrentThread.CurrentCulture, seguendo quanto scritto in How to: Set the Culture and UI Culture for Windows Forms Globalization.

ASP.NET – RESOURCE PROVIDER PER TUTTI

ASP.NET 2.0 Localization Features: A Fresh Approach to Localizing Web Applications: l’articolo di riferimento da leggere per la localizzazione delle applicazioni un ASP.NET 2.0
Introduction to Localization in ASP.NET 2.0: questo articolo, che attinge a larga mano dal precedente, espone alcuni concetti di base della localizzazione in ASP.NET 2.0, parlando di assembly delle risorse (gli stessi utilizzati in maniera trasparente nell’approccio WinForm precedente), spiega come impostare una pagina in base alla lingua predefinita nel browser dell’utente, fa una panoramica su risorse globali (GetGlobalResourceObject) e risorse locali (GetLocalResourceObject), su come funziona il Resource Fallback, su come assegnare via markup code il testo dei controlli nella pagina asp grazie alle Implicit ed Explicit Resource Expressions.

Punti di debolezza di questi approcci, il fatto che i resource file sono gestiti automaticamente e non si possono condividere, ad esempio, con una versione WinForm della stessa applicazione. Inoltre, come il precedente, ogni cambiamento delle risorse necessita di una ricompilazione e ridistribuzione di parti dell’applicazione.

Continue reading ‘Pattern per la localizzazione delle applicazioni WinForm, ASP.NET e WPF’ »