2 pagine in totale: <<Indietro 1 [2]
Con l'avvento di ASP.NET, questo codice può essere eliminato poichè nel web.config è possibile stabilire che il run-time imposti la cultura del thread corrente a quella di default del browser. Questo è possibile grazie al fatto che questo dato è inviato nell'intestazione HTTP ACCEPT_LANG. È anche possibile stabilire una lingua di fallback da utilizzare qualora questo header non contenga alcun valore.
<system.web>
<globalization uiCulture="auto:it">
</system.web>
Come per molti altri casi, i parametri impostati nel web.config possono essere sovrascritti a livello di pagina.
<%@ Page ... uiculture="auto" %>
La globalizzazione
La traduzione in diverse lingue non è l'unica caratteristica di un'applicazione fruibile da ogni parte del mondo. Ogni cultura ha propri modi di interpretare i numeri, le stringhe, le date, ecc. Popoli come i russi, i cinesi o gli arabi hanno addirittura un proprio alfabeto ed una diversa direzione di scrittura. Tutte queste considerazioni portano al concetto di globalizzazione, cioè il processo per cui non solo l'interfaccia, ma anche i dati vengono trattati correttamente.
La prima cosa da tenere in mente è la codifica del testo. Tutto quello che si vede su un computer non è altro che una serie di byte creati ed interpretati in una determinata maniera. Quando il modo in cui la serie di byte è interpretata è diverso da quello in cui è creata, quello che si ottiene è una serie di caratteri inutili.
Specificatamente, nell'ambito del colloquio client-server, il browser interpreta le risposte in base al character-set inviato negli header HTTP. Se questo non è riconosciuto, vengono visualizzati tanti caratteri (?) quanti quelli che non sono stati riconosciuti.
Il mancato riconoscimento può essere collegato all'invio sbagliato dell'encoding nelle intestazioni HTTP o alla mancata presenza sul browser dell'interprete del charset ricevuto. Basta pensare, per esempio, a quando si naviga su siti cinesi ed il browser richiede l'installazione del traduttore del Cinese Semplificato.
Se per la parte client non si può fare nulla, lato server la cosa importante è impostare il charachter-set della risposta qualora questo differisca da quello standard che è utf-8. Il browser invia i dati in post in base a come li interpreta, quindi, se non riconosce il charset li invia nel proprio formato standard. Per evitare problemi legati a questi charset, basta specificare sempre il formato in cui il server crea i dati spediti ed interpreta quelli ricevuti.
<globalization
fileEncoding="utf-8"
requestEncoding="utf-8"
responseEncoding="utf-8" />
I valori specificati nel web.config (esempio 18.14) sono quelli che l'applicazione usa di default, ma nulla vieta di sovrascriverli tramite codice a run-time in base alle esigenze.
Per evitare problemi di encoding, comunque, nel caso delle lingue occidentali è suggeribile utilizzare iso-8859-15 così da evitare l'utilizzo di un formato come l'UTF-8 che è pensato per garantire una compatibilità più ampia.
La formattazione dei numeri e delle date è altrettanto importante. Chi vive negli Stati Uniti è abituato a scrivere e vedere le date con il mese ed il giorno invertiti rispetto allo standard europeo. L'effetto si ottiene impostando una cultura di default sul web.config e reimpostandola a run-time (esempi 18.15 e 18.16).
<system.web>
<globalization culture="it">
</system.web>
System.Threading.Thread.CurrentThread.CurrentCulture = New System.Globalization.CultureInfo("en")
System.Threading.Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("en");
Conclusioni
È molto importante pensare alla localizzazione come ad una caratteristica di progetto sin dall'inizio dello sviluppo in modo da essere pronti nel momento in cui l'applicazione deve essere globalizzata.
Questo processo a posteriori è alquanto gravoso e lungo, mentre se intrapreso sin dagli inizi dello sviluppo è sicuramente più semplice.
La generazione automatica delle risorse locali unita alla gestione dei file di risorse rende semplice il processo di creazione e manutenzione. La localizzazione implicita ed esplicita insieme alla gestione automatica della cultura rende possibile lo sviluppo di pagine senza preoccuparsi del collegamento fisico tra i controlli e le risorse.
Infine, l'accesso tipizzato o tramite API alle risorse rende lo sviluppo del codice molto più semplice e meno soggetto ad errori. Insomma, rendere un sito accessibile a tutto il mondo è un compito molto meno gravoso rispetto al passato.
Speciale "ASP.NET 2.0 per tutti"
Elenco degli articoli tratti dal libro ASP.NET 2.0 per tutti scritto dallo staff di ASPItalia.com (Daniele Bochicchio, Cristian Civera, Riccardo Golia e Stefano Mostarda):
- 26 settembre 2006 - Personalizzazione dell'utente con le Profile API di ASP.NET 2.0
- 10 ottobre 2006 - Programmazione orientata agli oggetti - Prima parte
- 24 ottobre 2006 - Programmazione orientata agli oggetti - Seconda parte
- 7 novembre 2006 - BuildProvider, ExpressionBuilder e VirtualPathProvider
- 5 dicembre 2006 - Localizzazione e globalizzazione di applicazioni web - Prima parte
- 19 dicembre 2006 - Localizzazione e globalizzazione di applicazioni web - Seconda parte
2 pagine in totale: <<Indietro 1 [2]
Attenzione: Questo articolo contiene un allegato
Contenuti dell'articolo
Aggiungi un nuovo commento »»»
Per inserire un commento, devi registrarti alla nostra community.
Difficoltà
Utilità
Stampa 
Download
