Siti in multilingua con CMS, DB e CF

Oggi inizia il racconto di come affronto io la strutturazione di un sito multi-lingue con CMS e DB, da sempre uno dei crucci più rognosi per un webSomething. Ribadisco che è un mio modo di affrontare la problematica, non una regola da seguire. Si accettano critiche e consigli 🙂

 

Con l’esperienza ho approcciato questo tipo di filosofia a questo tipo di problema: una soluzione sicuramente elastica, che costi il meno possibile in termini di replicazione delle pagine, senza essere un bagno di sangue come sviluppo iniziale.

 

 

Strutturare il DB

Una delle cose IMHO che salva maggior tempo possibile nella strutturazione di un semplice DB per siti web è quella di mantenere il più possibile ordine, soprattutto rispetto delle regole (proprie) nella denominazione delle tabelle e delle colonne.

 

Per prima cosa analizzo il tipo di dato che devo rappresentare e analizzo quali sono i campi internazionali, cioè che sono uguali in qualsiasi lingua, e quali i campi sensibili alla lingua.

Esempio veloce: db prodotti.

 

Per ogni prodotto avremo: id_prodotto, nome, codice, descrizione, foto, attivo (per attivare o meno la visualizzazione del prodotto).

 

A questo punto divido i campi:

internazionali: id_prodotto, codice, foto

lingua: nome, descrizione, attivo

 

Nella strutturazione della tabella considero i vari campi in lingua, moltiplicandoli per ogni lingua; l’esempio è in 3 lingue (IT,FR,EN):

– id_prodotto (chiave)

– codice

– foto

– nome_IT

– nome_EN

– nome_FR

– descrizione_IT

– descrizione_EN

– descrizione_FR

– attivo_IT

– attivo_EN

– attivo_FR

 

A questo punto la tabella è apposto *.

 

 

Come creare la query

Strutturare la query sarà semplicissimo, ma soprattutto potremo inserire la query in pagine di qualsiasi lingua, magari importandola tramite un cfinclude, un cfc, un custom tag…

 

<cfquery name="qry_prodotto" datasource="#db#" cachedwithin="#cache_time#">
SELECT id_prodotto, nome_#client.lingua# as nome, descrizione_#client.lingua# as descrizione
FROM xxx_prodotti
WHERE attivo_#client.lingua# = 1
ORDER BY nome
</cfquery>

 

#db#: nome del database definito nell’application.cfm o in altro punto a vostro piacere

#cache_time#: tempo time span

#client.lingua#: variabile client all’interno della quale definiamo la lingua del cliente (IT,FR,EN,…), questo passaggio lo spiegherò meglio nel prossimo post.

 

 

Il CMS: come farlo

Qui non ci sono indicazioni particolari. L’unica cosa comoda da fare è utilizzare il CFLOOP nei campi input e nelle query di inserimento e registrazione, scorrendo la variabile APPLICATION.LINGUE.

 

APPLICATION.lingue è una variabile applicazione, rappresenta una lista, e sarà formata dalle lingue previste. Es.: "IT,FR,EN".

Per controlli futuri ho aggiunto anche APPLICATION.lingueTag: identica a quella sopra ma con underscore già previsto: "IT_,FR_,EN_".

 

Esempio:

<cfloop index="i" list="#application.lingue#">

Id_prodotto<br>
<input type="text" name="id_prodotto" value="#id_prodotto#" />
<br>
<fieldset>

<legend>Lingua: #i#</legend>
Nome <br>
<input type="text" name="nome_#i#" value="#nome#" /><br>
Descrizione<br>
<textarea name="descrizione_#i#">#descrizione#</textarea><br>

</fieldset>
<input type="submit" value="Invia…">

</cfloop>

 

La bellezza di questo formato è l’utilizzo di FieldSet che crea un bordo attorno al gruppo di input di una stessa lingua, e a Legend che assegna a questo spazio una etichetta. FieldSet e Legend sono modificabili tramite CSS.

 

 

Al prossimo post…

Vai al prossimo post per vedere come ottimizzare i template di Dreamweaver per più lingue e per fare il controllo della lingua prescelta con le variabili CLIENT di Coldfusion.

 

* Avevo provato anche a gestire i campi lingua generando una tabella esterna, collegata 1-N con questa tramite id_prodotto, la cui chiave era "id_prodotto,lingua". Però i costi di gestione in programmazione e delle query per la ricostruzione della riga completa mi hanno fatto prendere la strada descritta sopra.

Loading Facebook Comments ...

4 pensieri su “Siti in multilingua con CMS, DB e CF

  1. stefra

    beh… la soluzione funziona… ma se non sai a priori il numero e le lingue che il cliente vorrà gestire non puoi applicare questa soluzione… ti tocca a forza usare quella con tabelle di descrizione relazionate…

    Rispondi
  2. Merlinox

    Io sinceramente ho provato entrambe le soluzioni e continuo a preperire quella postata.
    Anche solo il tempo di creare le query per il CMS e le query di visualizzazione secondo me è talmente alto che conviente per ogni nuova lingua aggiungere le colonne al db.

    Magari mi sbaglio però.

    Rispondi
  3. angelo

    Per quanto ne so sembrerebbe che tradurre un cms di solito si utilizzano strade sempre lunghe e difficili e pesanti da supportare, ma tempo fa trovai un cms multilingua che veniva tradotto interamente da file di testo file.txt dove veniva inserita la traduzione multilingua dell’intero sito.

    Cosa ne pensate?
    Credete che potrebbe essere una valida idea?

    Rispondi
  4. Merlinox

    Ci sono due milioni di soluzioni per questo tipo di siti.
    E’ chiaro che se ti serve tanta elasticità e un controllo completo da parte dell’utente (admin) hai bisogno di piazzare tutto su db, o al massimo su degli xml.

    .net prevede delle particolari strutture XML apposite per quello, ma per prodotti di fascia alta il db è l’unica soluzione ottimale.

    Rispondi

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *