В моем текущем проекте, Некоторые из пользователей будет путешествовать во всем мире, и когда они прибывают в различные пункты назначения, использовать любую машину удобно, в то время. Эти гостевые машины под управлением Windows и установлен и настроен для местного языка. (Я просто понял, что гостевых машин могут не иметь правильный языковые пакеты… вероятно, не будет, На самом деле… Я парковка что один сейчас).
SharePoint необходимо предоставить механизм, при котором пользователь может выбрать предпочтительный язык и затем иметь честь языке независимо от того, как пользователь обращается к мох Мосс. Другими словами, игнорировать любой браузер говорит IIS/Мосс и вместо этого искать что предпочтительный язык и использовать его.
Мы будем расследовать два подхода:
- Обработчик HTTP-данных: Пользовательский обработчик HTTP, установленных на сервере IIS будет искать Мосс профиля пользователя, выяснить, предпочтительный язык и перейдите в заголовке HTTP вокруг необходимости перед передачей управления MOSS.
- Global.asax: Изменить global.asax сделать то же самое. Мы можем изменить что-то другое, но идея состоит в том, что мы находим некоторые места, где мы можем вставить нашу логику переключения языка.
Другим осложняющим фактором является, что нам нужно поддержка 60k пользователей, о 1,000 которые могут одновременно доступа Мосс на пике нагрузки.
Обработчик HTTP-данных кажется довольно резкое, но возможно лучшее место, чтобы поместить код, так как это на уровне IIS и всезнающим. Это хороший один точка работы.
Мы склоняется подход типа global.asax, главным образом потому, что мы считаем, что мы будем иметь больше возможностей для кэширования данных в тот момент.
Я буду блоге больше на эту тему, как я могу узнать больше.
Если у вас знать что-нибудь об этом, please post a comment 🙂
</конец>
Следуй за мной по щебетать на http://www.twitter.com/pagalvin
Я не проверял это поэтому я не уверен, если он работает.
Класс страницы имеет InitializeCulture() метод, который может быть переопределен. Если вы делаете это в коде пользовательского masterpage, Вы могли бы сделать что-то вдоль линий:
охраняемые переопределить недействительными InitializeCulture()
{
// переопределять виртуальный метод InitializeCulture() чтобы проверить, если профиль содержит параметр языка пользователя
Строка UserCulture = GetCultureFromUserProfile();
Если ( UserCulture != "")
{
// существует параметр языка пользователя в профиле: перейти к нему
Thread.CurrentThread.CurrentUICulture = новый CultureInfo(UserCulture);
Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(UserCulture);
}
}
Очевидно, что вы можете построить некоторые кэширования в реализации этого метода.
Источник: HTTP://quickstarts.asp.net/QuickStartv20/util/srcview.aspx?path=~/ASPNET/Samples/Localization/LocalizePers.src&файл = LocalizePers_cs\LocalizePers_cs.aspx&lang = C % 23 источник
Я имею в виду обработчика HTTP с следующим потоком:
1. Запрос приходит, Проверка куки для файла cookie сеанса для языковых предпочтений (сеансовые куки истекает, когда браузер закрывается)
2. Проверить, если запрос для страницы ASPX, Если не, пропустить запрос
3. Если файл Сookie существует, присвоить указанное значение language заголовок. Вы сделали!
4. Без файла cookie, Возьмите учетных данных проверки подлинности и искать пользователя в SPS, Найти языковых предпочтений
5. Задать заголовок cookie и язык заголовка HTTP. Договорились.
Первый запрос страницы APX будет иметь накладные расходы на SPS поиска но каждый запрос от после этого дальше с иметь без поиска так будет родной скорости. Нет необходимости в кэш сессий или других служебных данных с помощью файла cookie сеанса слишком. После закрытия браузера, файл cookie сеанса уходит. Если пользователь изменяет их языки предпочтения в SPS они просто нужно закрыть и снова открыть браузер для того, чтобы вступили в силу.
на самом деле обработчик http не на уровне iis…Это на уровне приложения (Фильтры ISAPI находятся на уровне IIS)…я быть осторожным, что БК SP имеет свой собственный обработчик…так что не забудьте проверить его…я делал это раньше, но имел некоторый конфликт с обработчиком SP.
Я хотел бы быть более склонны использовать HTTPHandler, Единственная причина, что я не люблю прикасаться файлы SharePoint. Кроме того, он легко создавать решения SharePoint для развертывания HttHandler ( и использовать SPWebConfig API для изменения файла web.config). Имея пользовательской нагрузки вы делаете, Я бы себе, что у вас есть значительные фермы, Вы действительно не хотите пойти общесистемными файлы на каждом сервере.
Развертывание файла global.asa через решение — плохая идея, Если вы отказаться, Ваш исходный файл больше нет …
Кроме того, возможность отозвать решение быстро может быть хорошей идеей, в случае, если дела идут не так с perf обработчика.