No meu projeto atual, alguns dos utilizadores viajará ao redor do mundo, e quando eles chegam em diferentes destinos, usar qualquer máquina é útil no momento. Aquelas máquinas de comentários estará executando Windows e instalado e configurado para a localidade do local. (Acabei de perceber que as máquinas de comentários podem não ter os pacotes de idioma da direita… Provavelmente não vai, Na verdade… Estou estacionando um para agora).
Precisa de SharePoint para fornecer um mecanismo pelo qual o usuário pode escolher o seu idioma preferido e depois MOSS honrar essa linguagem independentemente de como o usuário acessa o musgo. Em outras palavras, Desconsidere tudo o que o navegador diz MOSS/IIS e, em vez disso, procure esse idioma preferencial e usá-lo.
Nós vamos investigar duas abordagens:
- Manipulador HTTP: Um manipulador HTTP personalizado instalado no IIS irá procurar o perfil do usuário MOSS, descobrir o idioma preferido e em seguida, alternar o cabeçalho HTTP ao redor conforme necessário antes de passar controle para MOSS.
- global. asax: Modificar o global. asax para fazer a mesma coisa. Nós pode modificar alguma coisa, Mas a idéia é que podemos encontrar algum lugar onde podemos inserir nossa lógica de alternância de localidade.
O outro fator complicador é que precisamos de apoio de 60 mil usuários, sobre 1,000 de acesso que podem ser simultaneamente ao MOSS no pico de carga.
O manipulador HTTP parece drástico, Mas possivelmente o melhor lugar para colocar o código, uma vez que é no nível do IIS e onisciente. É um bom ponto único de trabalho.
Nós está inclinado em direção a uma abordagem de tipo global. asax, principalmente porque acreditamos que teremos mais opções para o cache de dados nesse ponto.
Eu vou estar blogando mais sobre este assunto, como eu aprendo mais.
Se você tem sabe alguma coisa sobre isso, please post a comment 🙂
</fim>
Siga-me no Twitter em http://www.twitter.com/pagalvin
Eu não testei isso então não tenho certeza se ele funciona.
A classe de página tem um InitializeCulture() método que pode ser substituído. Se você fizer isso no código por trás de seu masterpage personalizado, Você poderia fazer algo ao longo das linhas de:
Protected override void InitializeCulture()
{
// substituir o método virtual InitializeCulture() para verificar se o seu perfil contém uma configuração de idioma do usuário
String UserCulture = GetCultureFromUserProfile();
se ( UserCulture != "")
{
// Há uma configuração de idioma no perfil do usuário: alternar para ela
Thread.CurrentThread.CurrentUICulture = new CultureInfo(UserCulture);
Thread.CurrentThread.CurrentCulture = CreateSpecificCulture(UserCulture);
}
}
Obviamente você pode criar um cache para a implementação desse método.
Fonte: http://quickstarts.asp.net/QuickStartv20/util/srcview.aspx?Path=~/ASPNET/Samples/Localization/LocalizePers.src&arquivo = LocalizePers_cs\LocalizePers_cs.aspx&lang = C % 23 fonte
Eu estou pensando o manipulador HTTP com o seguinte fluxo:
1. Solicitação de, verificar cookies um cookie de sessão para o idioma de sua preferência (cookies de sessão expirarem quando o navegador é fechado)
2. Verificar se a solicitação for para página ASPX, Se não, ignorar o pedido
3. Se o cookie existe, definir o cabeçalho de idioma para o valor especificado. Você é feito!
4. Nenhum cookie, levar a credencial de autenticação e procure o usuário no SPS, encontrar o idioma de sua preferência
5. Definir o cabeçalho do cookie e language cabeçalho HTTP. Feito.
Primeira solicitação de página APX terá sobrecarga de pesquisa SPS mas cada solicitação a partir daí com ter sem pesquisas assim será velocidade nativa. Não há necessidade de cache de sessão ou qualquer outra sobrecarga usando um cookie de sessão também. Uma vez que o navegador é fechado, o cookie de sessão desaparece. Se o usuário mudar sua preferência de idiomas em SPS precisam fechar e reabrir o navegador para que tenha efeito.
na verdade o manipulador http não está no nível do iis…é no nível do aplicativo (Filtros ISAPI são no nível do IIS)…teria cuidado que BC SP tem seu próprio manipulador…Então, certifique-se de testá-lo…Eu fiz isso antes, mas tive algum conflito com o manipulador de SP.
Eu estaria mais inclinado a usar um HTTPHandler, a única razão é que eu não gosto de tocar os arquivos do SharePoint. Além disso, é fácil criar uma solução do SharePoint para implantar um HttHandler ( e usar a API SPWebConfig para modificar o Web. config). A carga de usuário a ter que fazer, Eu imagino que você tem uma fazenda de tamanho considerável, Não queres mesmo ir modifiying arquivos em cada servidor.
Implantar o arquivo global. asa, através de uma solução é uma má ideia, Se você se retratasse, seu arquivo original desapareceu. …
Também ter a capacidade de retrair a solução rapidamente pode ser uma boa idéia, no caso das coisas correrem mal com o perf do manipulador.