På mitt nuvarande projekt, några användare kommer att resa runt i världen och när de anländer till olika destinationer, använda oavsett maskin är praktiskt vid tidpunkten. Dessa gästmaskiner kommer att köra Windows och installerat och konfigurerat för lokala språket. (Jag har bara insett att gäst maskinerna inte kanske har rätt språkpaket… förmodligen kommer inte, I själva verket… Jag parkering att man nu).
SharePoint måste skapa en mekanism där användaren kan välja deras språk och sedan har MOSS hedra det språket oavsett hur användaren ansluter till MOSS. Med andra ord, bortse från vad webbläsaren säger IIS/MOSS och istället leta upp det språket och använda den.
Vi kommer att undersöka två metoder:
- HTTP-hanteraren: En anpassad HTTP-hanteraren installeras på IIS kommer leta upp användarens profil, MOSS, räkna ut önskat språk och sedan växla HTTP-huvudet runt som behövs innan kontroll till MOSS.
- Global.asax: Ändra global.asax för att göra samma sak. Vi kan ändra något annat, men tanken är att vi hittar något ställe där vi kan sätta in våra locale-switching logik.
Den andra komplicerande faktorn är att vi behöver stöd 60k användare, om 1,000 som kan samtidigt att få tillgång till MOSS på topp ladda.
HTTP-hanteraren verkar ganska drastiska, men kanske den bästa platsen att sätta koden eftersom det är på IIS och allvetande. Det är ett bra ställe för arbete.
Vi lutar mot en global.asax typ strategi, främst eftersom vi anser att har vi fler alternativ för cachelagring data då.
Jag kommer att blogga mer om detta ämne som jag lär dig mer.
Om du vet något om detta, please post a comment 🙂
</slutet>
Följ mig på Twitter vid http://www.twitter.com/pagalvin
Jag har inte testat detta så jag inte är säker på om det fungerar.
Klassen sida har en InitializeCulture() metod som kan åsidosättas. Om du gör det i kod bakom din anpassade huvudsida, du kunde göra något i linje med:
skyddade Åsidosätt void InitializeCulture()
{
// åsidosätta virtuell metod InitializeCulture() att kontrollera om profilen innehåller en user-språkinställning
string UserCulture = GetCultureFromUserProfile();
om ( UserCulture != "")
{
// Det finns en user-språkinställning i profilen: Växla till det
Thread.CurrentThread.CurrentUICulture = ny CultureInfo(UserCulture);
Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(UserCulture);
}
}
Självklart kan du bygga några cachelagring i genomförandet av denna metod.
Källa: http://quickstarts.asp.net/QuickStartv20/util/srcview.aspx?Path=~/ASPNET/samples/localization/LocalizePers.src&Fil = LocalizePers_cs\LocalizePers_cs.aspx&lang = C % 23 källa
Jag tänker HTTP-hanterare med följande flöde:
1. Begäran kommer i, Kontrollera cookies för en sessionscookie för språkinställning (sessionscookies upphör när webbläsaren stängs)
2. Kontrollera om begäran är för ASPX-sida, om inte, hoppa över begäran
3. Om cookie finns, Ange rubriken språk till det angivna värdet. Du är klar!
4. Ingen cookie, ta Autentiseringsbehörigheten och ser användaren upp i SPS, hitta språk
5. Ange cookie-huvudet och HTTP language header. Gjort.
Första APX sidbegäran har overhead av SPS sökning men varje begäran från därefter på med har ingen sökningar så blir native hastighet. Inget behov av sessionscachen eller andra omkostnader genom att använda en sessionscookie för. När webbläsaren stängs, Sessionscookien försvinner. Om användaren ändrar deras språk preferens i SPS behöver de bara att stänga och åter öppna webbläsaren för att funktionen ska gälla.
faktiskt http-hanteraren är inte på nivån iis…Det är på programnivå (ISAPI-filter är på IIS nivå)…Jag skulle vara försiktig bc SP har sin egen handler…så vara säker på att testa det.…Jag har gjort det förut men har haft några konflikter med det SP handtag.
Jag skulle vara mer benägna att använda en HTTPHandler, den enda anledningen är att jag inte gillar att röra de SharePoint-filerna. Plus att det är enkelt att skapa en SharePoint-lösning för att distribuera ett HttHandler ( och använda SPWebConfig Apis för att ändra web.config). Har användaren lasten gör du, Jag skulle tro att du har en betydande gård, du vill verkligen inte gå modifiying filer på varje server.
Distribuera filen global.asa via en lösning är en dålig idé, Om du dra tillbaka det, den ursprungliga filen är borta …
Också ha förmågan att återkalla lösningen snabbt kan vara en bra idé, om saker går fel med perf av hanteraren.