Wikipedia:Bar/Discussioni/Errori di parsing con grassetto e corsivo

Salve, so che si tratta di un argomento barboso, ma sopportatemi ugualmente. :) Da tempo immemore esistono situazioni sfortunate in cui il parser che si occupa di interpretare il grassetto e il corsivo va in pappa. In particolare quando davanti all'inizio di grassetti o corsivi vengono messi degli apici con funzione di apostrofo.

Esempio1: '''Virgilio''', noto poeta romano, ha scritto un'''opera'' =====> Virgilio, noto poeta romano, ha scritto un'opera

Esempio2: l'''Iliade'' che l'''Odissea'' sono poemi epici =====> sia l'Iliade che l'Odissea sono poemi epici

In compenso ci sono casi anche molto molto simili dove non si presentano problemi.

Esempio3: '''Virgilio''', noto poeta romano, ha scritto l'''Eneide'' =====> Virgilio, noto poeta romano, ha scritto l'Eneide.

Per aggirare il problema ci sono diverse strade.

1. Lasciare uno spazio tra l'apice usato come apostrofo e gli apici di formattazione.
   Esempio: '''Virgilio''' ha scritto un' ''opera'' =====> Virgilio ha scritto un' opera.
   Funziona, ma lascia purtroppo uno spazio visibile tra l'apcie usato da apostrofo e la parola che lo segue. Era una delle soluzioni più utilizzate fino a quando con il mio bot non ne ho eliminati migliaia. La maggior parte erano inutili, ma mi sono accorto troppo tardi che alcuni in effetti servivano. Ehm... :) ed è questo il motivo principale per il quale sto cercando la migliore soluzione generale al problema.
2. Mettere l'apice incriminato dentro un tag nowiki.
   Esempio: '''Virgilio''' ha scritto un<nowiki>'</nowiki>''opera'' =====> Virgilio ha scritto un'opera.
   Si tratta in teoria della soluzione migliore, ma mettere un sacco di tag <nowiki>'</nowiki> in giro per l'enciclopedia non solo appesantisce la lettura del sorgente, ma aumenta significativamente il rischio di trovarsi dei pastrocchi creati dal visual editor o da utenti inesperti.
3. Convertire l'apice usato come apostrofo in un carattere apostrofo.
   Esempio: '''Virgilio''' ha scritto un’''opera'' =====> Virgilio ha scritto un’opera.
   A livello grafico la differenza con l'apice è quasi impercettibile e in teoria sarebbe il carattere giusto per l'apostrofo. Inoltre già adesso questo carattere è comunque molto diffuso (almeno una pagina su 11 nel ns0 utilizza il carattere di apostrofo). È chiaro che in linea di principio non è bello avere voci con un po' di apostrofi scritti con l'apice e un po' di apostrofi scritti con l'apostrofo e in caso di riutilizzo del testo con un altro font la differenza grafica potrebbe diventare più evidente.
