Grosse proportion de mots accentués découpés

[luc.salommez]

Bonjour tout le monde,

Je suppose que le problème a été rencontré par pas mal de monde mais je ne l’ai pas vu être évoqué.

Lorsque je m’enregistre ou que je valide des échantillons, je remarque qu’il y a de plus en plus de phrase dont les mots accentués sont découpés en plusieurs morceaux, rendant la phrase illisible et surtout pénalisant probablement les algorithmes apprenant à partir de ces phrases.

Exemple de phrase : “Un commencement de mystère menaçait « l’ordre établi », lequel était suspect et sournois.”

Au début je laissais passer pensant que c’était marginal ou que c’était un bug côté front mais je pense que le problème est assez important pour être adressé.

Une idée d’où ça peut venir ?

[lissyx]

Je suis désolé, j’ai rien compris au problème que tu exposes. C’est le texte qui est mal découpé ? Ce sont les enregistrements qui posent problème ?

Je ne vois rien de problématique dans l’exemple que tu cites.

Voici un screenshot de ta phase problématique, qui est correcte là :

Du coup, je ne comprends pas, c’est cette phrase sur le site qui est cassée ?

[lissyx]

(par contre je veux vraiment vérifier et comprendre ce qui se passe).

[luc.salommez]

Alors là, j’ai été stupéfait de voir ton screenshot.
Voici ce que j’obtiens :

J’ai tout de suite pensé à un problème de navigateur (Je suis sous Firefox, je n’ai pas fait la toute dernier maj mais je suis presque à jour).

En allant effectivement sur Chrome j’ai exactement comme toi.

Comme j’ai voulu le montrer sur le screenshot, en double cliquant sur le mot, sa sélectionne aussi l’espace et la fin du mot.

Je pense que c’est pour ça que sur Chrome ça donne un mot unique, je pense qu’il y a un problème d’encodage ou de caractère spécial (ça n’arrive qu’après des caractères spéciaux).

Ce qui est étonnant c’est que seules les phrases récentes proposées sur Common Voice ont ce problème.
Je tombe encore de temps en temps sur des phrases accentuées non concernées par ce problème.

Je vais faire la maj et voir si ça change quelque chose. J’ai quand même un peu peur que des utilisateurs pas totalement à jour tombent aussi dessus.
Mais bon, ça reste lisible.

Comme je l’ai dit plus haut, j’avais plus peur pour l’apprentissage (peur qui persiste, puisque je me demande si l’algo ne va pas lire les caractères bugués et non bugués comme deux caractères distincts).

Bref, en rentrant ce soir j’essayerai de voir si l’encodage des caractères spéciaux est toujours le même.

EDIT : Après mise à jour, le problème a disparu.
Pourtant j’étais pas tant en retard niveau version … Le problème reste étrange.

[luc.salommez]

@lissyx Mon inquiétude se confirme, en prenant un “é” sur Common Voice et un “é” normal, et en utilisant un convertisseur comme celui-ci :
https://www.asciitohex.com/
ou celui là
https://www.binaryhexconverter.com/binary-to-ascii-text-converter

J’obtiens deux code hexa différents pour les deux lettres.
é --> 01100101 11001100 10000001
é --> 11000011 10101001

Il va surement falloir mouliner sur les fichiers sources des phrases pour uniformiser les caractères (indifférents pour nous mais différents pour la machine).

Une idée duquel il vaut mieux garder ?

[lissyx]

Une idée duquel il vaut mieux garder ?

Normalement, on utilise UTF-8.

[lissyx]

Il y a clairement un caractère pourri là :

>>> ord(u"é")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: ord() expected a character, but string of length 2 found
>>> ord(u"é")
233

[lissyx]

$ git grep -c "é" server/data/fr/
server/data/fr/sentence-collector.json:1
server/data/fr/sentence-collector.txt:50800

[lissyx]

@luc.salommez Merci pour le retour, je pense que j’ai trouvé l’origine, et normalement ce sont uniquement des données qui ne font pas partie des versions de Common Voice releasées officiellement. Donc on devrait pouvoir corriger directement les données dans Sentence Collector et dans Common Voice, sans en perdre vu que c’est juste un soucis de normalisation des caractères Unicode.