Spiegazione dei concetti fondamentali di MUI

• Prerequisito per MUI
• Separazione del codice sorgente da risorse specifiche del linguaggio
  • I primi giorni: il codice e le risorse vivono insieme
  • Separazione logica del codice e delle risorse localizzabili
  • Separazione fisica di codice e risorse
• Caricamento dinamico di risorse specifiche del linguaggio
• Compilazione di applicazioni MUI

Prerequisito per MUI

Il prerequisito di base per la creazione di un'applicazione conforme a MUI per Windows Vista e oltre consiste nel progettare l'applicazione in conformità alle linee guida per la globalizzazione di Windows.

Separazione del codice sorgente da risorse specifiche del linguaggio

Una delle premesse fondamentali della tecnologia MUI è la separazione del codice sorgente dell'applicazione da risorse specifiche del linguaggio, per consentire scenari multilingue nelle applicazioni in modo più efficiente. La separazione del codice e delle risorse è stata ottenuta tramite meccanismi diversi e in gradi diversi nel tempo, come descritto nelle sezioni seguenti. Ogni metodo ha fornito diversi gradi di flessibilità nella compilazione, distribuzione e manutenzione dell'applicazione.

La soluzione consigliata per le applicazioni conformi a MUI è l'ultimo metodo descritto qui, ovvero la separazione fisica del codice sorgente e delle risorse dell'applicazione, con le risorse stesse ulteriormente suddivise in un file per ogni linguaggio supportato per la massima flessibilità nella creazione, distribuzione e manutenzione.

I primi giorni: il codice e le risorse vivono insieme

Inizialmente, le applicazioni localizzate sono state create modificando il codice sorgente e modificando le risorse (in genere stringhe) nel codice stesso e ricompilando le applicazioni. Ciò significa che per produrre una versione localizzata, è necessario copiare il codice sorgente originale, tradurre gli elementi di testo (risorse) all'interno del codice sorgente e ricompilare il codice. L'immagine seguente mostra il codice dell'applicazione con testo che deve essere localizzato.

Anche se questo approccio consente la creazione di applicazioni localizzate, presenta anche svantaggi significativi:

• Richiede più versioni del codice sorgente, almeno una per la lingua di origine e una per ognuna delle lingue di destinazione. Ciò crea problemi significativi durante la sincronizzazione delle diverse versioni della lingua dell'applicazione. In particolare, quando un difetto deve essere corretto nel codice, il difetto deve essere corretto in ogni copia del codice sorgente (uno per ogni lingua).
• È anche estremamente soggetto a errori perché richiedeva localizzatori, che non sono sviluppatori, di apportare modifiche nel codice sorgente, creando così un notevole rischio in termini di integrità del codice.

La combinazione di questi svantaggi rende questa proposta estremamente inefficiente ed è stato necessario un modello migliore.

Separazione logica del codice e delle risorse localizzabili

Un miglioramento significativo rispetto al modello precedente è la separazione logica del codice e delle risorse localizzabili per un'applicazione. In questo modo il codice viene isolato dalle risorse e si garantisce che il codice rimanga invariato quando le risorse vengono modificate dalla localizzazione. Dal punto di vista dell'implementazione, le stringhe e altri elementi dell'interfaccia utente vengono archiviate nei file di risorse, che sono relativamente facili da tradurre e sono separate logicamente dalle sezioni di codice.

Idealmente, l'aggiunta del supporto per qualsiasi lingua specifica può essere semplice quanto la traduzione delle risorse localizzabili in questa nuova lingua e l'uso di queste risorse tradotte per creare una nuova versione localizzata dell'applicazione, senza richiedere alcuna modifica del codice. L'immagine seguente illustra come separare logicamente il codice e le risorse localizzabili all'interno di un'applicazione.

Questo modello consente una creazione più semplice di versioni localizzate di un'applicazione ed è un miglioramento significativo rispetto al modello precedente. Questo modello, implementato tramite l'uso di strumenti di gestione delle risorse, è stato di grande successo nel corso degli anni ed è ancora comunemente usato da molte applicazioni oggi. Tuttavia, presenta svantaggi significativi:

