Newsgroup: it.comp.www.php
Titolo: Sito multilingua....idee?

Avete metodi preferenziali, consigli, suggerimenti su come realizzare 
un sito multilingua, tra le varie possibilità? Pro/contro?
rob4you


Bhe, una soluzione è creare dei file .php indipendenti con una serie
di variabili o un'array con il testo. In questo modo puoi gestire più
lingue.
Potresti anche scriverti una funzione che legga la lingua del browser e
carichi di conseguenza il file corretto.

 lingue.
Cosa intendi file indipendenti? Un file per ciascuna lingua (cioè, N 
file per ciascuna lingua per ogni pagina del sito)?
E le variabili o gli array in questo modo come li uso?


leggi la variabile dal browser la salvi in una sessione
in base a quello che trovi nella sessione fai la query
li avrai una tabella x ogni lingua del sito
e se lo voglio leggere in inglese ?

 wrote:

In genere io uso due metodi. Il primo è nel caso che il sito sia
bilingue e il secondo invece con + lingue.
Nel primo realizzo le tabelle con doppi campi e poi estrapolo i dati che
mi servono con query subordinate alla lingua scelta.
I vantaggi sono che che i riferimenti ai record sono sempre gli stessi e
quindi puoi commutare da una lingua all'altra in qualsiasi pagina. Altro
vantaggio è che chi inserisce i dati è obbligato ad eseguire gli
inserimenti in tutte e due le lingue. Mi sono capitati casi di
amministratori che inserivano solo la lingua taliana per poi
dimenticarsi il resto, e se visitavi il sito in inglese questo era
desolatamente vuoto.
Nel secondo caso invece uso tante tabelle quante sono le lingue.
Probabilmente questo è il sistema migliore, puoi aggiungere quante
lingue vuoi e le gestisci come ti pare. Il Db è normalizzato, ecc ecc 
Però ho avuto appunto casi in cui non venivano fatti degli inserimenti
sincronizzati, come dicevo sopra.
Per quello che riguarda i titoli del sito, di solito salvo dei files che
contengono un array di traduzioni e poi piazzo dei "segnaposto"
nell'html della pagina.
Max
-- 
http://www.maxori.it

 e se lo voglio leggere in inglese ?
E lo chiedi a me? lol
rob4you

 nell'html della pagina.
Ma questo lo fai "solo" per i titoli, o anche per qualsiasi contenuto 
"statico"?
rob4you

 
Ma scusa qual'è la tua difficoltà?
se hai un record con un semplice campo lingua .. basta eseguire la query 
  selezionando quella lingua .. se invece (come nell'esempio precedente) 
hai i campi che ti rappresentano la lingua esempio titolo_IT e titolo_EN 
quando esegui la query invece di recuperare tutti i campi ti basta fare
SELECT titolo_IT as titolo FROM tabella WHERE id = 1
in questo modo nel codice avrai sempre la tua variabile titolo che 
discerni direttamente nella query ;)
-- 
SEZIONE RECUPERO LAVORO: Lancio di una nuova lavatrice sul mercato, due 
morti e sei feriti.
[CapoBecchino] - hotmail/msn: capobecchino [@] hotmail [.] com

 "statico"?
Tutto quello che necessita di traduzione; pulsanti, scritte di risposta
ringraziamenti, ecc ecc
Max
-- 
http://www.maxori.it

 Includo il file delle traduzioni nella pagina
Lo so che ti sto angosciando...e pure parecchio! :-) Ma non ho capito 
se tu usi files di testo in cui metti le traduzioni, e poi le vai a 
sostituire ai segnaposti, appunto includendo una volta sola il file 
nella pagina; oppure se memorizzi le traduzioni in tabelle del db, e in 
tal caso come le recuperi (es. mille contenuti: mille chiamate al db; 
oppure mille contenuti: una sola chiamata al db ma massiccia).
rob4you

 SELECT titolo_IT as titolo FROM tabella WHERE id = 1
Giustissimo! :-) ma quindi, il dubbio che mi attanaglia :-), a 
prescindere dal numero di lingue è: per recuperare i contenuti, faccio 
ogni volta una query al db (come nell'esempio che tu mi hai riportato)?
rob4you

 wrote:

Mi sa che ti preoccupi forse troppo delle query che possono appesantire
la pagina, in realtà la velocità di esecuzione dei comandi dipende dalla
quantità di record presenti nel DB più che dalla query stessa.
Se anche esegui tre query (traduzioni, menu, contenuti) non hai un
sensibile rallentamento.
Max
-- 
http://www.maxori.it

rob4you ha scritto:

Si se uso il db come contenitore dei dati .. ma no se non uso il db come 
contenitore dei dati .. ma questo esula dal tuo problema perchè come ti 
è stato spiegato se devo usare un db per un sito che farà si e no 100 
visitatori al giorno allora il problema nn si pone e posso benissimo 
fare le 100 query .. :D
se invece il sito fa 1.000.000 di visitatori al giorno allora potrebbe 
porsi il problema che logicamente se è la semplice query per recuperare 
il risultato non rallenta di molto :D ma ogni caso è separato ..
in tutti i casi tu discerni i risultati in base alla lingua. se hai il 
db usi la variabile per impostare la query .. se usi il filesystem usi 
la variabile per discerne il nome/cartella dove sono contenute le tue 
traduzioni ;)
-- 
SEZIONE PICCOLI ACCORGIMENTI: "Chiamami un tassì", mi disse prima di 
morire e sulla sua lapide ho scritto: "Qui riposa in pace Untassì".


 sensibile rallentamento.
