opzioni per `converti`

[danse]

vorremmo che il convertitore web utilizzasse i comandi di conversione nel modo più semplice possibile, così da avere un'interfaccia chiara fra i due progetti. da questo punto di vista sarebbe comodo se il convertitore web potesse invocare direttamente un comando come converti che applichi internamente le buone pratiche. converti non è di per se adatto a questo caso d'uso perché punta alla massima automazione al costo dell'introduzione di errori aggiuntivi, quindi è indicato solo per utenti esperti che sappiano identificare con più facilità quale passaggio è andato storto. credo che una buona soluzione sarebbe quella di aggiungere un comando converti-web che possa essere utilizzato direttamente dal servizio di conversione.

per comunicare più facilmente i casi di errore, converti-web potrebbe ricevere le opzioni utente tramite un singolo file JSON piuttosto che tramite opzioni da riga di comando. in questo modo in caso di errore di conversione sarebbe sufficiente che chi sviluppa il servizio web apra una issue sul repo dei comandi di conversione, includendo il JSON con le opzioni ed il documento da convertire.

per esempio l'interfaccia di converti-web potrebbe essere:

$ converti-web <documento> --options "{ wrap: true, font-to-style: false }"

piuttosto che:

$ converti-web <documento> --wrap=true --font-to-style=false

credo che questo faciliterebbe l'uso del comando da parte del task celery, e la comunicazione fra gli sviluppatori in caso di errore. quando si verifichi un errore a run-time, sarà facile salvare il JSON delle opzioni insieme al documento da tradurre, per riprodurre fedelmente la condizione di errore

[danse]

un'alternativa è quella di usare lo stesso converti, aggiungere un'opzione --options lì, e renderlo più flessibile

[danse]

parlando con @yakky abbiamo capito che un file opzioni.json sarebbe ancora più comodo, così avremmo tutto il necessario leggibile su una cartella

[danse]

da una votazione su slack è emerso che @atorin, @pablopers e @giupal, in base alla loro esperienza sulla conversione, considerano prioritarie le seguenti opzioni:

• collegamento a normattiva. opzione --collegamento-normativa con valore di default false per evitare gli errori di sintassi dovuti ad un round trip attraverso HTML.
• linee che non vanno a capo. potrebbe essere un'opzione --celle-complesse o --tabelle-complesse, con valore di default false. per cui normalmente un documento avrà linee che vanno a capo, ma in caso di celle con formattazione complessa gli utenti potranno selezionare questa opzione
• rimozione quotes. potrebbe diventare --preserva-citazioni, con valore di default false. per cui normalmente tutte le citazioni vengono rimosse, a meno che non si specifichi questa opzione

Potrei spiegare queste opzioni in dettaglio nel README di converti, ed il convertitore web potrebbe indirizzare a quella pagina nel caso gli utenti vogliano approfondire. In questo modo potremmo supportare sia gli utenti da riga di comando sia gli utenti web, senza duplicare il lavoro di aggiornamento della doc

[danse]

i commenti sulle opzioni mi fanno propendere sempre più verso l'opzione di mantenere un singolo converti, di modo che le competenze degli utenti che usano i comandi possano giovare anche agli utenti del servizio web, e si sviluppi una conoscenza condivisa fra i due gruppi

[danse]

per portare converti al livello di robustezza desiderabile in un prototipo di convertitore web, probabilmente vorremmo avere anche un'opzione --dividi-sezioni con default false

[danse]

sto lavorando a questo in un branch. Potete già leggere quella che potrebbe essere la futura documentazione per le opzioni, qualsiasi commento potrebbe permetterci di risparmiare del tempo aggiustando il tiro prima ancora che lo sviluppo sia completo :)