sito multilingua con tag

[bendervinicio]

Salve,
Dovrei fare un sito con più lingue.
Le voci menu ovviamente devono essere diverse in base alla lingua scelta.
Cosa mi consigliate?
Creare un db con tutte le voci menu o Creare un file php da includere con le varie voci?

Vorrei sapere la soluzione più veloce e dinamica.

Grazie,
Alex

[zimok]

Io opterei più per la prima scelta, ovvero db mysql con le voci.
Un'altra soluzione possibile e flessibile sarebbe quella di scrivere le varie voci nelle diverse lingue in un file XML.

[bendervinicio]

Grazie della risposta.

Io avrei pensato a una pagina php da includere.
Ogni pagina inclusa contiene un array con le voci.
Detto in altre parole: Avrei Una cartella per ogni pagina che contiene i file php con gli array in varie lingue.
Nn so se mi sono spiegato.
Praticamente sarebbe com un db ma senza mysql.
Mi sembra comodo, che dici?

[pictor]

Sì anche io ho scelto di mettere nel DB una tabella di relazione tra TbMenu e TbLingue contenente

TbMenu
----------------
idMenu
LinkMenu
Visibile

TbLingue_Menu
----------------
IdMenu
IdLingua
NomeMenu
DescrizioneMenu

TbLingue
----------------
IdLingua
Descrizione
Abbreviazione
Abilitata




L'unica cosa su cui sono dubbioso è che, in fase di inserimento del menu, non so come gestirmela perchè non so se scegliere:
- La creazione di un menu localizzato in più lingue (grazie a TbLingue_Menu)
oppure
- La creazione di un menu per ogni lingua, ottenendo quindi dei contenuti diversi (non è lo stesso menu della versione italiana ma è un nuovo menu nella versione inglese, per esempio) anzichè delle traduzioni.

Per i menu non è un grosso problema. Più che altro me lo pongo per le pagine che dovranno essere localizzate.
Il secondo metodo è più versatile ma obbliga a inserire il contenuto moltiplicato per il numero di lingue; e se voglio effettuare delle modifiche al menu dovrò farle ad entrambe le versioni.

Cioè se ho lingua inglese ed italiana ed un menu "Contatti" nel DB avrò

Un record con ID=X e Descrizione="Contatti" e
un record con ID=Y e Descrizione="Contacts"

Mentre nel primo caso ho un solo menu co ID=X e due traduzioni nella relativa tabella.

Io credo che sceglierò la prima strada.
Voi che cosa ne pensate?


PS - Perdonate la prolissità
Nome

[pictor]

Originariamente inviato da bendervinicio
Grazie della risposta.

Io avrei pensato a una pagina php da includere.
Ogni pagina inclusa contiene un array con le voci.
Detto in altre parole: Avrei Una cartella per ogni pagina che contiene i file php con gli array in varie lingue.
Nn so se mi sono spiegato.
Praticamente sarebbe com un db ma senza mysql.
Mi sembra comodo, che dici?

Io l'ho fatto per un sito in ASP.

Ho una directory

/Sito/Language/Italiano
/Sito/Language/Inglese

Ed ogni cartella ha dei file con una versione tradotta delle stringhe contenute nelle pagine.
Su ASP creava problemi perchè è più complesso fare una include dinamica.

Con PHP credo sia molto più fattibile; inoltre ha il vantaggio di poter usare anche un array multidimensionale che contiene entrambe le localizzazioni.

Solo che con un array se vuoi stampare "CIAO" devi fare

- Italiano -
$lingua = 'IT';
echo $traduzione[$lingua]['Ciao'];

risultato: Ciao!

- Inglese -
$lingua = 'EN';
echo $traduzione[$lingua]['Ciao'];

risultato: Hello! 

mentre se memorizzi tutto in un DB hai una struttura più solida (con gli Array devi fare tutto tu a manina e se sbagli nessuno ti dice niente) e con una SELECT trovi direttamente il valore del campo passando la lingua come parametro.

Questo parlando di menu e contenuti inseriti dinamicamente....
per quanto riguarda le voci statiche di una pagine (come "Torna alla home page" o cose del genere) invece potrebbe essere più comoda la soluzione degli include.

Nel sito che citavo ho usato infatti gli include per le traduzioni statiche e il DB per quelle dinamiche.

Che mi dite invece della mia questione sulla 'Traduzione' degli elementi o la 'Duplicazione Localizzata' degli elementi?

[bendervinicio]

grazie dei suggerimenti

[pictor]

Uaaaaaah!!

Li voglio anche io i suggerimenti!!!