Sono d'accordo.
In fin dei conti, anche il sistema di localizzazione di Linux funziona
allo stesso modo, solo che ci sono database in formato testo, con hash,
per le stringhe.
Fare una query su un DB SQL non e` molto piu` pesante che farla su un GDBM.
Di sicuro leggere una stringa da un file di testo non indicizzato, e che
quindi richiede il parsing, e` molto piu` pesante.
Considera anche che uno script PHP ha vita breve. A meno che non carichi
tutto il file con la traduzione nella sessione dell'utente (appesantendo
tutto il server), la velocita` di accesso sara` minore.
Quindi consiglio un DB SQL, qualcosa del genere:
create table sito_lingua (
  str varchar(255),
  trad varchar(255)
) unique index(str)
oppure le funzioni di localizzazione di Linux.
In entrambi i casi se molta gente accede a quella lingua, il file/DB viene
bufferizzato e accelerano le ricerche.
Bye.

 ) unique index(str)
Seguendo la struttura consigliata, potresti utilizzare anche questo:
http://pear.php.net/manual/en/package.authentication.auth-prefmanager.php
	Francesco

 un sito multilingua, tra le varie possibilità? Pro/contro?
ti dico come faccio io ... e' un metodo come un altro :
bandierine sul sito, che settano un cookie (il primo cookie viene impostato
dalle impostazioni del browser).
poi query sul db, che ha campi tipo:
titolo,titolo_en,titolo_fr
stitolo,stitolo_en,stitolo_fr
testo,testo_en,testo_fr
qui hai due possibilita': o configuri a "monte" la query sul database,
facendo selezionare le colonne nella lingua, o selezioni tutti e poi
decidi quale mandare nella pagina ... io ho scelto la seconda soluzione,
anche perche' alcune pagine non ci sono nelle altre lingue, e di default
deve uscire almeno una notizia !!
quindi faccio la query di tutte le colonne e poi mando il cookie e le
row ad una funzione del tipo:
function get_notizia_lang($row,$lang)
{
	if (preg_match('/^en.*/',$lang) && strlen($row['acca3_en']))
		return array($row['titolo_en'],
			$row['stitolo_en'],$row['testo_en']);
	else
	if (preg_match('/^fr.*/',$lang) && strlen($row['acca3_fr']))
		return array($row['titolo_fr'],
			$row['stitolo_fr'],$row['testo_fr']);
	else
		return array($row['titolo'],
			$row['stitolo'],$row['testo']);
}
richiamata con qualcosa tipo
list($titolo,$stitolo,$testo)=get_notizia_lang($row,$cook);
echo '<h1>'.$titolo.'</h1>'.
	'<h3>'.$stitolo.'</h3>'.
	'<hr>'.$testo.'</hr>';
potresti fare anche una query con un 'CASE' ...
ciao ...
-- 
#include <stdio.h>
int main(void){char c[]={10,65,110,116,111,110,105,111,32,98,97,114,98,111,110,
101,32,60,104,105,110,100,101,109,105,116,64,116,105,115,99,97,108,105,110,101,
116,46,105,116,62,10,10,0};printf("%s",c);return 0;}

> ti dico come faccio io ... e' un metodo come un altro :
Grazie di tutti i tuoi consigli.
rob4you

 per discerne il nome/cartella dove sono contenute le tue traduzioni ;)
Ok, recepito il messaggio... ;-) grazie mille.
rob4you

 
http://pear.php.net/manual/en/package.authentication.auth-prefmanager.php
Grazie e tutti per i consigli, ora mi è più chiara la situazione. 
Ovviamente se sorgeranno altri dubbi....tornerò a rompervi! :-D
rob4you

>xml<<
+veloce
+semplice
+modificabile
+dinamico
ricerca nei post passati sull'argomento e lo trovi

