Newsgroup: it.comp.www.php
Titolo: Come complicarsi la vita nella localizzazione di un portale?

Ciao,
ho un portale che dev'essere multilingua.
Il mio scopo è riuscire a separare il più possibile la struttura dal
contenuto e mantenere il più semplice possibile la struttura,
l'implementazione e (conseguentemente) la manutenzione della
localizzazione.
Ho già un sistema di localizzazione per le stringhe statiche facenti
parte della struttura (Titolo, menu, home page, pagina, Torna
indietro, pagina non disponibile, etc, etc....) con doppia possibilità
di caricamento da un file php oppure da una tabella del database.
Queste stringhe+chiave vengono trasformate in costanti per essere
utilizzate agevolmente ovunque nel portale.
Il problema è per i contenuti, che hanno invece una struttura molto
meno prevedibile, inglobabile od organizzabile.
Posso avere, ad esempio, due pagine strutturate in modo simile ma che
poi differiscono per poche parti, ma che mi rendono di fatto 'diverse'
le due pagine.
Alcune pagine, tipo le news, hanno una struttura più versatile e
quindi ho creato una tabella di localizzazione
TbNews che contiene gli attributi globali, tipo Id_News, Visibile,
Data, Autore
e
TbLingueNews che contiene invece un record per l'italiano, con Titolo,
Testo, etc, e un record per l'inglese con gli stessi tradotti.
Per queste non ho problemi.
Le pagine col contenuto più variabile al momento sono indicizzate nel
DB, in modo da gestirmele più agevolmente, e contengono il path fisico
dove andare a prendere il file.php da incluedere, dove sta scritto il
contenuto.
Però non so ancora come tradurle.
Ho cercato di mantenere il più possibile ambivalente la struttura, per
permettermi più strade.... però non riesco a scegliere quella giusta.
In mente ho:
1) Di continuare sulla stessa linea di adesso; scrivere la parte di
contenuto in file di testo "pagina.it.php", tradotta dentro a
"pagina.en.php" o "pagina.fr.php" e fare l'include da lì, e
ritrovandomi testo e HTML mescolati.
Facile per me ma più problematico da tradurre per chi non è avezzo al
linguaggio di markup... :-/
Questo approccio mi permette comunque di inserire un CMS con editor
WYSIWYG e modificare HTML e Contenuto (immagini o allegati) tramite
un'interfaccia (che dovrei costruire). Ed eventualmente ho la scelta
se tenere il contenuto su filesystem o su DB.
Ma, volendo mantenere il codice HTML accessibile e validato, non mi
permette molto controllo.
2) Strutturare in modo più dettagliato la localizzazione delle pagine,
avendo un record per ogni pagina, e un numero indefinito (e
variabile!) di stringhe da utilizzare all'interno della pagina.
In questo modo posso separare perfettamente il contenuto dal markup,
avendo una stringa per ogni paragrafo (per esempio) o per il titolo, o
per il title di un link.
Questo sarebbe il modo più affascinante (per me) di gestire il tutto,
perché mi permetterebbe un controllo enorme, sia sul codice HTML della
singola pagina, sia tra versioni localizzate della stessa pagina
(posso decidere se mantenere la struttura della pagina italiana o se
ho bisogno di variarla nella versione inglese).
Solo che mi pare 'un pochino' complesso da implementare (ma anche il
più soddisfacente! ^_^) e soprattutto da mantenere (ma mi fido delle
mie capacità crative per questo ;-P).
Questo approccio richiederebbe:
- Elementi/Pagine con associate N stringhe (ma possono essere anche M
per un'altra pagina o Y per un'altra). Se dovessi pensarla come
struttura SQL mi viene solo da pensare che avrei bisogno di tabelle
3Dimensionali!!! ^_^ (essì, il 3D è il trend del momento non solo
cinematograficamente! hihihi).... vabbè o anche un monte di Primary
Keys ... :)
E oltretutto ciò dovrebbe funzionare per N lingue in modo praticamente
automatico. Quindi NON voglio avere una tabella per ogni lingua. La
localizzazione dev'essere suddivisa per record.......
Al massimo potrebbero andar bene delle tabelle generate
automaticamente alla bisogna. :-)
- Un sistema di nominazione di tali stringhe in modo da evitare di
avere STR_1, STR_2, STR_3, STR_N, STR_M e non sapere affatto cosa
contengono.
- Un modo versatile di organizzare il tutto.
A voi viene in mente qualcosa per realizzarle?
Oppure qualche altra idea/proposta?
.... io getto l'amo. ;)
Ciao!
Pictor


