MUI 的必要條件
針對 Windows Vista 和更新版本建置符合 MUI 規範應用程式的基本先決條件，是依照 Windows 全球化指導方針來設計應用程式。
將原始碼與語言特定資源區隔
MUI 技術的其中一個基本前提是將應用程式原始程式碼與語言特定資源分開，以更有效率地在應用程式中啟用多語系案例。 程式代碼和資源分離已透過不同的機制和不同程度來達成，如下列各節所述。 每個方法在建置、部署及維護應用程式方面提供了不同程度的彈性。
建議的 MUI 相容應用程式解決方案是此處概述的最後一種方法，也就是應用程式原始程式碼和資源的實際分隔，資源本身會進一步細分為每個支援語言的一個檔案，以取得建置、部署及服務的最大彈性。
早期：程式代碼和資源共同存在
一開始，當地語系化應用程式是藉由編輯原始程式碼和變更程式碼本身中的資源（通常是字串）並重新編譯應用程式所建立。 這表示要產生本地化的版本，必須複製原始原始原始程式碼、翻譯原始程式碼內的文字（resources）元素，然後重新編譯程式碼。 下圖顯示需要當地語系化之文字的應用程式程序代碼。
雖然此方法可建立本地化的應用程式，但也有顯著的缺點：
- 它需要多個版本的原始程式碼，至少一個用於來源語言，一個用於每個目標語言。 這會導致應用程式不同語言版本之間的同步嚴重問題。 特別是當程式代碼中需要修正瑕疵時，必須在原始程式碼的每個復本中修正瑕疵（每種語言一個）。
- 由於需要當地語系化人員（不是開發人員）在原始程式碼中進行修改，因此在程式碼完整性方面造成了相當大的風險，因此很容易出錯。
這些缺點的組合使這個方案極其低效，因此需要更好的模型。
以邏輯方式分隔程式代碼和可本地化的資源
前一個模型的一個顯著改進是，應用程式的程式代碼與可本地化資源之間的邏輯上的分離。 這會隔離程式代碼與資源，並確保當當地語系化變更資源時，程式代碼會維持不變。 從實作的觀點來看，字串和其他使用者介面元素會儲存在資源檔中，這相對容易轉譯，而且在邏輯上與程式代碼區段分開。
在理想情況下，新增任何指定語言的支援可以像將可本地化的資源翻譯成這個新語言一樣簡單，並使用這些翻譯的資源來建立新的當地語系化版本的應用程式，而不需要修改任何程序代碼。 下圖說明如何在應用程式中以邏輯方式分隔程式代碼和可本地化的資源。
此模型可讓您更輕鬆地建立應用程式的當地語系化版本，而且對先前的模型有顯著的改善。 此模型是透過使用資源管理工具實作的，多年來一直非常成功，目前許多應用程式仍普遍使用。 不過，它確實有顯著的缺點：
- 雖然以邏輯方式分隔，但程式代碼和本地化的資源仍會實際聯結在一個可執行檔中。 特別是，可維修性仍然有問題，因為每種語言都需要針對相同的程式代碼缺失進行修補（在所有語言版本中都相同）。 因此，如果一個以 20 種語言傳送應用程式，服務修補程式必須發出 20 次（每個語言一個），即使程式碼只固定一次。
- 此模型未充分支援多語系應用程式的散發和使用。 這在 OEM 和企業案例中可能是一個重大問題。 例如，如果計算機要使用不同語言在兩個使用者之間共用，則必須使用此模型安裝兩次應用程式，然後必須啟用某些機制，才能在兩個安裝之間替代。 這假設沒有任何額外的相依性可防止實作此案例。 下圖顯示需要兩個修補程式的單一程式代碼缺失範例。
很明顯，雖然此模型在某些案例中運作良好，但其多語系應用程式及其部署的限制可能會非常有問題。
這種模型的變體緩解了某些多語系應用程式的問題，該模型的在於當地化資源包含一組不同的語言資源。 此模型具有通用的程式代碼基底，以及相同應用程式中不同語言的數個資源。 例如，應用程式可以在相同的套件中隨附英文、德文、法文、西班牙文、荷蘭文和義大利文。 下圖顯示包含多種語言資源的應用程式。
此模型可讓您更輕鬆地在需要修正程式碼瑕疵時為應用程式提供服務，這是一項改進，但在支援其他語言時不會改善先前的模型。 在此情況下，仍然需要發布新版本的應用程式（且該版本可能會變得複雜，因為需要確保所有語言資源在相同的發行版本中同步）。
以實體方式分隔程式代碼和資源
下一個進化步驟是實際分隔程式代碼和資源。 在此模型中，資源會從程序代碼中擷取，並在不同的實作檔案中實際分隔。 特別是，這表示程式代碼可以真正獨立語言;應用程式的所有當地語系化版本實際上都隨附相同的實體程序代碼。 下圖說明必須實際分隔程式代碼和可本地化的資源。
這種方法比先前的方法有數個優點：
- 多語系解決方案的部署已大幅簡化。 新增任何指定語言的支援只需要傳送並安裝一組新的特定語言資源。 當語言資源並非全部同時可用時，這特別重要。 透過此模型，人們可以使用一組核心語言來部署應用程式，並隨著時間增加支援的語言數目，而不需要修改或重新部署實際程序代碼。 此優勢更進一步擴展了回退機制，這個機制允許應用程式和系統元件在特定語言的部分本地化，方法是確保在慣用語言中找不到的資源能夠「回退」到使用者也能理解的另一種語言。 整體而言，此模型有助於減輕全球公司以多種語言部署應用程式時所面臨的巨大負擔，因為它能夠以更有效率的方式進行單一映射部署。
- 服務性已改善。 程序代碼缺失只需要修正並部署一次，因為程式代碼完全與當地語系化無關。 有了此模型，只要變更與UI無關，就發出程式代碼瑕疵的更正，比先前任何模型都簡單且符合成本效益。
動態載入語言特定資源
實際分隔原始程式碼與語言特定資源，併為應用程式建置語言中性核心二進位檔的 MUI 基本概念，基本上設定了一種架構，有利於根據使用者和系統語言設定實作語言特定資源的動態載入。
應用程式的原始程式碼捆綁進語言中性核心二進位檔後，可以利用 Windows 平台中的 MUI API 來抽象化選擇適合特定情境的顯示使用者介面語言。 MUI 透過以下方式支援：
- 根據系統、使用者和應用層級、用戶層級和系統層級設定，建構顯示使用者介面語言的優先順序清單。
- 實作備援機制，根據本地化資源的可用性，從這個優先順序的語言清單中選擇適當的候選語言。
以優先順序遞補動態載入使用者介面資源的優點如下：
- 它允許特定語言中部分當地語系化應用程式和系統元件，因為在此慣用語言中找不到的資源會自動回復到優先順序清單上的下一個語言。
- 它可啟用從一種語言動態切換至另一種語言等案例。
- 它允許建立涵蓋 OEM 和企業一組語言的區域或全球單一部署映像。
建置 MUI 應用程式
前幾節概述將原始程式碼與語言特定資源分開的選項，以及能夠利用核心 Windows 平臺 API 動態載入本地化資源的結果優點。 雖然這些都是指導方針，但也應該指出，沒有特定的規範性方法來開發適用於Windows 平臺的 MUI 應用程式。
應用程式開發人員在處理各種使用者介面語言設定、資源建立選項和資源載入方法的方式方面有完整的選擇。 開發人員可以評估本檔中提供的指導方針，並選擇符合其需求和開發環境的組合。
下表摘要說明應用程式開發人員想要為 Windows 平臺建立 MUI 應用程式的不同設計選項。
| 使用者介面語言設定 | 資源建立 | 資源載入 |
|---|---|---|
| 遵循作業系統中的 UI 語言設定 |
拆分資源二進位檔中的單一語言（MUI 資源技術） -或- 非分割資源二進位檔中的多種語言 |
應用程式會呼叫標準資源載入函式。 資源會以符合作系統設定的語言傳回。 |
| 應用程式特定的資源機制 |
應用程式會呼叫 MUI API，從作業系統擷取執行緒慣用 UI 語言或進程慣用 UI 語言，並使用這些設定來載入其自身的資源。 |
|
| 應用程式特定的 UI 語言設定${REMOVE}$ |
分割資源二進位檔中的單一語言 -或- 非分割資源二進位檔中的多種語言 |
應用程式會呼叫 MUI API 來設定應用程式特定的 UI 語言或行程慣用 UI 語言，然後呼叫標準資源載入函式。 資源會以應用程式或系統語言所設定的語言傳回。 -或- 應用程式會以特定語言探查資源，並從擷取的二進位數據處理自己的資源擷取。 |
| 應用程式特定的資源機制 |
應用程式會管理自己的資源載入。 |