• Anche se le risorse localizzate e il codice sono separati logicamente, il codice e le risorse localizzate vengono ancora aggiunti fisicamente in un file eseguibile. In particolare, la gestibilità è ancora problematica perché lo stesso difetto del codice (identico in tutte le versioni del linguaggio) richiede una patch per ogni linguaggio. Pertanto, se si invia l'applicazione in 20 lingue, è necessario emettere una patch di servizio 20 volte (una per ogni lingua), anche se il codice è fisso una sola volta.
• La distribuzione e l'uso di applicazioni multilingue non sono adeguatamente supportati da questo modello. Questo può essere un problema significativo negli scenari OEM e aziendali. Ad esempio, se un computer deve essere condiviso tra due utenti che usano lingue diverse, le applicazioni dovranno essere installate due volte con questo modello e sarà necessario abilitare un meccanismo per alternare tra le due installazioni. Ciò presuppone che non siano presenti dipendenze aggiuntive che impediscono anche l'implementazione di questo scenario. L'immagine seguente mostra un esempio di un singolo difetto di codice che richiede due patch.

È chiaro che anche se questo modello funziona bene in alcuni scenari, le relative limitazioni per le applicazioni multilingue e le relative distribuzioni possono essere molto problematiche.

Una variante di questo modello che riduce alcuni dei problemi relativi alle applicazioni multilingue è il modello in cui le risorse localizzabili contengono un set di risorse linguistiche diverse. Questo modello ha una codebase comune e diverse risorse per linguaggi diversi nella stessa applicazione. Ad esempio, un'applicazione può essere fornita con inglese, tedesco, francese, spagnolo, olandese e italiano nello stesso pacchetto. L'immagine seguente mostra un'applicazione che contiene più risorse della lingua.

Questo modello semplifica il servizio dell'applicazione quando è necessario correggere un difetto del codice, che è un miglioramento, ma non migliora rispetto ai modelli precedenti quando si tratta di supportare linguaggi aggiuntivi. In questo caso, è comunque necessario rilasciare una nuova versione dell'applicazione e tale versione è potenzialmente complicata dalla necessità di garantire che tutte le risorse del linguaggio siano sincronizzate all'interno della stessa distribuzione.

Separazione fisica di codice e risorse

Il passaggio evolutivo successivo consiste nel separare fisicamente codice e risorse. In questo modello le risorse vengono astratte dal codice e separate fisicamente in file di implementazione diversi. In particolare, ciò significa che il codice può diventare veramente indipendente dal linguaggio; lo stesso codice fisico viene effettivamente fornito per tutte le versioni localizzate di un'applicazione. L'immagine seguente illustra che il codice e le risorse localizzabili devono essere fisicamente separati.

Questo approccio presenta diversi vantaggi rispetto agli approcci precedenti:

• La distribuzione di soluzioni multilingue è notevolmente semplificata. L'aggiunta del supporto per qualsiasi lingua specifica richiede solo la spedizione e l'installazione di un nuovo set di risorse linguistiche per questa lingua specifica. Ciò è particolarmente importante quando le risorse linguistiche non sono tutte disponibili contemporaneamente. Con questo modello, è possibile distribuire un'applicazione in un set di linguaggi di base e aumentare il numero di lingue supportate nel tempo senza dover modificare o ridistribuire il codice effettivo. Questo vantaggio è ulteriormente esteso da un meccanismo di fallback che consente la localizzazione parziale delle applicazioni e dei componenti di sistema in una determinata lingua assicurando che le risorse non trovate in questa lingua preferita "fallback" a un altro linguaggio compreso anche dagli utenti. In generale, questo modello consente di ridurre il notevole carico di lavoro che le aziende globali devono affrontare nella distribuzione di applicazioni in più lingue, in quanto consente la distribuzione di singole immagini in modo molto più efficace.
• La funzionalità è stata migliorata. Un difetto del codice deve essere corretto e distribuito una sola volta, perché il codice è completamente indipendente dalla localizzazione. Con questo modello, l'emissione di una correzione per un difetto del codice, purché la modifica non sia correlata all'interfaccia utente, è molto più semplice e conveniente rispetto a qualsiasi modello precedente.

