Invia le tue Newsletter con JNews!

sabato 27 settembre 2025

Siti multilingua in Wordpress

 Wordpress non gestisce nativamente la funzionalità multilingua ma è possibile realizzare il sito vs sito in più lingue utilizzando vari approcci differenti:

Approcci possibili

  1. Multisite (una installazione per lingua)
    Crei un network WordPress e un “sito” per ogni lingua (es. example.com/itexample.com/en).
    Pro: isolamento pulito dei contenuti, performance prevedibili, permessi separati, plugin/tema configurabili per lingua.
    Contro: manutenzione più articolata (backup, utenti, plugin), relazioni tra contenuti manuali se non supportate da plugin dedicati.

  2. Plugin multilingua su singolo sito
    Tutte le lingue convivono nella stessa installazione. Opzioni più diffuse:

    • Polylang: leggero, ottimo per blog/siti corporate; estensione a pagamento per WooCommerce.

    • WPML: completo, include traduzione stringhe, media, workflow; più “pesante”.

    • TranslatePress: traduzione visuale dal front-end, supporto MT (da rivedere/redigere).
      Pro: una sola installazione da gestire, linking tra traduzioni semplice.
      Contro: lock-in da plugin, possibili impatti su performance in siti molto grandi.

  3. Multisite + plugin di collegamento (es. MultilingualPress)
    Ibrido: benefici di Multisite con collegamento “nativo” tra versioni tradotte.
    Pro: scalabilità, nessun contenuto duplicato nel DB di un solo sito.
    Contro: costo/licenza, setup più tecnico.

  4. Headless/Jamstack
    WordPress solo come CMS; front-end (Next.js/Nuxt) gestisce i18n.
    Pro: massima libertà su UX/performance, routing i18n su misura.
    Contro: richiede team con competenze da sviluppo front-end moderno e DevOps.


Come scegliere (decision quick-guide)

  • Sito piccolo/medio senza e-commerce: Polylang o TranslatePress.

  • Sito complesso o con molto flusso redazionale: WPML (workflow, TM, stringhe).

  • Portale enterprise o network di brand/paesi: Multisite (con o senza MultilingualPress).

  • Team con skill React e focus performance/SEO avanzata: Headless.


