Grundläggande begrepp i MUI förklaras
- Förutsättning för MUI
- Avgränsning av källkod från språkspecifika resurser
- Dynamiskt läser in språkspecifika resurser
- Skapa MUI-program
Krav för MUI
Den grundläggande förutsättningen för att skapa ett MUI-kompatibelt program för Windows Vista och senare är att utforma programmet i enlighet med Riktlinjerna för Globalisering i Windows .
Separation av källkod från språkspecifika resurser
En av de grundläggande premisserna för MUI-teknik är separationen av programvarans källkod från språkspecifika resurser, för att möjliggöra flerspråkiga scenarier i applikationer mer effektivt. Uppdelningen av kod och resurser har uppnåtts via olika mekanismer och i olika grad över tid, enligt beskrivningen i följande avsnitt. Varje metod gav varierande flexibilitet när det gäller att skapa, distribuera och underhålla programmet.
Den rekommenderade lösningen för MUI-kompatibla program är den sista metoden som beskrivs här, nämligen den fysiska uppdelningen av programkällans kod och resurser, med själva resurserna ytterligare uppdelade i en fil per språk som stöds för maximal flexibilitet vid skapande, distribution och service.
De första dagarna: kod och resurser lever tillsammans
Ursprungligen skapades lokaliserade program genom att redigera källkoden och ändra resurserna (vanligtvis strängar) i själva koden och kompilera om programmen. Detta innebar att för att skapa en lokaliserad version var man tvungen att kopiera den ursprungliga källkoden, översätta textelementen (resurserna) i källkoden och kompilera om koden. Följande bild visar programkod med text som måste lokaliseras.
Även om den här metoden gör det möjligt att skapa lokaliserade program, har den också betydande nackdelar:
- Det kräver flera versioner av källkoden, minst en för källspråket och en för vart och ett av målspråken. Detta skapar betydande problem med att synkronisera de olika språkversionerna av programmet. I synnerhet när en defekt måste åtgärdas i koden måste defekten åtgärdas i varje kopia av källkoden (en per språk).
- Det är också mycket felbenäget eftersom det krävs lokaliserare – som inte är utvecklare – för att göra ändringar i källkoden, vilket skapar en betydande risk när det gäller kodintegritet.
Kombinationen av dessa nackdelar gör detta till ett extremt ineffektivt förslag, och en bättre modell behövdes.
Logiskt avgränsa kod och lokala resurser
En betydande förbättring jämfört med föregående modell är den logiska separationen av kod och lokaliserade resurser för ett program. Detta isolerar koden från resurserna och ser till att koden förblir orörd när resurser ändras genom lokalisering. Från implementeringssynpunkt lagras strängar och andra användargränssnittselement i resursfiler, som är relativt enkla att översätta och som är logiskt åtskilda från kodavsnitten.
Helst kan det vara så enkelt att lägga till stöd för ett visst språk som att översätta de lokala resurserna till det nya språket och använda dessa översatta resurser för att skapa en ny lokaliserad version av programmet – utan att kräva någon kodändring. Följande bild visar hur kod och lokala resurser ska separeras logiskt i ett program.
Den här modellen möjliggör enklare skapande av lokaliserade versioner av ett program och är en betydande förbättring jämfört med den tidigare modellen. Den här modellen, som implementeras med hjälp av resurshanteringsverktyg, har varit mycket framgångsrik genom åren och används fortfarande ofta av många program idag. Det har dock betydande nackdelar:
- Även om kod och lokaliserade resurser är logiskt åtskilda är de fortfarande fysiskt anslutna i en körbar fil. I synnerhet är servicebarhet fortfarande problematiskt eftersom samma kodfel (identiska i alla språkversioner) kräver en korrigering per språk. Om man skickar programmet på 20 språk måste därför en tjänstkorrigering utfärdas 20 gånger (en för varje språk), även om koden bara har åtgärdats en gång.
- Distribution och användning av flerspråkiga program stöds inte tillräckligt av den här modellen. Detta kan vara ett betydande problem i OEM- och företagsscenarier. Om en dator till exempel ska delas mellan två användare med olika språk måste program installeras två gånger med den här modellen, och sedan måste någon mekanism aktiveras för att växla mellan de två installationerna. Detta förutsätter att det inte finns några ytterligare beroenden som förhindrar att även det här scenariot implementeras. Följande bild visar ett exempel på ett enda kodfel som kräver två korrigeringar.
Det är uppenbart att även om den här modellen fungerar bra i vissa scenarier kan dess begränsningar för flerspråkiga program och deras distributioner vara mycket problematiska.
En variant av den här modellen som lindrar vissa problem med flerspråkiga program är modellen där de lokala resurserna innehåller en uppsättning olika språkresurser. Den här modellen har en gemensam kodbas och flera resurser för olika språk i samma program. Ett program kan till exempel levereras med engelska, tyska, franska, spanska, nederländska och italienska i samma paket. Följande bild visar ett program som innehåller flera språkresurser.
Den här modellen gör det enklare att hantera programmet när ett kodfel måste åtgärdas, vilket är en förbättring, men inte förbättras jämfört med tidigare modeller när det gäller stöd för ytterligare språk. I det här fallet måste man fortfarande släppa en ny version av programmet (och den versionen kan vara komplicerad av behovet av att se till att alla språkresurser synkroniseras inom samma distribution).
Fysiskt avgränsa kod och resurser
Nästa evolutionära steg är att fysiskt separera kod och resurser. I den här modellen abstraheras resurserna från koden och separeras fysiskt i olika implementeringsfiler. Detta innebär i synnerhet att koden kan bli helt språkoberoende. samma fysiska kod levereras faktiskt för alla lokaliserade versioner av ett program. Följande bild visar att kod och lokala resurser måste separeras fysiskt.
Den här metoden har flera fördelar jämfört med tidigare metoder:
- Distributionen av flerspråkiga lösningar förenklas avsevärt. Att lägga till stöd för ett visst språk kräver endast leverans och installation av en ny uppsättning språkresurser för det här språket. Detta är särskilt viktigt när språkresurser inte är tillgängliga samtidigt. Med den här modellen kan man distribuera ett program i en uppsättning kärnspråk och öka antalet språk som stöds över tid utan att behöva ändra eller distribuera om den faktiska koden. Den här fördelen utökas ytterligare av en reservmekanism som möjliggör partiell lokalisering av program och systemkomponenter på ett visst språk genom att se till att resurser som inte hittas på det här föredragna språket "återgår" till ett annat språk som användarna också förstår. Sammantaget bidrar den här modellen till att minska den stora belastning som globala företag står inför när de distribuerar program på flera språk eftersom den möjliggör distribution av en avbildning på ett mycket effektivare sätt.
- Servicebarheten förbättras. En koddefekt behöver bara åtgärdas och distribueras en gång, eftersom koden är helt lokaliseringsoberoende. Med den här modellen är det mycket enklare och kostnadseffektivt att utfärda en korrigering för en koddefekt, förutsatt att ändringen inte är UI-relaterad, än i någon av de tidigare modellerna.
Läs in språkspecifika resurser dynamiskt
De grundläggande MUI-begreppen i fysiskt separera källkoden från språkspecifika resurseroch skapa en språkneutral kärnbinärfil för ett program, konfigurerar i princip en arkitektur som bidrar till att implementera dynamisk inläsning av språkspecifika resurser baserat på inställningar för användar- och systemspråk.
Programkällkoden som paketeras i den språkneutrala kärnbinärfilen kan använda MUI-API:er på Windows-plattformen för att abstrahera valet av lämpligt gränssnittsspråk för visning av ett visst sammanhang. MUI stöder detta genom att:
- Skapa en prioriterad lista över språk för visning av användargränssnitt baserat på inställningar på system-, användar- och programnivå, användarnivå och systemnivå.
- Implementera en reservmekanism som väljer en lämplig kandidat från den här prioriterade listan över språk, baserat på tillgängligheten för lokaliserade resurser.
Fördelarna med att dynamiskt läsa in användargränssnittsresurser med prioriterad återställning är:
- Det möjliggör partiell lokalisering av program och systemkomponenter på ett visst språk, eftersom resurser som inte hittas på det här föredragna språket automatiskt återgår till nästa språk i den prioriterade listan.
- Det möjliggör scenarier som att växla dynamiskt från ett språk till ett annat.
- Det gör det möjligt att skapa regionala eller globala distributionsbilder som täcker en uppsättning språk för OEM-tillverkare och företag.
Utveckla MUI-applikationer
I föregående avsnitt beskrevs alternativen för att skilja källkod från språkspecifika resurser och den resulterande fördelen med att kunna använda kärn-API:er för Windows-plattformen för att dynamiskt läsa in lokaliserade resurser. Även om detta är riktlinjer bör det också påpekas att det inte finns något specifikt normativt sätt att utveckla ett MUI-program för Windows-plattformen.
Programutvecklare har ett fullständigt val i hur de hanterar olika språkinställningar för användargränssnittet, alternativ för att skapa resurser och metoder för resursinläsning. Utvecklare kan utvärdera riktlinjerna i det här dokumentet och välja en kombination som passar deras krav och utvecklingsmiljö.
I följande tabell sammanfattas de olika designalternativ som är tillgängliga för programutvecklare som vill skapa ett MUI-program för Windows-plattformen.
| Språkinställningar för användargränssnitt | Skapa resurs | Resursinläsning |
|---|---|---|
| Följ språkinställningarna för användargränssnittet i operativsystemet${REMOVE}$ |
Enkelt språk i en delad resursbinär fil (MUI-resursteknik) -eller- Flera språk i en icke-delad resursbinär |
Applikationen anropar standardfunktioner för resursinläsning. Resurser returneras på de språk som matchar operativsystemets inställningar. |
| Programspecifik resursmekanism |
Programmet anropar MUI API för att hämta de trådprefererade eller processprefererade användargränssnittsspråken från operativsystemet och använder dessa inställningar för att läsa in sina egna resurser. |
|
| Programspecifika språkinställningar för användargränssnitt${REMOVE}$ |
Enskilt språk i en delad resurs binär -eller- Flera språk i en icke-delad resursbinär |
Programmet anropar MUI API för att ange programspecifika gränssnittsspråk eller process föredragna gränssnittsspråk och anropar sedan standardfunktioner för resursinläsning. Resurser returneras på de språk som anges av programmet eller systemspråken. -eller- Programmet avsöker resurser på ett visst språk och hanterar sin egen resursextrahering från hämtade binära data. |
| Programspecifik resursmekanism |
Programmet hanterar sin egen laddning av resurser. |