Newsgroup: it.lavoro.professioni.webmaster
Titolo: URL design e sito multilingua

Salve,
sto cercando info per la costruzione corretta di un sito multilingua.
Prendiamo ad esempio la struttura più classica e banale di un sito (chi
siamo, prodotti e contattaci) costruito in 3 lingue: italiano, francese e
inglese.
Qual'è il modo corretto di costruire l'architettura del sito?
1. creare 3 sezioni principali, 1 per ogni lingua (italiano, francese e
inglese), e al di sotto di esse costruire la struttura del sito (chi siamo,
prodotti e contattaci) ottenendo un url di questo tipo:
www.miosito.com/italiano/chisiamo/
,  
www.miosito.com/italiano/prodotti/
,
www.miosito.com/italiano/contattaci/
, 
www.miosito.com/francese/chisiamo/
etc...
2. creare la struttura del sito e al di sotto di ogni sezione creare una
directory per ogni lingua ottenendo un URL di questo tipo:
www.miosito.com/prodotti/italiano/
, 
www.miosito.com/prodotti/francese/
,
www.miosito.com/prodotti/inglese/
 etc...
Inoltre dato che il sito è multilingue è corretto l'uso di una terminologia
per l'URL in inglese o in italiano? Si tratta cmq di un'azienda italiana.
Grazie,
Max


Nessuna delle due soluzioni, visto che oramai per fare siti di più di 4 
pagine è utile appoggiarsi a soluzioni di content management, inoltre 
devi porti il problema se i contenuti saranno una "copia" di tutto o se 
possono essere strutturati diversamente. La solzione 1 è sicuramente più 
flessibile anche se "antiquata".
Saluti
Cla!
-- 
http://www.docebolms.org
 :: E-learning open source
Oggi, 6 luglio 2005, mi sento più Europeo


L'approccio più corretto è realizzare la base su cui poggiano i contenuti 
una volta sola per tutte le lingue che siano 3,. 5, 10, 20, 1000 poco 
importa.
Quindi attraverso un identificativo richiamare i contenuti relativi alla 
lingua scelta da un database e appiccarli li, dinamicamente.
Il vantaggio cosi è che se devi apportare una modifica al contenuto lo fai 
direttamente sul database senza influenzare ne il codice php ne il codice 
html ne altro.
Cooper.
-- 
BlueWare WebStudio
 [web:] 
http://www.blueware.it
 [msn:] 
coo...@blueware.it
 [icq:] 146781935 

 Cooper.
Venitemi a spiegare perché allora IBM usa un approccio come uno di quelli
che ho descritto io.
IBM che di server e database fa scuola. Usare un database per mettere una
marea di porcate mi sembra esagerato. Non influenzare il codice php? Non è
detto che c'é programmazione back-end. E poi se metti le mani nel DB non
"influenzi" il DB???
Posso continuare con Apple, Microsoft etc...
Fare un sito con una connessione al DB significa non solo cambiare i
contenuti dal DB ma anche i riferimenti alle immagini, agli stili css etc...
A questo punto conviene usare un CMS. Ma a che serve un CMS per un sito che
non ha assolutamente bisogno della "gestione dei contenuti"?
Fare un sito piccolo (4 pagine) e metterci un CMS è, scusate, una stronzata.
Si appesantisce inutilmente un sito che nasce volutamente piccolo e quindi
veloce...
Ma poi, per curiosità, ve lo fate pagare il setup del CMS dai vostri
clienti?
Max

 Qual'è il modo corretto di costruire l'architettura del sito?
[...]
Prova a guardare questo link (
http://tinyurl.com/8ucos
). Quelli 
descritti sono i metodi più comuni.
ciao
-- 
MM > 
http://www.thepixel.it

 clienti?
No, lavoriamo pro-bono. Sicuramente un setup di un CMS costa meno di te 
che gestisci le pagine a manina ...


 Posso continuare con Apple, Microsoft etc...
Attenzione che ci sono anche dei CMS che quando fai il deploy del sito te lo 
generano statico ma in realtà a livello di authoring del  sito il backend è 
un CMS.
I vantaggi di questo sono che mentre a livello di authoring sviluppi il sito 
utilizzando dei template per la struttura/grafica del sito ed il contenuto è 
separato e mantenuto in un db quando fai il deploy ha in sito completamente 
statico cho notevoli guadagni di performance.
Altra cosa importate, è che ci sono anche  CMS che fanno url rewriting a 
livello di http context, in pratica, quando tu vedi un url del tipo 
http://www.nomesito.tld/italiano/prodotti/12223.html
 questo viene riscritto 
