Objaśnienie podstawowych pojęć dotyczących interfejsu MUI

• wymagania wstępne dotyczące interfejsu MUI
• oddzielenie kodu źródłowego od zasobów specyficznych dla języka
  • Wczesne dni: kod i zasoby działają razem
  • logiczne oddzielenie kodu i zasobów lokalizowalnych
  • fizycznie oddzielający kod i zasoby
• dynamiczne ładowanie zasobów specyficznych dla języka
• tworzenie aplikacji MUI

Wymaganie wstępne dla MUI

Podstawowym wymaganiem wstępnym do utworzenia aplikacji zgodnej ze standardem MUI dla systemu Windows Vista i poza nią jest zaprojektowanie aplikacji zgodnie z wytycznymi globalizacji systemu Windows .

Separacja kodu źródłowego z zasobów specyficznych dla języka

Jednym z podstawowych założeń technologii MUI jest oddzielenie kodu źródłowego aplikacji od zasobów specyficznych dla języka, aby umożliwić bardziej efektywne wielojęzyczne rozwiązania w aplikacjach. Rozdzielenie kodu i zasobów zostało osiągnięte za pomocą różnych mechanizmów i różnych stopni w czasie, jak opisano w poniższych sekcjach. Każda metoda zapewniała różny stopień elastyczności w tworzeniu, wdrażaniu i obsłudze aplikacji.

Zalecane rozwiązanie dla aplikacji zgodnych ze standardem MUI jest ostatnią metodą opisaną tutaj, czyli fizyczną separacją kodu źródłowego i zasobów aplikacji, a zasoby są dalej podzielone na jeden plik na obsługiwany język, aby zapewnić maksymalną elastyczność tworzenia, wdrażania i obsługi.

Wczesne dni: kod i zasoby działają razem

Początkowo zlokalizowane aplikacje tworzono przez edytowanie kodu źródłowego, zmianę zasobów (zazwyczaj ciągów znaków) w samym kodzie, a następnie ponowne kompilowanie aplikacji. Oznaczało to, że aby utworzyć zlokalizowaną wersję, trzeba było skopiować oryginalny kod źródłowy, przetłumaczyć elementy tekstowe (zasoby) w kodzie źródłowym i ponownie skompilować kod. Na poniższej ilustracji przedstawiono kod aplikacji z tekstem, który musi zostać zlokalizowany.

Chociaż takie podejście umożliwia tworzenie zlokalizowanych aplikacji, ma również znaczące wady:

• Wymaga wielu wersji kodu źródłowego, co najmniej jednej dla języka źródłowego i jednej dla każdego z języków docelowych. Powoduje to znaczne problemy podczas synchronizowania różnych wersji językowych aplikacji. W szczególności, gdy usterka musi zostać naprawiona w kodzie, wadę należy naprawić w każdej kopii kodu źródłowego (jeden na język).
• Jest również bardzo podatny na błędy, ponieważ wymaga lokalizatorów ( którzy nie są deweloperami) w celu wprowadzania modyfikacji w kodzie źródłowym, tworząc w ten sposób znaczne ryzyko pod względem integralności kodu.

Połączenie tych wad sprawia, że jest to niezwykle nieefektywna propozycja, a potrzebny był lepszy model.

Logiczne oddzielenie kodu i zasobów lokalizowalnych

Znaczącą poprawą w stosunku do poprzedniego modelu jest logiczne rozdzielenie kodu i zasobów lokalizowalnych w aplikacji. Dzięki temu kod jest odizolowany od zasobów i zapewnia, że kod pozostaje nienaruszony, gdy zasoby są zmieniane przez lokalizację. Z punktu widzenia implementacji ciągi i inne elementy interfejsu użytkownika są przechowywane w plikach zasobów, które są stosunkowo łatwe do tłumaczenia i są logicznie oddzielone od sekcji kodu.

W idealnym przypadku dodanie obsługi dowolnego języka może być tak proste, jak tłumaczenie zasobów lokalizowalnych na ten nowy język i użycie tych przetłumaczonych zasobów w celu utworzenia nowej zlokalizowanej wersji aplikacji — bez konieczności modyfikacji kodu. Na poniższej ilustracji przedstawiono sposób logicznego oddzielenia kodu i zasobów lokalizowalnych w aplikacji.