io creo una file php tipo:
lang.ita.inc.php
in questo file ci butto dentro le variabili e le traduco:
es:
$txt_lang_goodmorning = "buongiorno";
ovviamente nel file
lang.eng.inc.php
$txt_lang_goodmorning = "goodmorning";
poi nell'output ci metto solo le variabili, grazie a cio' riesco
a leggere le variabili nella lingua corretta.
vantaggi:
1. se voglio una lingua in + mi basta creare 
$txt.lingua.in.php e tradurre le variabili nella lingua che desidero.
ovviamente in viene sempre richiamata la pagina grazie ad un file
include che
include ('txt.'.$lingua_session.'.inc.php');
e talvolta capita che di mettere pure le variabili nella tabelle.
tipo table_main_category ci metto la categoria $txt_lang_man
che fara' l'output uomo, man, monsieur, Herr ecc ecc...
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 +dinamico
Anche questo e` vero, ma non mi pare serva molta dinamicita` in un sistema
di localizzazione. Devi semplicemente dargli una stringa in una lingua
pre-decisa e lui deve tornartela in un'altra lingua.
Non serve altro.
Bye.

 e talvolta capita che di mettere pure le variabili nella tabelle.
Sei stato chiarissimo, tks! :-)
rob4you

 rob4you

>> xml<<
Premesso che la soluzione "perfetta" non esiste, ognuno di noi ha dato 
la sua opinione, quindi l'xlm è una possibile soluzione come un array 
multidimensionale, una serie infinita di define suddivise in include 
file o cos'altro hai in mente, inoltre ogni soluzione deve essere 
contestualizzata: un conto sono 5 frasi da localizzare, un intero 
dizionario è un'altra cosa
	Francesco

 +dinamico
E tu come lo usi l'xml?
rob4you

 wrote:

Rispondo anche se la domanda non è rivolta a me.
Io uso i files con traduzioni quando queste sono + o - n numero
predefinito, se prevedi un numero variabile allora è meglio gestire le
traduzioni come qualunque dato del Db.
Alla fin fine dipende da quanti titoli prevedi di mettere in un sito.
Max
-- 
http://www.maxori.it

 traduzioni come qualunque dato del Db.
Ma perché nel caso di N lingue predefinite preferisci i file, mentre 
nel caso di K lingue variabili [con K variabile tra K e K+x] opti per 
il db?
Da un punto di vista non è esattamente la stessa cosa?
Nel caso di un db, se aggiungi una nuova lingua, ciò implica aggiungere 
una nuova tabella.
Nel caso di un file di testo, l'aggiunta di una nuova lingua comporta 
la creazione di un nuovo file di traduzione (a meno che le traduzioni 
non vengano messe tutte in una pagina, e forse per questo con un numero 
fisso potrebbe essere comodo ciò che dici tu).
In tutta la discussione mi è sorti un dubbio, non strettissimamente 
legato al multilingua: se come hai detto tu (e molti altri), una 
traduzione di una lingua viene messa in n record della tabella 
appropriata (del tipo "variabile CHAR(25), traduzione VARCHAR(255)"), 
tale strutturazione in tabelle va bene SOLTANTO per dati dello STESSO 
tipo (e cioè in tal caso VARCHAR(255))?
Se quindi voglio gestire altri tipi (FLOAT, INT, DATE, BLOB, ecc...) 
devo creare una tabella per ogni tipo diverso (e moltiplicarla per le N 
traduzioni)?
rob4you

 rob4you
Vedi tu, in genere le idee vengono lavorandoci sopra. Tutti i progetti
sono diversi ed è difficile dire a priori cosa serve o no.
Ultimamente ho collaborato ad un progetto di un portale e di tabelle ce
n'erano 110, e un terzo di queste erano tabelle per le relazioni da
molti a molti, ma in partenza erano mooolto meno.
Max
-- 
http://www.maxori.it

 traduzioni)?
OK che parli di "non strettamente legato al multilingua", ma non ho
capito, nel caso del multilingua, a cosa ti serva tradurre dei numeri e
delle date. Nel primo caso usi number_format, nel secondo memorizzi il
timestamp e traduci nel formato regionale adatto.
Mi puoi fare un esempio di necessita` specifica?
Bye.

 Mi puoi fare un esempio di necessita` specifica?