in 
http://www.nomesito.tld/itemget.aspx?langid=39&catid=50&itemid=12223
. 
Questa riscrittura non la vedi mai poichè è fatta livello di http context, 
non è un http redirect che ti cambia l'indirizzo nella barra del tuo 
broswer, pertanto tu credi di navigare su un sito statico in realtà non è 
cosi. I vantaggi di questo, per foare solo un esempio, sono l'indicizzazione 
dei motori di ricerca.
Non entro nel merito di usare o meno un CMS per 4 pagine, diciamo però che 
quando uno non conosce un'H di html anche per 4 pagine potrebbe gradire un 
CMS, per tenere "sotto controllo" il proprio sito.

Non me ne frega niente dei CMS, altrimenti avrei posto un'altra questione.
Non ho detto che c'é un elenco prodotti, ho ipotizzato 3 pagine.
Non ho detto che IBM non usa il CMS, anzi semmai ho lontanamente detto il
contrario.
Non è una novità che IBM usa un CMS, li fa e li vende.
Non farei un sito come IBM senza CMS ma nemmeno uno piccolo con CMS.
IBM usa l'approccio 2, ma Apple (tanto per citare) e tanti altri usano
l'approccio 1. Vedi bene. Come mai?
E' chiaro che io "vedo" la pagine web come html o qualsiasi-altra-cosa
mentre dietro c'é un CMS con tanto di gente coi controcoglioni che li usa,
MA - dico MA - come vedi l'URL è scritta in maniera chiara dove c'é ANCHE la
lingua o il paese.
E' questo che io ho chiesto: l'URL design. Q-U-E-S-T-O. Niente di più
semplice.
Che sai usare un pò di php, linguaggio tra l'altro poco adatto per creare i
CMS anche se ce ne sono a bizzeffa, e vendi CMS o giù di li non mi
interessa.
Modificare a manina? Per cambiare una virgola o un accento apri un CMS
invece che una pagina .htm? Fa figo eh? :DDD
Che bravoooo...
Max

 CMS, per tenere "sotto controllo" il proprio sito.
Ecco, bravo.
Ciao,
Max

 semplice.
Se dietro ci sta un CMS, usare un approccio piuttosto che l'altro potrebbe 
non avere gran chč significato, come ti ho scritto nell'altro post, facendo 
url rewriting accomodi l'url come vuoi, l'ordine potrebbe non avere granchč 
importanza.

 contrario.
Mangiato pesante?
Per quanto riguarda la tua questione ti ho già risposto nel primo 
thread: *devi porti il problema se i contenuti saranno una "copia" di 
tutto o se possono essere strutturati diversamente*


Comunque, lasciando stare le CMS-snobberie, io preferirei strutturarlo 
lingua/sezione diventa più facile aggiungere o cancellare delle lingue e 
ogni lingua può essere considerata come un mini sito indipendente.
Inoltre ti permette di localizzare anche gli url, che non guasta: quindi 
avere /italiano/libri/.. e /english/books/.. ecc.
 


questo approccio va bene se i contenuti sono indipendenti ovvero, se le 
versioni dei testi nelle varie lingue sono svincolati fra loro; ad esempio 
del portale yahoo, abbiamo la versione inglese, la versione spagnola etc etc 
li non tutte le pagine sono uguali (vedi ad esempio la parte delle notizie).
In tutti gli altri casi è meglio avere una base comune statica e i contenuti 
dinamici su di essa.


 Cooper.
Ha ragione lui, partire dal concetto che le versioni linguistiche devono 
essere la copia una dell'altra č errato, puoi creare una copia anche 
gestendo il principio
Root
- Lingua
-- Content
- Lingua
-- Content
Cosa che invece non puoi fare se hai
Root
- Content
-- Lingua
-- Lingua
Dove il concetto di content č tranquillamente intercambiabili con funzione
Nel secondo caso hai il vincolo content - funzione che ti sei creato 
prima, senza poi andare a specificare il fatto che la struttura della 
directory specifica (che nel CMS puoi ad esempio fare con il mod 
rewrite) ti da un casino di vantaggio nel SEO
Prima di polemizzare o arrampicarti sui vetri come tuo solito ti prego 
di leggere attentamente la risposta, sulla materia sono relativamente 
ferrato e ti sarei grato se tu acconsentissi nel darmi ragione ;-)
Cla!
-- 
http://www.docebolms.org
 :: E-learning open source
Oggi, 6 luglio 2005, mi sento piů Europeo