Struttura URL e SEO internazionale

  • Struttura consigliata: sottocartelle per lingua (/it//en/, …). In alternativa sottodomini (it.example.com) o domini ccTLD. Mantieni una sola strategia ovunque.

  • hreflang: obbligatorio per evitare contenuti duplicati tra lingue e far capire a Google la variante corretta. I plugin citati lo gestiscono; verifica anche la versione “x-default”.

  • Sitemap per lingua: meglio separare ed elencarle in robots.txt.

  • Slug, title e meta tradotti: non lasciare slugs inglesi su pagine italiane e viceversa.

  • Redirect iniziale per lingua del browser: se lo usi, fallo solo alla prima visita, salva preferenza (cookie) e non indicizzare la pagina di redirect.

  • Contenuti davvero localizzati: evita traduzioni “letterali”; adatta esempi, misure, valute, date.


Note per WooCommerce

  • Lingua ≠ valuta: valuta, tasse e spedizioni possono variare per paese, non solo per lingua. Valuta e tasse vanno gestite con plugin specifici (multi-currency, geolocalizzazione).

  • Prodotti e attributi: traduci titoli, descrizioni, attributi e termini (paio/pack, taglie, materiali).

  • URL prodotto e categorie: traduci slug e ricontrolla i 301 se cambi struttura.

  • Email transazionali: predisponi template per lingua (ordine, spedizione, resi).

  • Ricerca e filtri: assicurati che l’indice (es. Elastic/Algolia) sia separato per lingua o includa il campo lingua nei documenti.


Workflow di traduzione

  • Glossario e guida di stile per coerenza terminologica.

  • Processo a step: bozza → traduzione → revisione → QA (link, moduli, formati numeri/date).

  • Stringhe di tema/plugin: usa .po/.mo (Loco Translate) o il modulo “String Translation” del tuo plugin i18n.

  • Media: valuta se duplicare o riutilizzare; in molti casi le stesse immagini bastano, ma cura i testi ALT per lingua.


Performance e caching

  • Cache per lingua: varia la cache per path (/it//en/) e per cookie se usi redirect alla prima visita.

  • CDN: regole di purge e invalidation consapevoli della lingua.

  • Ricorda il Vary: evita di variare su Accept-Language lato server quando non serve, per non esplodere la cache.


Checklist di avvio rapido

  1. Scegli struttura URL e plugin/architettura.

  2. Definisci lingue, glossario e stile.

  3. Imposta hreflang, sitemap per lingua e meta.

  4. Traduci menu, widget, footer, form, email.

  5. Traduci slugs e controlla i 301.

  6. Configura cache/CDN per lingua.

  7. QA completo (contenuti, moduli, pagamenti, ricerca).

  8. Monitora Search Console per ogni lingua/property.


Errori comuni da evitare

  • Mescolare sottocartelle e sottodomini senza motivo.

  • Lasciare meta/slug non tradotti.

  • Redirect forzato ad ogni visita (esperienza pessima + problemi di indicizzazione).

  • Non separare la cache per lingua.

  • Affidarsi solo alla MT senza revisione umana.


Se ti interessa, posso aggiungere una tabella comparativa rapida tra Polylang/WPML/TranslatePress/Multisite (pro, contro, costi tipici, compatibilità WooCommerce) o adattare l’articolo al tuo caso d’uso specifico.

domenica 26 ottobre 2014

Tradurre K2 con Joomfish!

Problemi di traduzione di K2 con Joomfish!

K2 è il mio CCK (Content Construction Kit) preferito per Joomla! e lo accompagna dalla versione 1.5, attualmente è in fase di sviluppo la release 3, scaricabile in Beta da questo link.

Joomfish è invece il compianto (ma non da tutti) componente per la gestione multilingua su Joomla! 1.5

Josetta e Falang sono delle ottime alternative su Joomla 2.5 e Joomla 3.x.x alla gestione multilingua core, anche se personalmente preferisco ridurre al minimo la quantità di estensioni installate, sia per una questione di performance ma anche, e soprattutto, per una questione di compatibilità fra esse.

Come tradurre K2 utilizzando Joomfish?

Se avete un vecchio sito in Joomla 1.5 e non temete di essere hackerati, potreste avere l'esigenza di tradurne i contenuti, in tal caso Joomfish farà al caso vostro.

Se però avete già installato K2 avrete dei problemi, perchè per funzionare correttamente occorre installare prima Joomfish, per saperne di più leggete questo post: http://www.joomfish.net/forum/viewtopic.php?f=21&t=5546



sabato 25 ottobre 2014

Manutenzione del db Joomla! dopo l'aggiornamento

Joomla! non funziona dopo l'upgrade dalla 3.x.x alla 3.3.x

Se effettuate l'aggiornamento di Joomla! manualmente semplicemente copiando i file del package di aggiornamento Joomla! vi incomincerà a segnalare degli errori nel backend relativi a tabelle mancanti.

Questo accade perchè mentre nella precedente versione 1.5 era sufficiente sovrascrivere i file, nelle nuove release di Joomla! vengono effettuati anche degli aggiornamenti allo schema del database.

Per questa ragione sono state inserite delle utility di manutenzione del db dalla versione 2.5

Per risolvere questi problemi quindi, andate nel backend su ESTENSIONI->Gestione Estensioni, poi selezionate Database, se vedrete una schermata relativa al DATABASE NON AGGIORNATO, premete il tasto Correggi e tutto sarà risolto.

Ecco le schermate:

Joomla 3.x.x


Joomla 2.5.x

Considerazioni

Se effettuate queste operazioni sopo aver aggiornato il db probabilmente avreste già un backup, altrimenti ricordatevi di farlo prima di premere il tasto CORREGGI, o potreste avere delle brutte sorprese!



sabato 6 settembre 2014

Cambiare la prima riga dell'e-mail dell'ordine di Virtuemart 2

Come cambiare il testo dell'e-mail dell'ordine di Virtuemart 2

Come visto in un precedente post è possibile modificare l'e-mail dell'ordine di Virtuemart utilizzando l'override dei file contenuti nella cartella html\com_virtuemart\invoice.

Se avete notato le e-mail che vengono inviate a cliente e venditore sono differenti, in effetti l'override è unico (orders), ma alcuni elementi sono inclusi in maniera differente a seconda del destinatario.

Cambiare l'e-mail del venditore

i file dell'e-mail dell'ordine del venditore sono i seguenti:
  • mail_html_vendor.php
  • mail_html_vendor_more.php

Modificare l'e-mail che viene inviata al cliente

Questi sono i file da modificare per cambiare l'e-mail che viene inviata al cliente sono i seguenti:
    • mail_html_shopper.php
    • mail_html_shopper_more.php


    Ovviamente per entrambi è possibile intervenire semplicemente sugli overrides:

    • COM_VIRTUEMART_MAIL_SHOPPER_CONTENT
    • COM_VIRTUEMART_MAIL_VENDOR_CONTENT


    venerdì 8 agosto 2014

    Tradurre i campi personalizzati (custom fields) di Virtuemart 2

    Per tradurre i campi personalizzati su Virtuemart 2 è sufficiente seguire la stessa logica di Joomla! integrato quindi per tradurre il valore di un campo personalizzato è sufficiente andare su ESTENSIONI->GESTIONE LINGUA, po OVERRIDE LINGUA e inserire il nome del valore da tradurre:


    Se però avete già inserito i valori dei campi personalizzati, non potrete tradurli con questo metodo.



    modificare il footer dell'e-mail dell'ordine in Virtuemart 2

    A volte può servire modificare il messaggio di conferma d'ordine di Virtuemart 2.

    Potrebbe capitare ad esempio di non avere Shop Name e Shop Company Name differenti.

    Se proviamo a lasciare vuoto uno dei due campi (o entrambi) apparirà il seguente errore)



    In questo caso possiamo effettuare un override del file

    com_virtuemart/invoice/mail_html_footer.php

    La riga interessata, se non sono state effettuate modifiche precedenti, è la 38:

    echo $this->vendor->vendor_name .'<br />'.$this->vendor->vendor_phone .' '.$this->vendor->vendor_store_name .'<br /> '.$this->vendor->vendor_store_desc.'<br />';

    Qui andremo ad inserire o togliere i valori che ci/non ci servono.

    giovedì 7 agosto 2014

    Disabilitare il Multivendor su Virtuemart 2 se è stato attivato per errore

    La funzione multivendor di Virtuemart 2 può essere attivata o disattivata in questo modo:


    mercoledì 6 agosto 2014

    Le impostazioni di Virtuemart vengono salvate nella tabella

    jos_virtuemart_configs

    Dentro il campo config.

    Qui vengono registrate le modifiche alla configurazione effettuate tramite il pannello di controllo di VM, viene inserito tutto in un'unica stringa in questo formato:
    offline_message=czo3MzoiT3VyIFNob3AgaXMgY3VycmVudGx5IGRvd24gZm9yIG1haW50ZW5hbmNlLiBQbGVhc2UgY2hlY2sgYmFjayBhZ2FpbiBzb29uLiI7|use_as_catalog=s:1:"0";|
    Il primo valore che troviamo è il seguente:

    shop_is_offline=s:1:"0";|

    è di tipo booleano, in questo caso indica che lo shop è off-line.

    Vediamo come si legge:

    shop_is_offline è il nome della variabile
    = assegna il valore
    s:1:"0" è il valore assegnato
    ;| separa i valori
    Per mettere off-line il sito basta cambiare il valore in questo modo:
    shop_is_offline=s:1:"1";|
    Il valore diventerà quindi TRUE;

    I valori riscritti di volta in volta al momento del salvataggio configurazione.

    Esistono delle impostazioni che non sono già presenti di deafult e vanno quindi aggiunti. Uno di questo è ad esempio: 

    |dblayoutstrict=s:1:"1";|

    Questa impostazione indica che le tabelle devono mantenere il layout originale impostato da VM al momento dell'installazione. In questo momento è su 1 (TRUE) quindi è attiva. Può essere utile cambiarlo nel caso non sia sufficiente lo spazio a disposizione per il campo della descrizione del prodotto che per default è di tipo VARCHAR.

    In tal caso è possibile cambiarlo in TEXT. Per farlo è sufficiente modificare questa impostazione su false:

    |dblayoutstrict=s:1:"0";|

    Al momento del salvataggio Virtuemart imposterà i campi product_desc e product_s_desc in formato TEXT.


    lunedì 4 agosto 2014

    cambiare l'oggetto dell'e-mail in Virtuemart 2

    L'oggetto delle e-mail può essere cambiato semplicemente effettuando i seguenti override di lingua:
    • COM_VIRTUEMART_MAIL_SUBJ_SHOPPER_C="[%3$s], Bestätigung Ihrer Bestellung bei %1$s"
    • COM_VIRTUEMART_MAIL_SUBJ_SHOPPER_P="[%3$s], Bestellung wird bearbeitet von %1$s"
    • COM_VIRTUEMART_MAIL_SUBJ_SHOPPER_R="[%3$s], Bestellung rückerstattet von %1$s"
    • COM_VIRTUEMART_MAIL_SUBJ_SHOPPER_S="[%3$s], Bestellung versendet von %1$s"
    • COM_VIRTUEMART_MAIL_SUBJ_SHOPPER_U="[%3$s], Bestellung bestätigt von %1$s"
    • COM_VIRTUEMART_MAIL_SUBJ_SHOPPER_X="[%3$s], Bestellung storniert von %1$s"
    • COM_VIRTUEMART_MAIL_SUBJ_VENDOR_C="[%3$s], Bestätigung der Bestellung von %1$s"
    • COM_VIRTUEMART_MAIL_SUBJ_VENDOR_P="[%3$s], Eingang einer Bestellung von %1$s"
    • COM_VIRTUEMART_MAIL_SUBJ_VENDOR_R="[%3$s], Zurückerstattete Bestellung für %1$s"
    • COM_VIRTUEMART_MAIL_SUBJ_VENDOR_S="[%3$s], Bestellung versendet für %1$s"
    • COM_VIRTUEMART_MAIL_SUBJ_VENDOR_U="[%3$s], Bestellung bestätigt von %1$s"
    • COM_VIRTUEMART_MAIL_SUBJ_VENDOR_X="[%3$s], Stornierte Bestellung für %1$s"

    sabato 2 agosto 2014

    Disabilitare il Multivendor Mode nel caso sia stato abilitato per errore

    Se per errore avete avete abilitato la funzione Multivendor potete disabilitarla così:


    martedì 17 aprile 2012

    Social networks, SEO e Joomla! Un approccio professionale.

    Joomla! come tutti i C.M.S. ha utili funzioni per ottimizzare la visibilità ed il SEO.Ultimamente sono proliferati moduli, plug-in e componenti free, open source e commerciali per integrare il sito web con i social network.L'abbondanza di soluzione tecniche non è però sempre abbinata alla strategia ed al metodo, in queste slides vengono presentati dei concetti pratici e di strategia di web marketing per approcciare correttamente il problema di utilizzare al meglio Social Media & SEO
    Guarda altre interessanti presentazioni sul canale Slideshare di Gruppo M.C. Ancona dal 1979 / Consulenti aziendali e Web agency

    mercoledì 4 aprile 2012

    Pronti per le nuove pagine Fan di Facebook? Segui i miei 6 consigli!

    Il 31 di Marzo Facebook ha cambiato definitivamente  il layout delle pagine FAN, segui i miei 6 consigli per non commettere errori da newbie!

    venerdì 14 gennaio 2011

    i templates in Joomla 1.6 differenze Joomla 1.5

    Joomla 1.6 arriva con 3 templates:
    • beez20 (alias Beez 2.0)
    • beez5
    • atomic (nel senso della essenzialità)

    #Differenze con i template di Joomla 1.5

    #1 Prima differenza : più sicuro

    Nel "vecchio" (troppo presto? guardate la disponibilità delle estensioni) Joomla 1.5 era sufficiente creare una cartella pippo all'interno della cartella templates inserire un file index.php e un templateDetails.xml che avesse il contenuto del tag <name> uguale alla cartella contenente per avere un nuovo template.

    Ora ciò non basta! Occorre effettuare un'installazione. Questo si traduce in una maggior sicurezza.

    Tuttavia sarà sufficente creare una sandbox in questo modo:
    • index.html (vuoto)
    • index.php (vuoto)
    • templateDetails.xml
    <?xml version="1.0" encoding="utf-8"?>
    <!DOCTYPE install PUBLIC "-//Joomla! 1.6//DTD template 1.0//EN" "http://www.joomla.org/xml/dtd/1.6/template-install.dtd">
    <extension
    version="1.6"
    type="template"
    client="site">
    <name>nuovo</name>
    <description></description>
    <files>
    <filename>index.php</filename>
    <filename>index.html</filename>
    <filename>templateDetails.xml</filename>
    </files>

    <positions>
    <position>unica posizione</position>
    </positions>

    <!-- For core templates, we also install/uninstall the language files in the core language folders.
    -->
    </extension>

    Tutto il resto è opzionale, potete anche aggiungerlo dopo l'installazione così farete prima a creare la sandbox del template.

    Come fare per sapere quali sono tutti i tags supportati? Di solito si legge la DTD, quella specificata nel file XML: http://www.joomla.org/xml/dtd/1.6/template-install.dtd
    bene, ad oggi 14/01/2011 questo link non funziona..

    #2 Seconda differenza : il manifest file XML è più leggibile

    Il manifest file supporta nuovi tag, ad esempio <folder>, dove vanno specificate le cartelle contenute nella cartella principale. Inoltre i file vanno specificati nel tag <file> senza il percorso della cartella in cui sono contenuti, quanti errori avete fatto nella creazione del manifest file da blocco note ;-)

    venerdì 7 gennaio 2011

    costo a ore di un programmatore Joomla!

    Qual'è il costo orario di un programmatore Joomla? Lo stesso di un altro programmatore.

    E' però importante valutare le skills, le referenze.
    Hai realizzato il tuo progetto web o sito internet in Joomla? Vuoi aggiornare il sito con delle nuove funzionalità e non riesci a trovare i moduli e i componenti Joomla! che soddisfino le tue esigenze?

    Per rendere il tuo sito web più professionale e coerente con il tuo progetto web devi chiedere una consulenza ad un programmatore Joomla! esperto che conosca le logiche del web 2.0 e abbia esperienza in sviluppo C.M.S. Open Source.

    Dieci anni fa la presenza in Internet rappresentava un vantaggio competitivo, un modo per differenziarli. Oggi siamo tutti on-line e rendere il proprio sito web più professionale è determinante.

    Il supporto di un programmatore php esperto può non essere sufficente, infatti sono necessarie delle competenze specifiche.

    La realizzazione di un sito web richiede l'utilizzo di diverse tecnologie:

    • MySql
    • Ajax
    • CSS, per l'impaginazione
    • HTML, XHTML o HTML5, per la definizione della struttura
    • una grafica accessibile e semplice
    Affidati ad un esperto!

    Costo orario

    Il costo orario può variare da 25 a 70 euro l'ora a seconda del livello di esperienza necessario tenendo presente che trattandosi di una prestazione professionale il costo può essere soggettivo

    mercoledì 5 gennaio 2011

    programmare su JOOMLA o WORDPRESS il vostro sito?

    Riporto di seguito la traduzione di questo articolo. I motivi che hanno motivato la scelta di questo articolo in particolare saranno descritti nel mio blog personale in un futuro articolo.

    Cofronto dei C.M.S. Joomla! e Wordpress


    "Quando cercate di creare un sito web, proverete probabilmente alcuni dei sistemi di gestione dei contenuti chiamati comunemente C.M.S.
    Due dei più popolari tra di essi sono Wordpress e Joomla!
    In questo articolo proverò a spiegare alcuni dei maggiori vantaggi e svantaggi di entrambi i sistemi.

    WORDPRESS

    Vorrei iniziare con Wordpress, che è uno dei più semplici sistemi disponibili oggi su Internet. Nonostante molte persone pensano che Wordpress possa essere utilizzato solo per la costruzione di blog, è possibile configurarlo per funzionare in molti altri modi.
    Inoltre installare questo CMS su di un server è davvero semplice. In questo modo è possibile permettere a persone senza alcuna esperienza di creare il proprio sito web in un paio di ore.
    Inoltre più per esempio non è necessario sviluppare script addizionali per ottenere i commenti dei visitatori perchè sono già parte integrante del sistema.
    D'altro canto, Wordpress non fornisce un'interfacciai adeguata per gli sviluppatori, perchè se si cerca di modificarlo, per esempio creando un carrello elettronico, l'intero sistema rischia di andare in crash.
    Se cercate di sviluppare in Wordpress, non troverete un adeguato supporto da parte della community di Wordpress, perchè si lamentano principalmente delle caratteristiche del sistema.
    Infine, quando cercate di effettuare un upgrade del sistema, vi arrenderete trovando molti più bug di quelli cui siete abituati.

    JOOMLA

    Joomla!, al contrario, è un dei migliori CMS per i designers, gli sviluppatori e gli amministratori. Questo sistema permette a tutti i suoi utenti di creare siti web di alto impatto visivo ed è molto semplice da utilizzare per i principianti.
    Inoltre ci sono molti sviluppatori (come me, ndr), che creano tools, che estendono rapidamente la performance di Joomla!
    Se siete degli sviluppatori, vi consiglio di utilizzare questo sistema, perchè offre enormi potenzialità in fatto di personalizzazione e sviluppo.
    Le caratteristiche di joomla sono state costantemente aggiornate da 3 anni a questa parte e quindi troverete sempre nuove funzionalità.
    Tuttavia se date un'occhiata al sistema, troverete che non è così semplice da utilizzare per coloro che non hanno esperienza di sviluppo ed è ancora abbastanza lontano dall'essere user-friendly. Tuttavia dopo il recente rilascio della versione 1.5.x che continuano ad utilizzare la vecchia.

    CONCLUSIONI

    In conclusione, vorrei dire che la scelta tra i due sistemi dipende dal proposito del sito web ed anche dalla tua conoscenza dello sviluppo e del web design.
    In più, quando comparerete la semplicità di entrambi i sistemi, troverete che lavorare con Wordpress è molto più semplice, quindi ci sono molti principianti che lo scelgono al posto di Joomla!
    Quando iniziate un progetto, dovete controllare esattamente quali sono i requisiti del vostro cliente, prima di scegliere uno dei due C.M.S."

    tradotto da http://www.wordpressvsjoomla.com/

    prestiamoci - il tuo investimento consapevole

    Prestiamoci - Il tuo investimento consapevole