Mi sa che dovrò azzardare la cosa della traduzione, per poi scoprire che avevo sbagliato scelta, per infine riprogrammare tutto da zero!

[daniele_dll]

ti consiglio di seguire una strada mista

Ovvero su disco tenere tutta la lingua "statica", ovvero che serve per i template, mentre su DB creare un set di tabelle ad hoc contenenti la lingua dinamica

Quando il sistema parte prima cerca nella lingua statica che ha già caricato in memoria, poi cerca nella cache che ha in memoria della lingua dinamica ed infine controlla sul database, andandosi a creare la cache di quello che tira fuori

Per cache intendo un semplice array di tipo

LINGUA => NAMESPACE => CHIAVE => VALORE

Dove:
- lingua corrisponde alla lingua corrente nel formato standard ISO, ovvero it_IT ... en_EN ... en_US e cosi via, in modo da poter leggere dal browser la codifica corretta da usare (se fate un bel var_dump($_SERVER) scoprirete che il browser vi indica quali sono le lingue "preferite" con quella di default all'inizio e poi le altre con una percentuale di preferenza)
- namespace è una stringa, separata da punti, che serve a indicare dei raggruppamenti in questo modo il namespace Blog.User conterrà tutte le parole/frasi che riguardano le informazioni degli utenti del blog, o ancora Administration.Blog.User conterrà altre parole/frasi usate dall'amministrazione, senza però clonare quelle di Blog.Users
- chiave indica semplicemente il nome della chiave, che consiglio di tenere in formato Camel Case ed in lingua inglese, ovvero qualcosa tipo Name, Surname, BornDate (ergo data di nascita) e cosi via
- valore, infine, la frase tradotta contenenti eventuali %s, %i, %d e cosi via per poter inserire dei valori nella frase tradotta

Sfruttando quel sistema si ha la libertà di fare ad esempio una chiave di tipo WelcomeUser contenente "Welcome %s" o "Benvenuto %s" e passare la variabile al metodo che vi estrae il valore richiesto o ancora fare semplicemente Welcome come chiave con i relativi valori e poi accodare il valore da tradurre

Magari quest'esempio non rende al massimo, ma implementare questa funzione è estremamente semplice e nel contempo da maggiore flessibilità

La necessità di implementare dei namespace è perché potete raggruppare in questo modo i contenuti tradotti con facilità evitando di ritrovarvi con enormi ed ingestibili tabelle

il namespace lo si accorpa nel nome della tabella ... ovviamente facendo si che al massimo il namespace contenga lettere, numeri e punti ... lettere che vengono poi convertite TUTTE in minuscolo e punti che vengono convertiti TUTTI in underscore (non si possono usare i punti nei nomi delle tabelle)

Ad esempio, le tabelle poi si chiameranno

i18n_languages

dove staranno l'accoppiata
codice iso | abilitata

e poi, ad esempio

i18n_traslations_languages

strutturata cosi
chiave | codice iso | traduzione

nel caso specifico questa tabella andrebbe a contenenre le traduzioni della lingua ... quindi se abbiamo inglese ed italiano ci starebbe dentro una chiave che corrisponderebbe al codice iso da tradurre, il codice iso della lingua ... e la traduzione ... quindi direi

it_IT | it_IT | Italiano
en_US | it_IT | Inglese (Americano)
en_GB | it_IT | Inglese (Gran Bretagnia)
it_IT | en_US | Italian
en_US | en_US | English (American)
en_GB | en_US | English (Great Britain)
it_IT | en_GB | Italian
en_US | en_GB | English (American)
en_GB | en_GB | English (Great Britain)

en_GB e en_US sono i codici relativi alle lingue inglesi della gran bretagnia (inghilterra) e dell'america ...

un'eventuale tabella di supporto, molto comoda, che ho implementato da poco, sono gli alias ... in questo modo un eventuale en_GB invece di clonarsi ovunque può essere gestito come un en_US

i18n_languages_aliases

con campi tipo

codice iso | codice iso alias

dove codice iso è il codice iso da ridirezionare e codice iso alias è il codice iso da usare vero e proprio

Ancora un altra tabella, nel caso del blog e dell'esempio fatto prima potrebbe essere

i18n_traslations_blog_user

e dentro

Welcome | it_IT | Benvenuto
Welcome | en_US | Welcome
Welcome | en_GB | Welcome



La struttura delle tabelle per le traduzioni dovrebbe essere un

VARCHAR(50) | CHAR(5) | TEXT

l'ultimo campo come text perché i contenuti che si vanno a caricare di solito si evita di farli "troppo" grandi

Questa struttura può essere usata anche per usare immagini diverse e cosi via ... insomma il limite è sempre la fantasia