Concetti fondamentali di MUI illustrati

• Prerequisito per l' MUI
• Separazione del codice sorgente da risorse specifiche della lingua
  • I primi giorni: codice e risorse vivono insieme
  • separare logicamente il codice e le risorse localizzabili
  • Separare fisicamente 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 della lingua

Una delle premesse fondamentali della tecnologia MUI è la separazione del codice sorgente dell'applicazione dalle 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 compilazione, 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ò significava che per produrre una versione localizzata, uno doveva 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 (una per lingua).
• È anche estremamente soggetto a errori in quanto 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 e era 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. Questo isola il codice dalle risorse e 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 archiviati nei file di risorse, che sono relativamente facili da tradurre e sono separati logicamente dalle sezioni di codice.

Idealmente, l'aggiunta del supporto per qualsiasi lingua specifica può essere semplice come 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, ha avuto successo nel corso degli anni ed è ancora comunemente usato da molte applicazioni oggi. Tuttavia, presenta svantaggi significativi:

• Sebbene siano separati logicamente, il codice e le risorse localizzate sono ancora fisicamente uniti in un unico file eseguibile. In particolare, la serviceability è 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, una patch di servizio deve essere rilasciata 20 volte (una per ogni lingua), anche se il codice viene corretto una sola volta.
• La distribuzione e l'uso di applicazioni multilingue non sono adeguatamente supportate 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 quindi sarà necessario abilitare un meccanismo per alternare tra le due installazioni. Ciò presuppone che non siano presenti dipendenze aggiuntive che impediscono l'implementazione di questo scenario. L'immagine seguente mostra un esempio di un singolo difetto di codice che richiede due patch.

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

Una variante di questo modello che risolve alcuni problemi di 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 linguistiche.

Questo modello semplifica la manutenzione 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 assicurarsi che tutte le risorse della lingua 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 separati fisicamente.

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 del linguaggio non sono tutte disponibili contemporaneamente. Con questo modello, è possibile distribuire un'applicazione in un set di linguaggi principali 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 ritorno che consente la localizzazione parziale delle applicazioni e dei componenti di sistema in una data lingua, assicurando che le risorse non trovate in questa lingua preferita ricadano su un'altra lingua che gli utenti comprendono. 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 facilità di servizio è 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, a condizione che 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 di separano fisicamente il codice sorgente dalle risorse specifiche del linguaggioe la creazione di un file binario core indipendente dal linguaggio per un'applicazione, configura essenzialmente un'architettura che consente di implementare il caricamento dinamico di risorse specifiche della lingua in base alle impostazioni della lingua utente e di 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 funzionalità in base a:

• Creazione di un elenco con priorità delle lingue dell'interfaccia utente visualizzate 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à di risorse localizzate.

I vantaggi del caricamento dinamico delle risorse dell'interfaccia utente con un fallback prioritario 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 principali per caricare in modo dinamico le risorse localizzate. Anche se si tratta di linee guida, si dovrebbe anche sottolineare 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 cercano di 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 delle risorse MUI) -o- Più linguaggi in un file binario di risorse non diviso	L'applicazione chiama 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 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 -o- Più linguaggi 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 dai processi e quindi chiama le funzioni di caricamento delle risorse standard. Le risorse vengono restituite nelle lingue impostate dalle lingue dell'applicazione o del sistema. -o- L'applicazione sonda le risorse in una lingua specifica e gestisce l'estrazione delle proprie risorse dai dati binari recuperati.
	Meccanismo di risorse specifico dell'applicazione	L'applicazione gestisce il caricamento delle proprie risorse.