Ciao. Ti rispondo sulla base delle mie esperienze, ma sappi che ho ancora 
molto da imparare...
Per prima cosa ti dico che ho preso l'abitudine, per la manuntenibilit�, di 
separare la parte di elaborazione dati da quella di output.
Cioe', nel visualizzare un modulo di una pagina, faccio l'include di due 
file in successione, ad esempio:
Devo caricare il modulo xxx.
Faccio prima l'include di xxx\xxx_preload.php e subito dopo di 
xxx\xxx_output.php.
E gia' questo mi aiuta parecchio a rimetterci le mani dopo tempo.
Per il multilingua invece creo una tabella multilingua per ogni tabella che 
lo richiede in questo modo:
tabella xxx:
- id (primary)
- campononmultilingua_1
- campononmultilingua_2
- campononmultilingua_n
dove appunto inserisco tutti i campi che non necessitano di traduzione in 
quanto date o numeri ecc.
creo in parallelo una tabella xxx_descrizioni:
- id (primary)
- id_xxx
- id_lingua
- campomultilingua_1
- campomultilingua_2
- campomultilingua_n
dove inserisco tutti i campi che necessitano di traduzione, avendo quindi un 
record per ogni lingua.
(id_xxx + id_lingua = index)
In questo modo estraggo i dati nella lingua corretta nella pagina 
xxx_preload.php e li memorizzo in variabili che poi utilizzo nell'unica 
pagina di output xxx_output.php rendendomi la manuntenibilit� come se si 
trattasse di un sito monolingua.
Ovviamente nella parte backoffice crei un sistema che ti permetta di gestire 
le variazioni sulla tabella lingue, magari definendo una lingua di default 
sicuramente presente da visualizzare nel caso non fossero ancora stati 
inseriti i valori della lingua da visualizzare.
Probabilmente non � la soluzione migliore ma mi trovo davvero bene.
Ciao
Max 


wrote:
Premesso che dipende dal cliente, quello che vuoi fare tu si potrebbe
realizzare nel seguente modo:
Lingua	Pagina	Chiave	Contenuto
ITA	*	Menu	Opzioni
ITA	home	Menu	Scelte
*	*	Menu	Menu
*	*	*	STRINGA_MANCANTE
Tutte le stringhe che devi localizzare, le marchi in qualche modo che
le renda facilmente riconoscibili, per esempio con le tre graffe o la
sequenza _(...).
Poi, quando devi sostituirle per la lingua, usando una preg callback,
sapendo che sei nella pagina "cippa" e la lingua e' "KLG", cerchi nel
database <KLG, cippa, CHIAVE> e sostituisci. E poi cerchi la versione
generica <KLG, *, CHIAVE> e sostituisci. Infine <*, *, CHIAVE>.
In questo modo puoi avere che in italiano per default {{{Menu}}} vien
fuori "Opzioni", ma nella pagina "Menu" viene fuori "Scelte". E nelle
lingue che non conosce ci lascia Menu.
Eventualmente puoi inventarti un segnalatore speciale
	<!-- PAGELOCALE pippo -->
e se trovi nella pagina in output <!-- PAGELOCALE ([^\s+]) -->, fingi
che quella pagina, anche se si chiama "home", si chiami \1. Cosi', ti
puoi scegliere delle "modalita'" indipendentemente dalla pagina.
Leonardo
-- 
The cock doth craw, the day doth daw,
the channerin' worm doth chide:
gin we be mist oot o' oor place,
a sair pain we maun bide.