per i programmatori che conoscono le regexp


Simone Dal Maso
 

Ciao,
allora, per rendere più felice la mia anima e il mio cuoricino, non poteva esserci cosa migliore che gli sviluppatori modificassero la struttura del file symbols.dic di NVDA per la prossima 2021.1.
O meglio, lo hanno riordinato, ma lasciamo perdere, ho già imprecato a sufficienza . :-)))
Ordunque, mi sono accorto che noi abbiamo delle regexp che sono un po' diverse rispetto all'internazionale, che riguardano il punto e il punto esclamativo.
Mi spiego.
Nel file internazionale troviamo:

. sentence ending (?<=[^\s.])\.(?=[\"'”’)\s]|$)
! sentence ending (?<=[^\s!])\!(?=[\"'”’)\s]|$)

Nel nostro file abbiamo:

. sentence ending (?<=[^\s.])\.(?=[\"'”’)\s\],;:»]|$)
! sentence ending (?<=[^\s!])\!(?=[\"'”’)\s\]!,;:»\.!]|$)

Credo sia sempre stato così e probabilmente ci sarà un buon motivo, però mi sto perdendo nell'interpretazione!
Secondo voi lo lasciamo così o è il caso di adeguarci al file internazionale?
Finché voi ci pensate, io torno ai miei nuovi simboli matematici, che c'è un simpatico wreath product che letteralmente vorrebbe dire prodotto ghirlanda, e dubito che una ghirlanda abbia a che fare con la matematica!
Grazie a chi aiuterà!


Alberto Buffolino
 

Simone Dal Maso, il 20/05/2021 15.52, ha scritto:
Nel file internazionale troviamo:
. sentence ending    (?<=[^\s.])\.(?=[\"'”’)\s]|$)
! sentence ending    (?<=[^\s!])\!(?=[\"'”’)\s]|$)
Nel nostro file abbiamo:
. sentence ending    (?<=[^\s.])\.(?=[\"'”’)\s\],;:»]|$)
! sentence ending    (?<=[^\s!])\!(?=[\"'”’)\s\]!,;:»\.!]|$)
Credo sia sempre stato così e probabilmente ci sarà un buon motivo, però mi sto perdendo nell'interpretazione!
Alberto:
Ciao Simone,
io farei una via di mezzo... considera che la regex internazionale:
(?<=[^\s.])\.(?=[\"'”’)\s]|$)
si traduce con "punto, preceduto da qualunque cosa non sia uno spazio o un punto, e seguito da la roba fra quadre o un fine riga".
Ora, se guardi la nostra regex:
(?<=[^\s.])\.(?=[\"'”’)\s\],;:»]|$)
vedi che, nell'ultimo gruppo, in più abbiamo la chiusa quadra, virgola, punto e virgola, due punti e le chiuse doppie virgolette.
Così a naso, io terrei solo la chiusa quadra e le chiuse doppie virgolette, tutti gli altri casi fatico un po' a considerarli fine frase... idem per il punto esclamativo.
Sentiamo comunque che dice Chris, che ha lavorato anche su espeak.
Alberto


ChrisLM
 

Ciao,

non avevo notato questa differenza, o per lo meno faccio fatica a ricordare.

Fondamentalmente non cambia quasi nulla, nel senso, la combinazione tra parentesi quadre considera solo ed un unico carattere. Messa così nel symbols.dic italiano controlla anche diversi segni di punteggiatura che sono improbabili a fine frase.

Probabilmente quando sono stati aggiunti lo scopo era quello di ignorare errori di battitura. Per esempio in una stringa così:

"Oggi non vado a scuola.;"


Io sono un po' contrario a usare questi metodi, anche perché chi lavora sulla correzione di testo quel punto e virgola dopo il punto la passa liscia e dificilmente viene catturato dalla lettura.

Sono quindi in sintonia con quello che ha proposto Alberto.

Riguardo ai sintetizzatori, NVDA  lascia ampio gioco anche grazie a queste regex. Si possono verificare comportamenti diversi a fine frase , non solo riguardo l'intonazione differente per tipo di frase. Per esempio, un confronto al volo, eSpeak-ng riconosce al volo se la parola dopo un punto inizia con maiuscola, eloquence se ne frega e legge correttamente come se nulla fosse anche se dopo il punto c'è una minuscola.

Ma quì siamo già fuori dal processo dello screen reader.

Tornando alla regex, come già indicato da alberto, toglierei dalla combinazione tra parentesi quadre  la virgola, i due punti e il punto e virgola.

Se il testo è scritto male è giusto che lo screen reader legga male!



Chris.

Alberto Buffolino ha scritto il 20/05/2021 alle 17:27:

io farei una via di mezzo... considera che la regex internazionale:
(?<=[^\s.])\.(?=[\"'”’)\s]|$)
si traduce con "punto, preceduto da qualunque cosa non sia uno spazio o un punto, e seguito da la roba fra quadre o un fine riga".
Ora, se guardi la nostra regex:
(?<=[^\s.])\.(?=[\"'”’)\s\],;:»]|$)
vedi che, nell'ultimo gruppo, in più abbiamo la chiusa quadra, virgola, punto e virgola, due punti e le chiuse doppie virgolette.
Così a naso, io terrei solo la chiusa quadra e le chiuse doppie virgolette, tutti gli altri casi fatico un po' a considerarli fine frase... idem per il punto esclamativo.
Sentiamo comunque che dice Chris, che ha lavorato anche su espeak.


Simone Dal Maso
 

Ciao,
grazie davvero dei vostri contributi, Alberto e Chris.
Ho sistemato le due stringhe uniformandole al file internazionale.
Era la cosa più logica in effetti.
Adesso rimangono una caterva di simboli matematici decisamente oscuri, ho provato a coinvolgere una persona che lavora al dipartimento di matematica dell'università di Padova, sono piuttosto ottimista!
Grazie ancora.

Il 20/05/2021 19:23, ChrisLM ha scritto:
Ciao,
non avevo notato questa differenza, o per lo meno faccio fatica a ricordare.
Fondamentalmente non cambia quasi nulla, nel senso, la combinazione tra parentesi quadre considera solo ed un unico carattere. Messa così nel symbols.dic italiano controlla anche diversi segni di punteggiatura che sono improbabili a fine frase.
Probabilmente quando sono stati aggiunti lo scopo era quello di ignorare errori di battitura. Per esempio in una stringa così:
"Oggi non vado a scuola.;"
Io sono un po' contrario a usare questi metodi, anche perché chi lavora sulla correzione di testo quel punto e virgola dopo il punto la passa liscia e dificilmente viene catturato dalla lettura.
Sono quindi in sintonia con quello che ha proposto Alberto.
Riguardo ai sintetizzatori, NVDA  lascia ampio gioco anche grazie a queste regex. Si possono verificare comportamenti diversi a fine frase , non solo riguardo l'intonazione differente per tipo di frase. Per esempio, un confronto al volo, eSpeak-ng riconosce al volo se la parola dopo un punto inizia con maiuscola, eloquence se ne frega e legge correttamente come se nulla fosse anche se dopo il punto c'è una minuscola.
Ma quì siamo già fuori dal processo dello screen reader.
Tornando alla regex, come già indicato da alberto, toglierei dalla combinazione tra parentesi quadre  la virgola, i due punti e il punto e virgola.
Se il testo è scritto male è giusto che lo screen reader legga male!
Chris.
Alberto Buffolino ha scritto il 20/05/2021 alle 17:27:
io farei una via di mezzo... considera che la regex internazionale:
(?<=[^\s.])\.(?=[\"'”’)\s]|$)
si traduce con "punto, preceduto da qualunque cosa non sia uno spazio o un punto, e seguito da la roba fra quadre o un fine riga".
Ora, se guardi la nostra regex:
(?<=[^\s.])\.(?=[\"'”’)\s\],;:»]|$)
vedi che, nell'ultimo gruppo, in più abbiamo la chiusa quadra, virgola, punto e virgola, due punti e le chiuse doppie virgolette.
Così a naso, io terrei solo la chiusa quadra e le chiuse doppie virgolette, tutti gli altri casi fatico un po' a considerarli fine frase... idem per il punto esclamativo.
Sentiamo comunque che dice Chris, che ha lavorato anche su espeak.


Adriano Barbieri
 

Ciao Simone,

Quei controlli li avevo aggiunti io a suo tempo, proprio perché spesso trovavo testi che li contenevano e che alteravano le risposte delle sintesi Loquendo, io li lascerei così, non capisco perché si debba perforza copiare da quelli internazionali, però fai come vuoi naturalmente.

Adriano


Il 20/05/2021 15:52, Simone Dal Maso ha scritto:

Ciao,
allora, per rendere più felice la mia anima e il mio cuoricino, non poteva esserci cosa migliore che gli sviluppatori modificassero la struttura del file symbols.dic di NVDA per la prossima 2021.1.
O meglio, lo hanno riordinato, ma lasciamo perdere, ho già imprecato a sufficienza . :-)))
Ordunque, mi sono accorto che noi abbiamo delle regexp che sono un po' diverse rispetto all'internazionale, che riguardano il punto e il punto esclamativo.
Mi spiego.
Nel file internazionale troviamo:

. sentence ending    (?<=[^\s.])\.(?=[\"'”’)\s]|$)
! sentence ending    (?<=[^\s!])\!(?=[\"'”’)\s]|$)

Nel nostro file abbiamo:

. sentence ending    (?<=[^\s.])\.(?=[\"'”’)\s\],;:»]|$)
! sentence ending    (?<=[^\s!])\!(?=[\"'”’)\s\]!,;:»\.!]|$)

Credo sia sempre stato così e probabilmente ci sarà un buon motivo, però mi sto perdendo nell'interpretazione!
Secondo voi lo lasciamo così o è il caso di adeguarci al file internazionale?
Finché voi ci pensate, io torno ai miei nuovi simboli matematici, che c'è un simpatico wreath product che letteralmente vorrebbe dire prodotto ghirlanda, e dubito che una ghirlanda abbia a che fare con la matematica!
Grazie a chi aiuterà!








ChrisLM
 

Ciao,

No, Simone non fa come vuole, come giustamente avrai notato ha chiesto alla community.
questo è uno degli aspetti che stimo di più del nostro moderatore e traduttore. A creare una listarella son capaci tutti, ma fare il leader e manterene una community ci vuole pure un poco di umiltà e grossi attributi.
Sono d'accordo, non è detto da nessuna parte che il symbols.dic deva esser copiato da quello originale, o internazionale se preferiamo. Però  almeno, secondo la mia opinione,  bisogna seguirne la logica.
Il symbols.dic è accomodato per tutti i sintetizzatori, quello di accomodare impostazioni per un unico sintetizzatore senza controllare eventuali comportamenti sgraditi ad altri sintetizzatori, SEMPRE SECONDO LA MIA OPINIONE,  non mi pare rientri in nessuna logica di NVDA.

Le motivazioni per eventuali modifiche al symbols.dic italiano sono espresse nelle risposte alla discussione aperta da Simone, sarebbe anche corretto non ignorarle.


Chris.

Adriano Barbieri via groups.io ha scritto il 23/05/2021 alle 10:10:


Ciao Simone,

Quei controlli li avevo aggiunti io a suo tempo, proprio perché spesso trovavo testi che li contenevano e che alteravano le risposte delle sintesi Loquendo, io li lascerei così, non capisco perché si debba perforza copiare da quelli internazionali, però fai come vuoi naturalmente.


Adriano Barbieri
 

Caro Chris,

Calma,non fraintendere, mi sono espresso male, intendevo dire naturalmente che la comunity può fare ciò chepiù desidera, ho solo espresso la mia opinione.
Simone è una persona che stimo tantissimo e che rispetto molto anch'io per tutto quello che fa per la comunity, non avere dubbi.
Ciao Simone

Adriano


Il 23/05/2021 12:01, ChrisLM ha scritto:

Ciao,

No, Simone non fa come vuole, come giustamente avrai notato ha chiesto alla community.
questo è uno degli aspetti che stimo di più del nostro moderatore e traduttore. A creare una listarella son capaci tutti, ma fare il leader e manterene una community ci vuole pure un poco di umiltà e grossi attributi.
Sono d'accordo, non è detto da nessuna parte che il symbols.dic deva esser copiato da quello originale, o internazionale se preferiamo. Però  almeno, secondo la mia opinione,  bisogna seguirne la logica.
Il symbols.dic è accomodato per tutti i sintetizzatori, quello di accomodare impostazioni per un unico sintetizzatore senza controllare eventuali comportamenti sgraditi ad altri sintetizzatori, SEMPRE SECONDO LA MIA OPINIONE,  non mi pare rientri in nessuna logica di NVDA.

Le motivazioni per eventuali modifiche al symbols.dic italiano sono espresse nelle risposte alla discussione aperta da Simone, sarebbe anche corretto non ignorarle.


Chris.

Adriano Barbieri via groups.io ha scritto il 23/05/2021 alle 10:10:

Ciao Simone,

Quei controlli li avevo aggiunti io a suo tempo, proprio perché spesso trovavo testi che li contenevano e che alteravano le risposte delle sintesi Loquendo, io li lascerei così, non capisco perché si debba perforza copiare da quelli internazionali, però fai come vuoi naturalmente.