Ciao a tutti,
affrontando per la prima volta un sito con 3 lingue diverse ho notato lo strano comportamento del blocco "Lingue" del modulo "Locale" (per interderci quello che mostra i link per fare lo switch della pagina tra le differenti traduzioni).
Il problema è già conosciuto e documentato... volevo chiedere se qualcuno ha trovato delle soluzioni pulite a questo:
quando un contenuto è stato inserito MA NON tradutto, il modulo mostra (stranamente) i link a tutte le lingue disponibili sul sito (in questo caso 3). Non appena si aggiunge una traduzione qualsiasi il suo comportamento cambia e mostra solo i link ad eventuali contenuti tradotti.
Es. sito in ITA, ENG, ESP
Creo pagina in ITA: vedo anche i link alle lingue ENG ed ESP che però mi ripropongono il medesimo contentuto in ITA con la sola interfaccia tradotta.
Se aggiungo la traduzione ENG: vedo solo i link a ITA ed ENG (il link ad ESP, prima presente anche se non tradotto, ora sparisce!)
La motivazione è spiegata tecnimente (qui se volete!) dal fatto che Drupal alla creazione di un contenuto, pur scegliendo una lingua di appartenenza, non lo identifica come "gruppo di traduzione". Lo farà solo quando verrà aggiunta almeno una traduzione.
Si può forzare questo comportamento ma si deve eseguire a mano un "Update Translation"; che inserisce il nodo in un gruppo di traduzione anche in presenza di un contenuto non tradotto (e a quel punto viene mostrata un solo link sul blocco in questione: quello dell'unica lingua presente).
L'articolo citato prima propone l'utilizzo di translation 404 come modulo "toppa": lo scopo è di evitare che il sito riproponga all'utente che sta cambiano lingua il medesimo contenuto non tradotto ma in sostituzione fornire una pagina "Not found", creata dal modulo, per intercettare questo tipo di situazione.
Di contro c'è anche chi preferisce il comportamento da me definito "anomalo" e anzi sceglie di usare moduli come Active Translation per estenderlo in ogni situazione .
Io invece sono curioso di sapere se qualcuno ha testato un modo semplice, senza hack sul core per fare in modo che sul blocco lingue siano riportati i link ai soli contenuti presenti in una lingua:
Quindi se esiste solo ITA mostra solo il link ad ITA (o magari non mostra nulla!) se esiste in ITA + ENG mostra i link a questi ecc.ec..
Insomma un modo di estendere in automatico lo stato di "gruppo di traduzione" anche ai nodi inseriti senza una traduzione, evitanto di dover fare l'update a mano (che nel caso di contenuti aperti agli utenti non è davvero carino!).
Ciao e Grazie!
Mah... io ho sempre lavorato con i18n senza moduli "toppa" (o simili...) e il consiglio che mi sento di dare (sempre secondo il mio modesto parere...) è tradurre, tradurre e tradurre... questo secondo me è il segreto...
Nonappena crei un nodo traducilo subito in tutte le lingue (Traduci/Translate) in modo da "confezionarlo/chiuderlo" subito e basta!
i18n sembra "desideri" questo (chiudere subito il nodo... appunto...) - se poi a questo nodo è associata una voce di Menu c'è una ragione in più per farlo... infatti, a volte dopo la traduzione, i menu non si vedono subito - devi cliccare sulle varie "bandierine" come per fargli fare una sorta di rodaggio/sblocco... dopo appare tutto ok!
Se crei un nodo es. ITA, traducilo es. in ENG inserendo una cosa tipo: Under Construction - ma traduci sempre il nodo in tutte le lingue!
Sempre secondo me è meglio vedere un "Under Construction" (e gli equivalenti nelle altre lingue...) piuttosto che delle Page not Found o soluzioni alternative che lasciano "aperti" i nodi ed esposti a potenziali malfunzionamenti...
Ciao
Kipper
Ah si sono completamente d'accordo con KIPPER
il modulo i18n è proprio costruito secondo questi krismi e questi sono i migliori sistemi per usarlo al meglio delle sue caratteristiche peculiari.
Approposito sig. Kipper ... ma NESPOLI è tuo zio vero ?
(quello che và nello spazio per ben 6 mesi ... checivai anche tu ? )
L' utilizzo dell' i18n è destinato, a mio modesto parere, prima di tutto a chi padroneggia una seconda o terza lingua e non si accontenta delle più o meno pseudo traduzioni di Google Translate o prodotti simili. Se ci vanno bene le traduzioni di Google, abbiamo il modulo ad hoc GTranslate ottimo per funzionalità, ma che produce l' errore "Javascript jump menu may be present" secondo lo standard WCAG; in pratica non è previsto un accesso alternativo al mouse, ma che, appena riesco, voglio vedere meglio, perchè io mi accontento anche della traduzione di Google.
Per tornare ad i18n, oltre a padroneggiare le lingue, secondo me è necessario anche padroneggiare Drupal e PHP, perchè, per avere un risultato professionale, oltre a tradurre i vari contenuti, è necessario importare anche le traduzioni di Drupal per i vari linguaggi (questo è il minimo) e probabilmente anche per i moduli.
La cosa più importante che sarebbe alquanto fastidiosa da risolvere, sarebbe, sempre secondo il mio modesto parere, quella di non fornire più un singolo RSS, ma un RSS diverso per ogni lingua; un singolo RSS produrrebbe più link ad ogni singolo articolo, uno per ogni lingua tradotta.
Scusate se non ho dato la soluzione al quesito proposto, ho voluto dare solo un mio parere.
...ehm... veramente qui il problema è di natura funzionale!
Capisco le posizioni "filosofiche" espresse ma in taluni casi rischiano di essere lontane dai problemi di tipo pratico; spiego:
Immaginiamo un sito aziendale composto da pagine statiche (tutte multilingua e gestite da un admin) e da contenuti dinamici (delle news per esempio) gestite direttamente dal "committente".
In questo caso non si può applicare l'invito a "tradurre sempre e comunque" perchè non sarà l'admin a decidere ma il committente stesso! ;)
E non mi sento di dare torno se lo stesso committente mi fa notare che le news non vanno tradotte "a prescindere" ma solo a seconda del loro contenuto... es:
il lancio di un nuovo prodotto su scala internazionale avrà sicuramente necessità di essere proposto in tutte le lingue.
Ma un avviso di carattere locale, del tipo "Domani parcheggio interno chiuso per lavori", magari non merita di essere esposto a mezzo mondo!
Quindi condivido la filosofia che se scegli un sito multilingua devi tradurlo... ma non ci sono solo i Blog! ;)
Pienamente d'accordo con te...
Insomma, questo i18n non è così semplice da gestire, io ho spiegato solamente il modo migliore per farlo funzionare (sulla base della mia esperienza......) ma ci sono evidentemente molte sfaccettature/esigenze oltre a quella che hai giustamente citato...
Premettendo che non lavoro sui Blog, sicuramente NON tradurre i nodi ancora da definire è la strada/logica migliore, il modulo Translation Overview >>> http://drupal.org/project/translation_overview da la possibilità di avere tutto sotto controllo... boh... che dire?
...metti una bella "Page not Found" se non vuoi mettere "Domani parcheggio interno chiuso per lavori" ...magari gli utenti/visitatori saranno più felici...
Avendo sempre lavorato nel modo che ho già citato e, non avendo mai usato moduli "toppa" (o simili...) non mi viene in mente altro...
Attendiamo esperti con vedute più ampie per allargare la discussione ;-)
quando fai una pagina fai subito le corrispettive pagine di traduzione : e fine !
I flag (il modulino con le bandiere x i18) mi sembra che appaiono solo se hai tradotto quella pagina.
Non vedo problemi se non quelli di "riempir pagine di contenuti e traduzioni corrispettive".
Ho perso un po ' il filo iniziale della discussione, ma non riesco a capire perché ci dovrebbero essere o dei segnaposto vuoti o dei 404 in caso di nodi che non vengono tradotti: se si tratta di voci linkate da un menu, si imposta la lingua di tali voci e si mostrano solo le voci effettivamente collegate; se si tratta di elementi "dinamici" tipo le news, si usa il filtro per la lingua per mostrare a chi sta vedendo la vista delle news in inglese solo quelle presenti. Per quanto riguarda i nodi, quelli che hanno la traduzione, presenteranno il link alle lingue diverse da quella visualizzata.
per Pinolo:
il problema non solo le viste, i menù, i contenuti o altro: il sito è perfetto da questo punto di vista! L'unico inconveninte sono state le label delle views; risolto grazie a Kipper che mi ha suggerito String Override.
Il problema che sollevavo è invece il blocco con lo swith tra le varie lingue: mostra sempre e comunque i link a tutte le lingue del sito anche quando un nodo non ha alcuna traduzione; salvo poi cambiare comportamento e mostrare solo quelle disponibili appena si aggiunge almeno una traduzione.
Il problema è tecnico, legato a come Drupal considera i gruppi di traduzione: un nodo non tradotto è trattato diversamente da uno con almeno una traduzione. Cercavo un workaround a questa situazione! Vorrei trovare un modo per cui qualunque nodo (con traduzione o meno) sia considerato in automatico "gruppo di traduzione" alla sua creazione.
;)
Quindi l' unico problema sarebbe quello di far eseguire automaticamente un "Update Translation" ogni volta che si inserisce un nuovo nodo.
Ma l' amministratore non dovrebbe indicare, ogni volta che si inserisce un nuovo nodo, quali sono i nodi da non visualizzare ?(se vengono prodotti automaticamente anche i nodi non tradotti).
Presumo inoltre che anche l' RSS dovrebbe passare per una view.
Il committente sarebbe quindi soddisfatto, ma con enorme sforzo da parte dell' amministratore.
Ma dal lato SEO, siamo sicuri che Google scansionerebbe solo le pagine visibili ?
Dret, adesso ho capito meglio. Leggi qua: http://drupal.org/node/518364
A questo commento c'è un passaggio importante: http://drupal.org/node/518364#comment-2870818
Può darsi che nel lunghissimo thread tu riesca anche a trovare qualche soluzione; facci sapere!
Grazie Pinolo... tra i 10000 post a riguardo... questo me l'ero perso!
La soluzione però la trovate qui (è citata in uno di quei post): http://drupal.org/node/995500#comment-3829750
E' un modulo realizzato l'11 Dicembre (3 giorni fa!) e non inserito (peccato) nella sezione dedicata!
Niente hack o patch del core il codice ha pochissime righe, con molti commenti utili (sembra molto pulito)!
Crea semplicemente un nuovo blocco Seleziona lingue!
Produce i seguenti effetti:
- Nasconde i link alle lingue se non esistono traduzioni per esse
- Nasconde il link alla lingua corrente (mi pare ottimo!)
Compatibilità:
- sembra integrarsi alla grande con tContact e con Pathauto (almeno per il momento!)
(sarebbe da testare con le tassonomie ma su questo sito ne farò un uso "anomalo" e quindi non sarà utile!)
Piccola notazione:
- Una vota installato funzionerà su tutti i nuovi nodi creati MA per quelli già esistenti dovrete "runnare" a manina "Update Translation" dall'interfaccia di traduzione!
O magari una query specifica... che lascio a quelli più bravi!
Grazie a tutti!
Ciao!
Brutto regalo di natale!
(Auguri a tutti intanto!)
Sotto l'albero ho trovato la brutta sorpresa: poche ore dopo aver postato la soluzione al problema, è stato rilasciato D 6.20.
Tra i tanti fix introdotti anche quello per un bug sul modulo traduzione quando interagiva con Rules ed altri componenti aggiuntivi (vedi qua: http://drupal.org/node/357785).
Sfortunatamente, agendo sul 'tnid', rende il modulo, citato precedentemente, inuitile e dannoso, perchè va a rompere l'associazione tra nodo e relative traduzioni (che vengono viste come elementi "stand alone' e non parte di un gruppo di traduzione).
Ho segnalato il problema...
Maledetto Babbo Natale!
Buone notizie:
Il Language switcher block fix è stato aggiornato ed ora funziona nuovamente.
Il link per scaricarlo è quello vecchio (è stato aggiornato l'allegato):
Io intanto avevo optato per una funzione lato theming!
Ciao!