Infatti diciamo che questa mia domanda era un po' slegata dal 
multilingua, ma centrava più con l'inserimento di contenuti in db 
(quindi, nel caso di una sola lingua: una tabella per ogni "tipo di 
dato"?).
Comunque...vediamo....:-)...i numeri.....uhm.......ad esempio i prezzi. 
Si, è vero che potrei memorizzarli in una valuta soltanto e solo al 
momento opportuno tradurre ogni prezzo.
Svantaggio: i tassi di cambio variano continuamente, quindi se 
memorizzo una volta per tutte il prezzo in tutte le valute, rischio di 
avere una cifra non aggiornata.
Soluzione: potrei memorizzare nel db il prezzo nella valuta originale, 
e poi avere una variabile "tasso di cambio" in un'apposita tabella (o 
da qualche altra parte), con i tassi aggiornati per ciascuna lingua. In 
tal caso avrei comunque bisogno di una tabella "a parte" per gestire i 
"numeri" (genericamente parlando).
Per quanto riguarda le date, son d'accordo sul timestamp. Ma se non 
erro il timestamp vale dal 1970. Quindi, ipotizzando date di nascita, 
presumibilmente ci saranno anche date antecedenti al 1970.
Quindi in tal caso potrei memorizzare la data in un'unica tabella in 
tre (o piu) campi distinti (anno, mese, giorno, [ore, minuti, 
secondi]).
Però poi devo sapere che se scelgo ad esempio la lingua inglese, il 
formato sarà qualcosa del tipo 24th November 2006, 1:30pm (o qualcosa 
di simile, comunque diversa dall'italiano).
Mi son spiegato?
rob4you

 aggiornata.
Mi sono espresso male: questo svantaggio è legato a memorizzare nel db 
tutti i prezzi nelle varie valute.
rob4you

rob4you ha scritto:

se fai col db ogni campo che crei mettimo varchar222 anche se mezzo
vuoto verra' allocato lo stesso tutto lo spazio per niente e in piu'
devi fare la query con annessi e connessi.(soluzione comoda)
mentre se tu lo metti in un file e' piu' semplice e veloce sia da
correggere che da gestire.(soluzione "impegnativa")
chettidevodire in +?

 correggere che da gestire.(soluzione "impegnativa")
Perché l'ultima è una soluzione "impegnativa"? Cosa ha di tanto 
impegnativo? A me sembra addirittura più immediata rispetto 
all'inserimento in un db.
E inoltre...anche io sto avendo le stesse perplessità sul perché 
preferire un db o un file relativamente alle traduzioni. Alcuni hanno 
scritto le loro preferenze a riguardo, ma non ho capito il perché 
preferiscano una soluzione o l'altra.
rob4you

 multilingua, tra le varie possibilità? Pro/contro?
Caso di studio ;-): per quanto riguarda il manuale di php (diciamo la 
versione per il web) sapete per caso come è realizzato nelle sue 
multi-lingue?
Come avrete notato, ad esempio, anche nella traduzione italiana, 
talvolta ci sono pezzi non tradotti in inglese (che sarà appunto la 
lingua di default).
rob4you

rob4you ha scritto:

bhe' il db e' piu' semplice hai le query, le tabelle e i campi. Un
gioco da ragazzi.
Mentre nel caso ad esempio dell'xml hai tag che poi devi allineare con
il codice php.
Cioe' con le tabelle hai un ordine logico concettuale mentre con il
file diciamo che risulta + facile fare caos in quanto il file rimane
pur sempre un oggetto sequenziale a pila. Di primo impatto. Ma poi con
il passare del tempo ti accorgi ;)

 il codice php.
Ah tu ti riferivi all'uso di file xml.
Ma perché si dovrebbero usare file xml per le traduzioni? Come ti ha 
risposto Alessandro, alla fine dei conti i vantaggi dell'uso di xml in 
questo contesto sono limitati (o non ci sono proprio).
A sto punto è ancora più semplice/comodo utilizzare un comunissimo file 
di testo per le traduzioni.
Magari fai un esempio, anche piccolo, su come utilizzare un file xml 
per le traduzioni, così mi rendo meglio conto di ciò che intendi tu.
rob4you

 Ah tu ti riferivi all'uso di file xml.
si forse e' vero che sono superflui gli xml, ad ogni modo ti devi
inventare te un separatore etc..

 come metodo
L'avevo nominato io, ma non mi ricordavo come si chiamava la funzione,
perche` in quasi tutti i linguaggi viene usato come alias l'underscore,
quindi ci si trova roba come
print _("Ciao mondo");
E` da li` che ho "preso spunto" per la versione su database con due
colonne. :)
Bye.



ora che me lo dici... hai perfettamente ragione :-D , ho letto tutto il
thread giorno per giorno e non tutto insieme e quel "sistema di
localizzazione linux" non me lo ricordavo proprio... ricordavo soltanto il
database
comunque sono arrivato a gettext proprio perchè in questi giorni sto
provando diverse distribuzioni live di gnu/linux e quando mi sono
imbattuto in un .mo volevo vedere cosa stavo realmente facendo... da li
ho ricollegato gettext con il gettext che avevo letto nella lista delle
funzioni del manuale di php, ma che non ero andato mai a leggere
veramente.... naturalmente ho rimediato subito :-D
P.S. forse presto verrò a rompervi su it.comp.os.linux.* è un po' di
tempo che vi lurko :-P e il cestinamento completo di win è alle porte...