JoomlaStaff
Home      Scambio Link    Web marketing     Php       
Cerca il tuo dominio qui!
COME PROGETTARE SITI MULTILINGUA IN PHP CON DATABASE

Quando si decide di internazionalizzare le proprie applicazioni bisogna studiare sistemi per permettere di gestire tutte le risorse con le quali operiamo in modo che siano dipendenti dalla lingua scelta . Precedentemente abbiamo visto come utilizzare gettext e le librerie di conversione tra charset ( Iconv e Mbstring ) per gestire l'internazionalizzazione delle stringhe all'interno dei propri script o provenienti dall'esterno, oggi invece tratteremo in modo più specifico qualche soluzione pratica per internazionalizzare le informazioni presenti all'interno di un database.

Purtroppo l'internazionalizzazione dei campi non è gestita nativamente dalla maggior parte dei database, e quindi bisogna organizzare le proprie strutture in modo che risulti possibile localizzare i nostri dati senza complicare eccessivamente la struttura delle relazioni. I sistemi utilizzabili sono molti e spesso bisogna sviluppare soluzioni specifiche per le circostanze in cui ci si trova a lavorare, ma possiamo adattare degli accorgimenti standard che ci verranno incontro in molte di queste situazioni.

Ovviamente il database si occuperà di fornire una struttura capace di essere interrogata per ottenere dati in una determinata lingua, ma tutte le eventuali operazioni di conversione dei caratteri o formattazione del testo saranno demandate a PHP.

Alcune informazioni importanti

Prima di addentrarci praticamente nel codice necessario a strutturare correttamente la nostra applicazioni, è utile discutere di alcune informazioni importanti relative alla conversione dei valori, alla loro rappresentazione e all'eventuale perdita di informazioni legata al passaggio di internazionalizzazione.

L'obiettivo iniziale quando si decide di strutturare una base di dati è quello di avere dati uniformi, in modo che sia possibile mantenere meglio il codice e facilitare le interrogazioni; per questo motivo, all'interno di un database, è fondamentale mantenere il più possibile indipendente la rappresentazione dei valori dalle informazioni relative alla localizzazione, salvo eccezioni in cui i dati uniformati perderebbero informazioni rispetto a quelli iniziali. Possiamo evidenziare alcuni esempi di situazioni in cui utilizzare questa politica.

La rappresentazione testuale di numeri decimali a virgola fissa viene effettuata differentemente in base alla cultura ed alla lingua di un utente. Per esempio gli inglesi utilizzano la virgola per separare le migliaia ed il punto per separare la parte intera da quella decimale; al contrario noi italiani utilizziamo il punto per le migliaia e la virgola per i decimali. In questa situazione è necessario uniformare i valori decimali al formato accettato dal database (solitamente quello inglese) e successivamente apportare le trasformazioni per riadattarlo alla lingua del visitatore.

Le sono un'altra situazioni in cui è fondamentale procedere con le dovute precauzioni: basta perdere per strada poche informazioni per rischiare di compromettere l'integrità dei dati e la loro credibilità. Nel caso in cui ci si trovi a lavorare su applicazioni che devono fornire agli utenti prezzi con valute differenti, è assolutamente necessario salvare i dati nella valuta utilizzata dall'utente, affiancandovi informazioni sulla localizzazione. In questo modo si evitano problemi legati ad incomprensione delle valute. Nel caso si siano calcolati i valori partendo da una valuta di base a cui è stato applicato un indice di conversione, sarebbe opportuno salvare anche questo indice come identificativo della conversione stessa. La formattazione delle valute può essere successivamente effettuata in base alla valuta stessa.

Le informazioni relative a date e tempo sono solitamente convertite in UTC a cui viene affiancata l'informazione relativa alla time zone. La conversione al formato di visualizzazione corretto viene fatto successivamente senza perdita di informazioni.

Infine abbiamo le stringhe : il valore di una stringa è determinato dalla sequenza di caratteri in essa contenuti, non dalla sua codifica; per questo motivo salvare stringhe in differenti codifiche all'interno del database può portare ad una serie di problemi successivamente. Per questo motivo è buona norma scegliere una codifica unica (UTF-8 potrebbe essere un'ottima scelta dato il supporto per un gran numero di set di caratteri) e convertire i valori a questa prima di salvarli sul database, per poi riportarli alla codifica necessaria prima di restituirli all'utente.

Ovviamente tutte queste situazioni che abbiamo analizzato si riferiscono a situazioni tipiche; potrebbe risultare che, soprattutto per motivi commerciali o funzionali, risulti necessario procedere in modo differente.

  Siti partners :    Article marketing