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/it, example.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.

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

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!

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

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.

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: