На мом тренутном пројекту, неки од корисника ће путовати широм света, а када стигну на различитим дестинацијама, use whatever machine is handy at the time. Those guest machines will be running Windows and installed and configured for the local locale. (Управо сам схватио да је гост машине не могу имати право језичке пакете… вероватно неће, заправо… Ја паркинг који један за сада).
SharePoint needs to provide a mechanism whereby the user can pick their preferred language and then have MOSS honor that language regardless of how the user accesses MOSS. In other words, disregard whatever the browser tells IIS/MOSS and instead look up that preferred language and use it.
Ми ћемо истражити два приступа:
- ХТТП Хандлер: Обичај ХТТП руковалац инсталиран на ИИС ће потражити профил МОСС корисников, схватим жељени језик, а затим се ХТТП заглавље око колико је потребно пре него што пролази контролу на МОСС.
- глобал.асак: Modify global.asax to do the same thing. We may modify something else, but the idea is that we find some place where we can insert our locale-switching logic.
Други компликујући фактор је то што је потребно за подршку корисницима 60к, око 1,000 од којих се могу истовремено приступају Мосс у вршном оптерећењу.
ХТТП управљач изгледа прилично драстичне, but possibly the best place to put the code since it’s at the IIS level and all-knowing. It’s a good single point of work.
Ми нагиње ка глобал.асак типа приступа, углавном због тога што верујемо да ћемо имати више опција за кеширање података у том тренутку.
Бићу са блоговањем више о овој теми као што сам сазнати више.
Ако сте нешто знате о томе, please post a comment 🙂
</крај>
Следите ме на Туиттер на http://www.twitter.com/pagalvin
I have not tested this so I am not sure if it works.
The Page class has an InitializeCulture() method which can be overridden. If you do this in the code behind of your custom masterpage, you could do something along the lines of:
protected override void InitializeCulture()
{
// override virtual method InitializeCulture() to check if profile contains a user language setting
string UserCulture = GetCultureFromUserProfile();
ако ( UserCulture != "")
{
// there is a user language setting in the profile: switch to it
Thread.CurrentThread.CurrentUICulture = new CultureInfo(UserCulture);
Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(UserCulture);
}
}
Obviously you can build some caching into the implementation of this method.
Извор: хттп://quickstarts.asp.net/QuickStartv20/util/srcview.aspx?path=~/aspnet/samples/localization/LocalizePers.src&file=LocalizePers_cs\LocalizePers_cs.aspx&lang=C# source
I’m thinking HTTP handler with the following flow:
1. Request comes in, check cookies for a session cookie for language preference (session cookies expire when the browser is closed)
2. Check if request is for ASPX page, if not, skip request
3. If cookie exists, set the language header to the value specified. You are done!
4. No cookie, take the authentication credential and look the user up in SPS, find language preference
5. Set cookie header and HTTP language header. Done.
First APX page request will have overhead of SPS lookup but every request from then on with have no lookups so will be native speed. No need for session cache or any other overhead by using a session cookie too. Once the browser is closed, the session cookie goes away. If the user changes their languages preference in SPS they just need to close and re-open the browser for it to take effect.
actually the http handler isn’t at the iis level…it’s at the application level (ISAPI Filters are at the IIS level)…i would be careful bc SP has its own handler…so be sure to test it out…i’ve done it before but have had some conflict with the SP handler.
I would be more inclined to use a HTTPHandler, the only reason is that I don’t like touching the SharePoint files. Plus it’s easy to create a SharePoint solution to deploy a HttHandler ( and use the SPWebConfig API’s to modify the web.config). Having the user load you do, I’d imagine you have a sizable farm, you really don’t want to go modifiying files on each server.
Deploying the global.asa file via a solution is a bad idea, if you retract it, your original file is gone …
Also having the ability to retract the solution quickly might be a good idea, in case things go wrong with the perf of the handler.