Il mio progetto attuale, alcuni degli utenti si recherà in tutto il mondo, e quando arrivano a diverse destinazioni, utilizzare qualsiasi macchina è comodo al momento. Quelle macchine guest saranno in esecuzione Windows e installato e configurato per la lingua locale. (Ho appena realizzato che le macchine guest non possono avere la destra language pack… probabilmente non, Infatti… Io sto parcheggio che uno per ora).
SharePoint deve fornire un meccanismo per cui l'utente può scegliere la lingua preferita e poi hanno MOSS onorare quella lingua indipendentemente dal modo in cui l'utente accede MOSS. In altre parole, ignorare tutto ciò il browser dice IIS/MOSS e invece cercare quella lingua preferita e utilizzarlo.
Stiamo andando a indagare due approcci:
- Gestore HTTP: Un gestore HTTP personalizzato installato IIS cercherà il profilo dell'utente MOSS, capire il linguaggio preferito e poi cambiare l'intestazione HTTP intorno all'occorrenza prima di passare il controllo al muschio.
- asax: Modificare il Global. asax per fare la stessa cosa. Possiamo modificare qualcos'altro, ma l'idea è che troviamo un posto dove possiamo inserire la nostra logica di commutazione locale.
L'altro fattore di complicazione è che abbiamo bisogno di sostegno 60k utenti, circa 1,000 di accesso che possono essere simultaneamente a MOSS al picco di carico.
Il gestore HTTP sembra abbastanza drastico, ma probabilmente il posto migliore per inserire il codice dato che è a livello di IIS e onnisciente. È un buon punto unico di lavoro.
Noi stiamo sporgendosi verso un approccio di tipo Global. asax, principalmente perché crediamo che avremo più opzioni per la memorizzazione nella cache di dati in quel punto.
Sarò blogging più su questo argomento, come saperne di più.
Se avete sapere nulla di questo, per favore posta un commento 🙂
</fine>
Seguimi su Twitter a http://www.twitter.com/pagalvin
Non ho testato questo quindi non sono sicuro se funziona.
La classe Page ha un InitializeCulture() Metodo che può essere sottoposto a override. Se fate questo nel code-behind della vostra masterpage personalizzato, si potrebbe fare qualcosa sulla falsariga di:
protectedoverridevoid InitializeCulture()
{
// eseguire l'override del metodo virtuale InitializeCulture() per verificare se il profilo contiene un'impostazione della lingua dell'utente
String UserCulture = GetCultureFromUserProfile();
Se ( UserCulture != "")
{
// c'è un'impostazione della lingua dell'utente nel profilo: passare ad esso
Thread.CurrentThread.CurrentUICulture = new CultureInfo(UserCulture);
Thread.CurrentThread.CurrentCulture = CreateSpecificCulture(UserCulture);
}
}
Ovviamente è possibile costruire alcune cache nell'implementazione di questo metodo..
Fonte: http://quickstarts.asp.net/QuickStartv20/util/srcview.aspx?path=~/ASPNET/Samples/Localization/LocalizePers.src&file = LocalizePers_cs\LocalizePers_cs.aspx&lang = C % 23 sorgente
Sto pensando gestore HTTP con il seguente flusso:
1. Richiesta è disponibile in, controllare i cookie per un cookie di sessione per la preferenza di lingua (i cookie di sessione scadano quando il browser viene chiuso)
2. Controllare se la richiesta è per una pagina ASPX, Se non, ignorare la richiesta
3. Se il cookie esiste, impostare l'intestazione di lingua al valore specificato. Si è fatto!
4. Nessun cookie, prendere la credenziale di autenticazione e cercare l'utente in SPS, trovare la preferenza di lingua
5. Impostare l'intestazione cookie e intestazione language HTTP. Fatto.
Prima richiesta di pagina APX avrà sovraccarico di ricerca SPS ma ogni richiesta da allora in poi con non avere nessun ricerche così sarà nativo Velocità. Senza bisogno di cache della sessione o qualsiasi altro sovraccarico utilizzando un cookie di sessione troppo. Una volta chiuso il browser, il cookie di sessione va via. Se l'utente cambia la loro preferenza di lingue in SPS hanno solo bisogno di chiudere e riaprire il browser per poter entrare in vigore.
in realtà il gestore http non è a livello di iis…è a livello di applicazione (Il livello di IIS sono filtri ISAPI)…Starei attento che a.c. SP ha il proprio gestore…quindi assicuratevi di provarlo…Hai fatto prima, ma hanno avuto qualche conflitto con il gestore SP.
Sarei più propenso a utilizzare un HTTPHandler, l'unico motivo è che non mi piace toccare i file di SharePoint. In più è facile creare una soluzione SharePoint per distribuire un HttHandler ( e utilizzare l'API SPWebConfig per modificare il file Web. config). Avendo il carico utente fai, Immagino che hai una considerevole fattoria, non vuoi davvero andare era file su ogni server.
Il file Global ASA tramite una soluzione di distribuzione è una cattiva idea, Se si ritrae e, file originale è andato …
Avendo anche la possibilità di ritirare rapidamente la soluzione potrebbe essere una buona idea, nel caso in cui le cose vanno male con la perf del gestore.