Ten model umożliwia łatwiejsze tworzenie zlokalizowanych wersji aplikacji i jest znaczącym ulepszeniem w stosunku do poprzedniego modelu. Ten model, zaimplementowany za pomocą narzędzi do zarządzania zasobami, od lat jest bardzo udany i jest nadal często używany przez wiele aplikacji dzisiaj. Jednak ma ona znaczące wady:

• Chociaż logicznie oddzielone, kod i zlokalizowane zasoby są nadal fizycznie przyłączone do jednego pliku wykonywalnego. W szczególności użyteczność jest nadal problematyczna, ponieważ ta sama usterka kodu (identyczna we wszystkich wersjach językowych) wymaga poprawki na język. W związku z tym, jeśli aplikacja jest wysyłana w 20 językach, poprawka usługi musi zostać wydana 20 razy (jeden dla każdego języka), mimo że kod jest naprawiany tylko raz.
• Dystrybucja i używanie aplikacji wielojęzycznych nie są odpowiednio obsługiwane przez ten model. Może to być znaczący problem w scenariuszach OEM i korporacyjnych. Jeśli na przykład komputer ma być współużytkowany między dwoma użytkownikami korzystającymi z różnych języków, aplikacje muszą być instalowane dwukrotnie z tym modelem, a następnie konieczne będzie włączenie mechanizmu alternatywnego między dwiema instalacjami. Zakłada się, że nie ma żadnych dodatkowych zależności, które uniemożliwiają nawet zaimplementowanie tego scenariusza. Na poniższej ilustracji przedstawiono przykład pojedynczej wady kodu, która wymaga dwóch poprawek.

Jest jasne, że chociaż ten model działa dobrze w niektórych scenariuszach, jego ograniczenia dotyczące aplikacji wielojęzycznych i ich wdrożeń mogą być bardzo problematyczne.

Odmiana tego modelu, która złagodzi niektóre problemy z aplikacjami wielojęzycznymi, to model, w którym zlokalizowane zasoby zawierają zestaw różnych zasobów językowych. Ten model ma wspólną bazę kodu i kilka zasobów dla różnych języków w tej samej aplikacji. Na przykład aplikacja może być dostarczana z językiem angielskim, niemieckim, francuskim, hiszpańskim, holenderskim i włoskim w tym samym pakiecie. Na poniższej ilustracji przedstawiono aplikację zawierającą wiele zasobów językowych.

Ten model ułatwia obsługę aplikacji, gdy należy naprawić usterkę kodu — co jest ulepszeniem — ale nie poprawia się w porównaniu z poprzednimi modelami, jeśli chodzi o obsługę dodatkowych języków. W takim przypadku nadal trzeba wydać nową wersję aplikacji (i ta wersja jest potencjalnie skomplikowana przez konieczność zapewnienia synchronizacji wszystkich zasobów językowych w ramach tej samej dystrybucji).

Fizyczne oddzielenie kodu i zasobów

Następnym krokiem ewolucyjnym jest fizyczne oddzielenie kodu i zasobów. W tym modelu zasoby są oddzielone od kodu i fizycznie oddzielone w różnych plikach implementacji. W szczególności oznacza to, że kod może stać się naprawdę niezależny od języka; ten sam kod fizyczny jest rzeczywiście dostarczany dla wszystkich zlokalizowanych wersji aplikacji. Na poniższej ilustracji przedstawiono, że kod i zasoby lokalizowalne muszą być fizycznie oddzielone.

Takie podejście ma kilka zalet w porównaniu z poprzednimi podejściami:

• Wdrażanie rozwiązań wielojęzycznych jest znacznie uproszczone. Dodanie obsługi dla danego języka wymaga tylko wysłania i zainstalowania nowego zestawu zasobów językowych dla tego konkretnego języka. Jest to szczególnie ważne, gdy zasoby językowe nie są jednocześnie dostępne. W tym modelu można wdrożyć aplikację w zestawie języków podstawowych i zwiększyć liczbę obsługiwanych języków w czasie bez konieczności modyfikowania lub ponownego wdrażania rzeczywistego kodu. Ta zaleta jest dodatkowo rozszerzona przez mechanizm rezerwowy, który umożliwia częściową lokalizację aplikacji i składników systemowych w danym języku, zapewniając, że zasoby, które nie znajdują się w tym preferowanym języku "wracają" do innego języka, który użytkownicy również rozumieją. Ogólnie rzecz biorąc, ten model pomaga zmniejszyć znaczne obciążenie, z jakim borykają się globalne firmy w przypadku wdrażania aplikacji w wielu językach, ponieważ umożliwia wdrażanie pojedynczego obrazu w znacznie bardziej efektywny sposób.
• Ulepszono możliwości obsługi. Usterka kodu musi zostać naprawiona i wdrożona tylko raz, ponieważ kod jest całkowicie niezależny od lokalizacji. W przypadku tego modelu wystawianie poprawki dla wady kodu, pod warunkiem, że zmiana nie jest związana z interfejsem użytkownika, jest znacznie prostsza i ekonomiczna niż w żadnym z poprzednich modeli.

Dynamiczne ładowanie zasobów specyficznych dla języka

Podstawowe pojęcia interfejsu MUI polegające na fizycznym oddzielaniu kodu źródłowego od zasobów specyficznych dla językaoraz tworzeniu rdzenia binarnego neutralnego językowo dla aplikacji, zasadniczo konfigurują architekturę sprzyjającą wdrażaniu dynamicznego ładowania zasobów specyficznych dla języka na podstawie ustawień języka użytkownika i systemu.

Kod źródłowy aplikacji dołączony do binarnego pliku głównego neutralnego językowo może korzystać z interfejsów API MUI na platformie Windows w celu abstrahowania wyboru odpowiedniego języka wyświetlania interfejsu użytkownika dla danego kontekstu. Interfejs MUI obsługuje to przez:

• Konstruowanie priorytetowej listy wyświetlanych języków interfejsu użytkownika na podstawie ustawień na poziomie systemu, użytkownika i aplikacji, na poziomie użytkownika i na poziomie systemu.
• Zaimplementowanie mechanizmu rezerwowego, który wybiera odpowiedniego kandydata z tej priorytetowej listy języków na podstawie dostępności zlokalizowanych zasobów.

Korzyści wynikające z dynamicznego ładowania zasobów interfejsu użytkownika z priorytetową rezerwą to:

• Umożliwia to częściową lokalizację aplikacji i składników systemowych w danym języku, ponieważ zasoby, które nie znajdują się w tym preferowanym języku, automatycznie powrócą do następnego języka na liście priorytetowej.
• Umożliwia ona dynamiczne przełączanie się z jednego języka na inny.
• Umożliwia tworzenie regionalnych lub na całym świecie pojedynczych obrazów wdrożenia obejmujących zestaw języków dla OEM i przedsiębiorstw.

Kompilowanie aplikacji MUI

W poprzednich sekcjach opisano opcje oddzielania kodu źródłowego od zasobów specyficznych dla języka oraz korzyści wynikające z możliwości korzystania z podstawowych interfejsów API platformy Windows w celu dynamicznego ładowania zlokalizowanych zasobów. Chociaż są to wytyczne, należy również zauważyć, że nie ma konkretnego preskrypcyjnego sposobu tworzenia aplikacji MUI dla platformy Windows.

Deweloperzy aplikacji mają pełny wybór w sposobie obsługi różnych ustawień języka interfejsu użytkownika, opcji tworzenia zasobów i metod ładowania zasobów. Deweloperzy mogą ocenić wytyczne podane w tym dokumencie i wybrać kombinację, która spełnia wymagania i środowisko programistyczne.

Poniższa tabela zawiera podsumowanie różnych opcji projektowania dostępnych dla deweloperów aplikacji, którzy chcą utworzyć aplikację MUI dla platformy Windows.