Probabilmente mi sono espresso male, ma di certo hai frainteso, visto che 
stiamo dicendo la stessa cosa almeno in linea di principio.
Io evidenziavo che se hai un sito internet di un albergo la base deve essere 
comune e quello che cambia è il contenuto e lingua su cui poggia il 
contenuto.
Quindi se effettui una variazione sulla lingua italiana, necessariamente 
devi effettuare la stessa variazione nelle altre lingue. Il contenuto anche 
se tradotto in diverse lingue deve essere sempre lo stesso per ciascuna 
lingua.
Se invece parliamo di siti internet quali ad esempio quelli che trattano le 
news dove variano da paese a paese, la traduzione delle parti comuni avviene 
come nel caso precedente, ma il resto invece avviene a secondo delle 
specifiche news di quel dato paese etc etc. Un esempio è il portale di 
yahoo, che cambia anche forma (impostazione) a secondo la lingua e il paese 
scelto.


 devi effettuare la stessa variazione nelle altre lingue.
Bocciato
4--
Cla!
-- 
http://www.docebolms.org
 :: E-learning open source
Oggi, 6 luglio 2005, mi sento più Europeo


Non mi sembra che sia un giudizio abbastanza maturo, parti dal presupposto 
di avere ragione e stop :) senza tenere conto di quello che vuole il 
cliente.
Se un cliente vuole uno stesso sito tradotto in tre lingue significa che ha 
una base comune la grafica e ciò che cambia è la lingua del contenuto non il 
contenuto, dunque stessa grafica e stesso contenuto in lingua diversa.
In questo caso l'approccio del database che suggerivo è quello migliore, a 
meno che non dimostri non con i disegnini ma con i fatti che non lo è.


 contenuto, dunque stessa grafica e stesso contenuto in lingua diversa.
Palle palle palle palle e te lo dimostro in un esempio banale che si 
rifà al tuo. Come gestisci il sito di un hotel in 3 lingue che fa una 
promozione SOLO per gli utenti in lingua tedesca?
Con il tuo metodo "a specchio" non è possibile



Vedi che non hai compreso nulla di quello che ho scritto? mi quoto:
<quote>
questo approccio va bene se i contenuti sono indipendenti ovvero, se le
versioni dei testi nelle varie lingue sono svincolati fra loro; ad esempio
del portale yahoo, abbiamo la versione inglese, la versione spagnola etc etc
li non tutte le pagine sono uguali (vedi ad esempio la parte delle notizie).
In tutti gli altri casi č meglio avere una base comune statica e i contenuti
dinamici su di essa.
</quote>
dunque l'esempio che citi rientra nel secondo caso (quello che esemplificavo 
con yahoo) e non nel primo. Dove appunto si ipotizzava semplicemente una 
grafica comune, e un contenuto comune scritto in tre lingue diverse e nulla 
di pių.
Ora se vuoi far finta di non capire č un altro discorso.


 di più.
Il concetto, che ho già ribadito nei post precedenti è che un approccio 
ome il tuo non è metodologicamente corretto in quanto parte dal 
presupposto che tutto è immutabile se non il contenuto comunqe, cosa che 
non è mai, dunque è un metodo *sbagliato* e *da non usare* come continuo 
a ripetere



Quello è il tuo presupposto, e comunque stai generalizzando, in queste cose 
bisogna esaminare caso per caso, circostanza per circostanza e valutare in 
base a quanto chiede il cliente, non si scappa.


 Cooper.
No, perché il costo di realizzazione è identico in quanto si tratta di 
architettura del sistema non di scrivere codice più ma semplicemente di 
scrivere codice flessibile.
Comunque no problem, visto che passi la vita a polemizzare sul NG per 
qualsiasi cazzata ti lascio continuare il thread da solo



Ma guarda per me va bene nessun problema, però ti fo osservare che sei te a 
polemizzare, io infatti la questione l'avevo chiusa li alla prima risposta, 
te invece anzichè limitarti a dire la tua ti sei accanito anche su di me :)
Quindi non dire che polemizzo io :) sei te che te la cerchi.
Cooper.
ps: ognuno ha il suo punto di vista, è giusto che ciascuno rispetti il punto 
di vista dell'altro; io rispetto il tuo, te fai altrettanto con me, infondo 
non dobbiamo essere qui a litigare ma a confrontarci.


 ha scritto nel messaggio
news:mA%Ve.52308$O6.28...@news3.tin.it...

Ciao Gianni,
sembra anche a me un'ottima soluzione. Per essere precisi, credi che la
lingua si possa definiere con "it", "fr" e "en" (quindi /it/libri,
/en/books/, /fr/livres) oppure per esteso "italiano", "francese" e
"inglese"? :/
Max