4. Come sopra, ma convertire l'apice nel codice &#39; in modo che non venga interpretato come codice wiki.
5. Usare il template {{'}}.
   Esempio: '''Virgilio''' ha scritto un{{'}}''opera'' =====> Virgilio ha scritto un'opera.
   Contiene in pratica il codice &#39;. Di tutte mi sembra la soluzione di gran lunga migliore.
6. Nei casi in cui c'è un wikilink si possono mettere gli apici dentro il piping
   Esempio: '''Virgilio''' ha scritto un'[[opera|''opera'']] =====> Virgilio ha scritto un'opera.
   Funziona bene, ma solo dove ci sono dei wikilink.
7. Chiedere agli sviluppatori di modificare il parser Mediawiki perché riconosca i casi classici di accenti italiani e li gestisca correttamente. Non credo che ci siano molte speranze.
8. Eliminare tutti i corsivi e i grassetti che non rispettano il manuale di stile ridurrebbe enormemente il numero di casi da gestire. Andrebbe fatto in ogni caso.

Morale: intuitivamente non è facile capire quando si presenterà il problema e alla fine molti contributori applicano sistematicamente i metodi 1 o 2 ogni volta che c'è un apostrofo vicino a degli apici di formattazione del testo. Al momento sto cercando di scrivere uno script in grado di riconoscere il maggior numero di casi in cui si presenterà il problema. In questo modo si potrebbe applicare una delle soluzioni proposte solo dove necessario.

La domanda a questo punto è: vi ispira utilizzare la soluzione 5 ovunque risulti necessario? Domanda2: siete d'accordo nel togliere eventuali stratagemmi di questo tipo dove al momento non risultano necessari? -- Basilicofresco (msg) 17:15, 30 ago 2014 (CEST)

L'ordine di cose da fare IMHO è:

1. Togliere tutti i corsivi e i grassetti dove non necessario (in particolare questi ultimi non andrebbero proprio messi fuori dall'incipit)
2. Usare nelle situazioni rimaste la soluzione 5, tranne dove si può usare la 6 (ma senza approfittarne, ovvero niente overlinking)

Sul punto 7 si può sempre provare, magari nel 2036 ci accontentano. :)--151.67.198.188 (msg) 18:04, 30 ago 2014 (CEST)

io ho sempre usato, nei pochi casi in cui sono stato costretto (nel senso che era obbligatorio usare grassetto e corsivo e non si poteva optare per una parola senza apostrofo) per il nowiki, che in effetti ora con l'introduzione del VisualEditor inizia a diventare problematico.

il ’ personalmente lo visualizzo in maniera differente da ', anche se nell'editor sembrano molto simili. nel caso si decida di passare ad un carattere che non è presente nella tastiera italiana, bisogna assolutamente agevolarne l'inserimento nella casella di modifica.

il template potrebbe essere una soluzione agevole nel caso uno scriva {{'}} e riesce ad ottenere (substato) il ’. purtroppo non mi sembra esista al momento un modo per forzare la sostituzione del template con il codice dello stesso. al limite si può suggerire l'uso e poi ci pensa il bot ad effettuare le modifiche... --valepert 19:26, 30 ago 2014 (CEST)

Intervengo su richiesta di Basilicofresco dato che la soluzione 6 è saltata fuori da una correzione che ho fatto. Se si tiene conto del fatto che il carattere apostrofo non è sulle normali tastiere, quindi non ci si può aspettare che l'utente ignaro dei problemi di parsing sappia di doverlo usare; il template è comodo, ma come sopra bisogna sapere di doverlo usare, comunque è abbastanza veloce sia usando wikicodice sia usando visualeditor (che dalle mie prove applica da solo la soluzione 6, tagliando la testa al toro), il nowiki ha il medesimo problema di "saperlo", con in più i problemi di compatibilità con visualeditor; allora mi viene dadire che le soluzioni 3, 5 e 6 vanno bene a patto di chiarirle nel manuale base sulla formattazione (e ovunque si parli di corsivi ecc) con wikicodice, mentre la 5 e la 6 vanno bene anche con visualeditor (la 6 più immediata). --Giuseppe (msg a baruneju) 19:43, 30 ago 2014 (CEST)

a me il grassetto/corsivo dentro il wikilink non piace perché rende complesso effettuare alcuni tipi di collegamento (esempio banale: ''[[italia]]na'' <-> [[Italia|''italiana'']]). --valepert 20:32, 30 ago 2014 (CEST)

Dato che il parser è quello che è, a qualcosa bisogna rinunciare. Bisogna solo decidere a cosa. A me, al contrario, quel tipo di link che segnali piace poco, perché si ha una resa ("italiana" come link corsivo) che non corrisponde al wikicodice ("italia" come link e tutto quanto come corsivo). Molto dipendente dal separatore utilizzato per decidere dove finisce il link, mentre con l'annidamento ''[[]]'' o [[|'''']]. Comunque, che si preferisca una o l'altra, resta il problema per i brani in cui non c'è wikilink, per cui probabilmente la soluzione 5 è più generale. --Giuseppe (msg a baruneju) 21:14, 30 ago 2014 (CEST)

a me questi "pasticci" non accadono mai, c'è un motivo particolare? dipende dal monobook o altre diavolerie del genere? --ROSA NERO 21:23, 30 ago 2014 (CEST)

Io in tanti anni e migliaia di modifiche non avevo mai rilevato questo problema, semmai mi è capitato di vedere l'apice tra tag nowiki (non ne avevo mai capito il motivo fino ad ora). Probabilmente quei tag erano messi a sproposito, perché quando li rimuovevo nulla cambiava. IMO togliere questi "stratagemmi" se non sono necessari è cosa buona, usare l'opzione 5 no, visto che si introdurrebbe un richiamo ad un template per generare un banale &#39;. Sarebbe come usare un template al posto di &nbsp per la spaziatura che vieta il rimando a capo. È vero che come codice può sembrare criptico per un niubbo, ma non credo che sarebbe diverso per {{'}}. In sintesi: userei la 4° strada e segnalerei comunque il problema agli sviluppatori. --Umberto NURS (msg) 23:23, 30 ago 2014 (CEST)

mi dispiace contraddirti, ma probabilmente NON erano messi a sproposito quando è stata fatta la modifica ma cambiamenti successivi sia della voce che del software (ricordo che i primi tempi l'anteprima dei popup era al 90% con i grassetti e i corsivi sbagliati, adesso la qualità è nettamente superiore) hanno reso meno evidente il problema, che esiste ancora e il VisualEditor ha riportato alla luce (complice anche un giro recente di modifiche da parte del bot di Basilicofresco, mi pare di aver capito).

personalmente non sono un fan dell'entità HTML (mi pare che gli sviluppatori stiano facendo negli anni modifiche per rendere sempre meno funzionale tale markup all'interno del wikitesto), l'opzione più logica forse sarebbe introduzione del vero apostrofo (invece dell'apice) e utilizzo del template apice per inserire quest'ultimo nelle voci, dato che già alcune pagine lo utilizzano (e spesso passando sulla voce si tende a sostituirli con gli apici). --valepert 23:53, 30 ago 2014 (CEST)

La quinta mi sembra l'unica opzione convincente. Diciamo che inserire un apostrofo in un template è molto più intuitivo di doversi ricordare una entity HTML.

[@ Umberto NURS] Il template che genera &nbsp; si chiama {{sp}}. --Horcrux_九十二 02:06, 31 ago 2014 (CEST)

Su una delle ultime questioni, tag nowiki (ma stesso discorso immagino si possa fare per gli altri metodi / trucchi) ritenuti messi a sproposito, perché una volta levati non è cambiato nulla: un conto se messi in un punto dove c'era il rischio del problema (es. apostrofo seguito immediatamente dall'inizio di un corsivo) non sarebbero così a sproposito, l'utente si è accorto del rischio e si è assicurato che non avvenga il problema. Già non è così banale ricordarsi di usare questi stratagemmi, sarebbe ancor più complicato doversi ricordare di scrivere normalmente e salvare o fare anteprima, controllare e solo in caso di effettivo bisogno usare lo stratagemma; senza contare che successive modifiche potrebbero cambiare la situazione e farlo diventare necessario.

Io ho quasi sempre visto usato il metodo 2 (tag nowiki), e di conseguenza ho imparato anche io ad usare quello. (E mi sembra anche il più intuitivo da capire se si guarda il codice e si approfondisce almeno un pochino: in fin dei conti è proprio quella la funzione del tag nowiki, impedire l'interpretazione di una sequenza di caratteri come codice). Ora c'è il problema del VisualEditor, ma non ho ben capito che problema sia e quando avvenga.

Per il metodo 6, mi pare di aver letto in qualche linea guida (o mi ricordo male? o me lo sono sognato?) di non utilizzare il piped wikilink quando non necessario. (Mentre non ho mai capito se scritture come [[italia]]no siano da preferirsi a [[Italia|italiano]] e in tal caso perché. A me sembra di più difficile lettura e comprensione). --109.53.213.178 (msg) 02:42, 31 ago 2014 (CEST)

la pagina di Aiuto suggerisce (sicuramente almeno dal 2009) di usare nowiki per l'apostrofo (anche se parla di "apostrofo vero e proprio" per riferirsi in realtà ad un apice...).

per quanto riguarda i suffissi, saranno gli anni di wikitesto, personalmente mi viene più facile "decomprimere" mentalmente ciò che viene linkato segnando un prefisso rispetto all'intera parola (funziona in realtà in maniera più complessa, però lo scopo è chiaramente evitare di riscrivere parte del link dopo il pipe). --valepert 03:22, 31 ago 2014 (CEST)

[@ Horcrux92] Conosco bene quel template, ma so anche che spesso non viene usato (sia nelle voci, sia nei wikicodici dei template). Quindi ritengo opportuno usare una linea omogenea, altrimenti sarei il primo a supportare l'uso del {{'}}.

@109.53.213.178: io non ho ritenuto che i tag fossero messi a sproposito, ho solo supposto, infatti ho scritto probabilmente; evidentemente erano stati messi quando, come dice Valepert, il software non era così affidabile e avevano un senso. --Umberto NURS (msg) 10:51, 31 ago 2014 (CEST)

ma quindi adesso il software è affidabile da questo pdv? è dunque necessario escogitare queste scappatoie? --ROSA NERO 14:49, 31 ago 2014 (CEST)

sicuramente la qualità del parser è migliorata (i grassetti e i corsivi aperti e non chiusi tra una sezione e l'altra vengono interrotti) ma rimane uno strumento ancora poco affidabile (per esempio non ho capito ancora perché questa revisione si veda bene nonostante la sequenza di apici 3, 2, 2, ..., 2). --valepert 15:42, 31 ago 2014 (CEST)

Si potrebbe substare il nowiki? R5b (msg) 14:52, 1 set 2014 (CEST)

Fra tutte le soluzioni non ho visto l'unica "ben conformata" (ma per motivi non comprensibili molto scoraggiata): l'uso di banalissimi tag html <b> ... </b>, <i> ... </i>. Mi sono sempre domandato perchè gli utenti dei forum sono considerati tanto abili da usarli regolarmente (nella variante bbCode) mentre gli utenti wikipedia non sono considerati abbastanza abili. ;-)

In wikisource abbiamo uno script che converte gli apostrofi dattilografici ' in apostrofi tipografici ’, ma è parecchio complesso, perchè deve evitare la conversione non solo nel markup dei grassetti-corsivi, ma anche gli apostrofi dentro i link, dentro il math, dentro i template.... e comunque sarebbe inutilizzabile sotto Visual Editor (che per wikisource non è stato ancora attivato). --Alex_brollo Talk|Contrib 22:47, 1 set 2014 (CEST)

Io problemi del genere ne vedevo spesso un po' di anni fa, ma poi ho notato che via via son passati dei bot a correggere le scappatoie artigianali, e pensavo che il problema fosse stato risolto. Se così non è non so quale soluzione possiamo escogitare, ma sicuramente non quella di inserire una spaziatura errata o il "vero" carattere dell'apostrofo, creando disomogeneità. Ricordiamoci che i nostri testi hanno la caratteristica fondamentale di poter essere riutilizzati, e pertanto dovrebbero evitare di contenere errori tipografici. --Phyrexian ɸ 00:49, 2 set 2014 (CEST)

Quoto Phyrexian. Tanto più che, se si decidesse di adottare l'espediente di mettere l'apostrofo vero, bisognerebbe cambiare tutti gli apostrofi di Wiki per omogeneità. Credo che la cosa diventerebbe antipatica... --Umberto NURS (msg) 09:08, 2 set 2014 (CEST)

Una soluzione sarebbe "annusare" nel codice le sequenze pericolose via regex immediatamente prima del salvataggio, e proporre all'utente una soluzione standard del problema. Es. una regex che annusa l'esempio 1 e lo distingue dall'esempio 3 potrebbe essere: r=/\'\'\'.+\'\'\'.+[^l]\'\'\'.+\'\'[^']*/. Utente avvisato mezzo salvato; inoltre la soluzione adottata potrebbe essere più uniforme (molti utenti seguirebbero il suggerimento)--Alex_brollo Talk|Contrib 15:11, 2 set 2014 (CEST)

(rientro, un po' OT) ma invece perchè lo spazio automatico dopo PostCognome non c'è più? --ROSA NERO 21:53, 2 set 2014 (CEST)

di là --ROSA NERO 22:14, 3 set 2014 (CEST)

Da quanto scritto in Wikipedia:Accessibilità del contenuto#HTML si dovrebbe usare HTML il meno possibile. R5b (msg) 12:28, 6 set 2014 (CEST)