Il framework ASP.NET Ajax implementa un sistema per la localizzazione delle applicazioni "lato client". Se abbiamo uno ScriptManager in una pagina, impostando l'attributo EnableScriptLocalization a "true" abilitiamo questa funzionalità che in sostanza "serve" dei file javascript in base alla cultura corrente. Prendiamo ad esempio il codice seguente e supponiamo che venga eseguita su un PC con impostata la localizzazione in lingua inglese (en-US ad esempio):
1: <asp:ScriptManager runat="server" ID="TheScriptManager"
EnableScriptLocalization="true">
2: <Scripts>
3: <asp:ScriptReference Path="~/js/Risorse.js" />
4: </Scripts>
5: </asp:ScriptManager>
Viene referenziato nello script manager il file Risorse.js, questo significa che il file in questione verrà inviato (o meglio la direttiva script..ecc verrà inserita nell'html prodotto dalla pagina) al client ql momento della richiesta della pagina. La particolarità è che, avendo abilitato l'apposita opzione dello ScriptManager (che per default è impostata a false) per la localizzazione, se nella posizione dove si trova il file js ne esiste una versione con nome Risorse.en-US.js, verrà servita questa in quanto corrisponde alla cultura correntemente impostata.
In questo modo è possibile creare dei file js contenenti le risorse necessarie alla localizzazione in diverse lingue e ASP.NET Ajax provvederà in automatico ad inviarci quello corretto per la lingua in uso. Un esempio di utilizzo potrebbe essere il seguente, un file di risorse fatto in questo modo:
1: Risorse = {
2: "Lingua" : "it-IT",
3: "testoBtnAnnulla" : "Annulla"
4: };
oppure in questo nella sua versione per la lingua inglese (con estensione .en-US.js)
1: Risorse = {
2: "Lingua" : "en-US",
3: "testoBtnAnnulla" : "Cancel"
4: };
Nel codice javascript del client ci basterà scrivere qualcosa tipo:
1: alert("La lingua corrente è: " + Risorse.Lingua);
Per ottenere un alert contenente un messaggio che cambierà in base alla lingua correntemente selezionata.
Fin qui tutto ok; qualche perplessità potrerbbe però nascere nel momento in cui la nostra applicazione debba gestire/memorizzare la cultura da utilizzare sul server. Già perche il sistema appena illustrato tiene conto in realtà della cultura corrente del client (dove gira il browser per intenderci) e non quella del server. Nella nostra applicazione invece potrebbe servire la cosa opposta perchè ad esempio la lingua impostata da utilizzare può essere impostata manualmente dall'utente attraverso l'interfaccia dell'applicazione e poi salvata nel profilo personale o in un cookie, e magari ci serve che sia lato server per localizzare altre parti/pagine dell'applicazione che "girano" soltanto sul server.
In questi casi si può comunque continuare ad utilizzare la tecnica appena descritta, con pochi accorgimenti. Prima di tutto possiamo in questo caso non abilitare la localizzazione automatica degli script, semplicemente impostando a false l'attributo EnableScriptLocalization dello ScriptManager o non impostandolo affatto in quanto come detto per default non è abilitato.
Ora possiamo sfruttare un'altra possibilità della localizzazione che consiste nel poter forzare per mezzo di un attributo la cultura con cui deve essere servito un particolare script dallo ScriptManager, semplicemente impostandola sul singolo riferimento per mezzo della proprietà ResourceUICultures come nell'esempio seguente:
1: <asp:ScriptManager runat="server" ID="TheScriptManager">
2: <Scripts>
3: <asp:ScriptReference Path="~/js/Risorse.js"
ResourceUICultures="it-IT" />
4: </Scripts>
5: </asp:ScriptManager>
In questo modo lo ScriptManager cercherà di utilizzare sempre e comunque un file scritto per la cultura italiana, indipendentemente da quella impostata sul client. Il prossimo passo per sfruttare questo meccanismo per il nostro scopo, è quello di fare in modo che il file di risorse javascript venga effettivamente inviato specificandone la cultura, ma quest'ultima sia impostata dal server prima della renderizzazione della pagina. Quello che serve quindi è semplicemente specificare il riferimento al file di risorse nello ScriptManager da codice a runtime impostandone di volta in volta la cultura da utilizzare (che ovviamente può cambiare anche da un postback all'altro.. l'importante è che per la cultura che si imposta ci sia un file js corrispondente, altrimenti le risorse non saranno inviate al client). Per farlo basta togliere dallo ScriptManager il riferimento al file Risorse.js dell'esempio ed aggiungerlo a runtime nel codice eseguito lato server, ad esempio nell'evento PageLoad della pagina in questo modo:
1: protected void Page_Load(object sender, EventArgs e)
2: {
3: // Riferimento al file di risorse da utilizzare
4: ScriptReference jsRisorse = new ScriptReference("~/js/Risorse.js");
5:
6: // la cultura viene impostata leggendola dal thread corrente,
7: // potrebbe essere diversa da quella del client
8: // e anche da quella di altri processi che girano sul server web
9: jsRisorse.ResourceUICultures = new string[1]
{ System.Threading.Thread.CurrentThread.CurrentUICulture.ToString() };
10:
11: // il riferimento con la cultura specificata viene aggiunto allo
12: // ScriptManager. Se ad esempio la cultura impostata fosse en-US
13: // è necessario che sia presente il file ~/js/Risorse.en-US.js
14: // perchè questo verrà effettivamente referenziato nell'HTML
15: TheScriptManager.Scripts.Add(jsRisorse);
16: }
E con questo abbiamo raggiunto il nostro scopo, cioè sul client verra servito il file js di risorse localizzato in base alle impostazioni memorizzate sul server, magari n el profilo dell'utente, e queste ultime possono essere diverse da quelle del PC client dove gira l'applicazione all'interno del browser.