Caricamento dinamico di risorse specifiche del linguaggio

I concetti fondamentali di MUI per separare fisicamente il codice sorgente dalle risorse specifiche del linguaggio e la creazione di un file binario core indipendente dal linguaggio per un'applicazione, configurano essenzialmente un'architettura che consente di implementare il caricamento dinamico di risorse specifiche della lingua in base alle impostazioni della lingua utente e del sistema.

Il codice sorgente dell'applicazione incluso nel file binario core indipendente dal linguaggio può usare le API MUI nella piattaforma Windows per astrarre la selezione della lingua dell'interfaccia utente di visualizzazione appropriata per un determinato contesto. MUI supporta questa operazione:

• Creazione di un elenco con priorità delle lingue dell'interfaccia utente in base alle impostazioni a livello di sistema, utente e applicazione, a livello di utente e a livello di sistema.
• Implementazione di un meccanismo di fallback che sceglie un candidato appropriato da questo elenco di lingue con priorità, in base alla disponibilità delle risorse localizzate.

I vantaggi del caricamento dinamico delle risorse dell'interfaccia utente con fallback con priorità sono:

• Consente la localizzazione parziale delle applicazioni e dei componenti di sistema in una determinata lingua, poiché le risorse non trovate in questa lingua preferita eseguiranno automaticamente il fallback alla lingua successiva nell'elenco con priorità.
• Consente scenari come il passaggio dinamico da una lingua a un'altra.
• Consente di creare immagini a distribuzione singola a livello di area o in tutto il mondo che coprono un set di lingue per oem e aziende.

Compilazione di applicazioni MUI

Le sezioni precedenti illustrano le opzioni per separare il codice sorgente dalle risorse specifiche della lingua e il vantaggio risultante nell'usare le API della piattaforma Windows di base per caricare in modo dinamico le risorse localizzate. Anche se si tratta di linee guida, è opportuno sottolineare anche che non esiste un modo prescrittivo specifico per sviluppare un'applicazione MUI per la piattaforma Windows.

Gli sviluppatori di applicazioni hanno la scelta completa di come gestiscono varie impostazioni del linguaggio dell'interfaccia utente, opzioni di creazione delle risorse e metodi di caricamento delle risorse. Gli sviluppatori possono valutare le linee guida fornite in questo documento e scegliere una combinazione che soddisfi i requisiti e l'ambiente di sviluppo.

La tabella seguente riepiloga le diverse opzioni di progettazione disponibili per gli sviluppatori di applicazioni che desiderano creare un'applicazione MUI per la piattaforma Windows.

Impostazioni della lingua dell'interfaccia utente	Creazione di risorse	Caricamento delle risorse
Seguire le impostazioni della lingua dell'interfaccia utente nel sistema operativo${REMOVE}$	Linguaggio singolo in un file binario di risorse diviso (tecnologia di risorse MUI) -oppure- Più lingue in un file binario di risorse non suddiviso	L'applicazione chiama le funzioni standard di caricamento delle risorse. Le risorse vengono restituite nelle lingue corrispondenti alle impostazioni del sistema operativo.
	Meccanismo di risorse specifico dell'applicazione	L'applicazione chiama l'API MUI per recuperare le lingue dell'interfaccia utente preferite dai thread o le lingue dell'interfaccia utente preferite dal processo dal sistema operativo e usare queste impostazioni per caricare le proprie risorse.
Impostazioni della lingua dell'interfaccia utente specifiche dell'applicazione${REMOVE}$	Linguaggio singolo in un file binario di risorse diviso -oppure- Più lingue in un file binario di risorse non diviso	L'APPLICAZIONE chiama l'API MUI per impostare lingue dell'interfaccia utente specifiche dell'applicazione o lingue dell'interfaccia utente preferite e quindi chiama funzioni di caricamento delle risorse standard. Le risorse vengono restituite nelle lingue impostate dalle lingue dell'applicazione o del sistema. -oppure- Le risorse del probe dell'applicazione in un linguaggio specifico e gestiscono la propria estrazione di risorse dai dati binari recuperati.
	Meccanismo di risorsa specifico dell'applicazione	L'applicazione gestisce il caricamento di risorse personalizzato.