search

CNRS-LACITO / eastlingplayer

This is the official repository of the Eastling player. It is part of the Eastling suite: Easy Annotation and Synchronization Tool for linguists.
GNU General Public License v3.0
2 stars 0 forks source link

Bug affichage traduction du texte #59

Closed sguillaume closed 1 year ago

sguillaume commented 3 years ago

Une concatenation au niveau W est faite pour créer une traduction du texte (qui apparait sous "autre") alors qu'il existe des traductions au niveau S. On se retrouve donc avec 4 traductions de textes (3 correctes et une qui est un ensemble de gloses concaténées) Il faut faire une concaténation au niveau des mots W que s'il n'y a pas de traduction au niveau S.

cf. : https://pangloss.cnrs.fr/corpus/show?lang=fr&mode=pro&oai_primary=cocoon-6af04a0f-aab9-3fe9-a35e-ffe556e9c9f8&oai_secondary=cocoon-3ce3ccde-a310-3e84-be2b-eecc86474000

alexis-michaud commented 3 years ago

"Il faut faire une concaténation au niveau des mots W que s'il n'y a pas de traduction au niveau S."

à voir : une concaténation au niveau des mots W pour constituer 1 S est-elle jamais utile ? je pensais que non

C'est un point important : Des phrases mises bout à bout peuvent former un texte correct (même si dans le détail il lui manque la respiration qu'apporterait un découpage en paragraphes). Des morphèmes (d'un même mot) mis bout à bout peuvent former la forme d'un mot correct (même si dans le détail il y a souvent des complications).
En revanche, des traductions de mots mises côte à côte ne forment pas une traduction de phrase, sauf cas très particuliers (castillan-français : donde esta la farmacia correspond à : où est la pharmacie ; pareil entre thai et laotien, par exemple).

m8nli9ht commented 3 years ago

Je ne peux malheureusement rien faire à ce sujet, il faut que les chercheurs qui annotent soient plus rigoureux pour que ce problème n'apparaisse pas !! Si on regarde la première phrase de ce texte dans le fichier annotation (http://cocoon.huma-num.fr/data/breu/masters/crdo-SVM_SOURIS.xml), on constate qu'il existe bien 3 traductions (de, en, it). Cependant, dans les traductions des mots de cette phrase, AUCUNE PRECISION DE LANGUE N'EXISTE, le parser les considère donc en langue "autre" ( et "autre" devient ainsi une option de traduction disponible). La mécanique du parser prévoit de reconstruire des concaténations au niveau mot et phrase dans le cas où des transcriptions/traductions n'existerait pas pour les options proposées et, dans ce présent cas, aucune traduction n'existant pour "autre", le parser concatène !

m8nli9ht commented 3 years ago

Ce n'est donc pas un bug, le parser fonctionne bien avec les règles que nous avons imaginées.

sguillaume commented 3 years ago

En fait je pense que nous nous sommes mal exprimés.

Ce qu'il faut c'est :

Dis moi si je ne suis pas claire ou si tu as des questions (des choses qui nous paraissent évidentes à Alexis et moi ne le sont pas forcément pour d'autres)

m8nli9ht commented 3 years ago

dans le ticket #8 :

Affichage du texte entier : attention, 2 cas de figure :

le contenu désiré existe déjà sous une forme fournie par le déposant :
par exemple, ici, pour la forme orthographique :
<FORM kindOf="ortho">Eyishei jjo … aeggi! … tee niq yi guq zimu. Tiq, mussinimi nigu jjo zimu. Tiq, amu yihin jjo sso niq zimu. Tiq, sso jjo, tiq, kushae hee zimu. Tiq, jjinami wo ddeesoku teezzee zimu. Qiddi hee zimu. Tiq, ggomi jjo, tiq, awo jjo zimu. Tiq, amu lemecee jjo, tiq, hin gi gi zimu. Tiq, hin gi gi seiq jjo, tiq, ri teeq zimu. Ri teeq ha zzi wodo jjo, tiq, gezzee zimu. Gezzee jjo, tiq, ddeehin jjo ggezze zzeeq keeq, jiehin muzze zzeeq. Tiq, ddeeda gezzee: ddeehin ddeezzee ddeezzee ddeezzee ddeezzee nee teegho teejjo, maegho teegho teejjo, tiq, tee amu tee qiddi lecee zimu.
etc.
Dans ce cas on affiche le contenu de la balise en question.
Ca, ça fonctionne déjà sur le site que tu m'indiques (mais pas sur le site Pangloss v2) : souci d'intégration @EdouardSombie ?

le contenu désiré n'est pas présent en tant que tel dans le XML. Dans ce cas, on concatène le contenu des balises correspondantes au niveau de la phrase : <S>
Pour ce texte, c'est ce qu'il faut faire pour la forme "phono".
Actuellement, ça ne fonctionne pas.
(De mémoire, ça marche sur le site v1)

Ca me pose problème du coup car dans ce qui est décrit dans ce ticket, il y a bien une transcription complète fournie au niveau texte (en "ortho") mais la demande suggère qu'on fasse quand même une concaténation de phrase pour avoir du "phono".

@alexis-michaud @sguillaume pouvez-vous échanger pour savoir ce qu'il faut faire ?

m8nli9ht commented 3 years ago

(sachant que cette règle est appliquée à chaque niveau de concaténation - TEXT, S, W - et à la fois pour les FORM et le TRANSL)

sguillaume commented 3 years ago

Ce que l'on peut faire pour éviter les erreurs c'est :

Par contre pour passer de mot à phrase, il ne faut faire de concaténation que lorsqu'il n'y a rien au niveau de la phrase (en transcription ou traduction). C'est à dire que :

Ca irait comme ça ? Ces règles permettraient ainsi de produire une visualisation au plus proche des annotations qu'ont produit les chercheurs en évitant au maximum les surinterprêtations.

alexis-michaud commented 3 years ago

"On concatène les traductions des mots seulement si au niveau de la phrase il n'y a pas déjà de traduction (toutes langues confondues. C'est à dire tout xml:lang confondus)" : 👎 Désolé d'insister lourdement : il ne faut jamais créer de traduction d'une phrase en collant bout à bout des traductions de mots ou morphèmes.

sguillaume commented 3 years ago

Alexis, je croyais que tu voulais absolument faire ça. Alors parfait !

Ca me va encore mieux !

alexis-michaud commented 3 years ago

"Ce que l'on peut faire pour éviter les erreurs c'est : Au niveau transcription du texte, on fait une concaténation des phrases pour former la transcription du texte seulement si le kindOf est indiqué. Ca évitera les erreurs. Idem au niveau traduction du texte, on fait une concaténation des phrases pour former la traduction du texte seulement si le xml:lang est indiqué au niveau de la phrase."

Ca je ne comprends pas trop la logique, ça me paraît contre-intuitif pour pas mal d'utilisateurs

sguillaume commented 3 years ago

"Ce que l'on peut faire pour éviter les erreurs c'est : Au niveau transcription du texte, on fait une concaténation des phrases pour former la transcription du texte seulement si le kindOf est indiqué. Ca évitera les erreurs. Idem au niveau traduction du texte, on fait une concaténation des phrases pour former la traduction du texte seulement si le xml:lang est indiqué au niveau de la phrase."

Ca je ne comprends pas trop la logique, ça me paraît contre-intuitif pour pas mal d'utilisateurs

C'était pour éviter de concaténer des choses pour lesquelles nous n'avons pas d'information de contenu. Mais laissons tomber.

sguillaume commented 3 years ago

Bon.

Alors voici mes propositions pour faire au plus simple et éviter les problèmes d'affichage :

Matthew, garde la logique actuelle de ton parseur et je propose ceci :

Pour les transcriptions/traductions au niveau du texte :

Pour les transcriptions/traductions au niveau de la phrase :

Est ce que ça vous va ?

sguillaume commented 3 years ago

J'ai eu encore des retours sur ces problèmes d'affichage. Les gens ne comprennent pas ces affichages de concaténation de gloses dans les traductions.

Matthew, quand est ce que tu penses pouvoir régler ça en mettant en oeuvre l'affichage indiqué au dessus ?

m8nli9ht commented 3 years ago

je regarde ça aujourd'hui !

m8nli9ht commented 3 years ago

Matthew, garde la logique actuelle de ton parseur et je propose ceci :

Pour les transcriptions/traductions au niveau du texte :

* On ne concatène jamais au niveau du mot (on concatène uniquement au niveau de la phrase si besoin)

Ce n'est pas clair pour moi, peut-on utiliser un exemple ?

m8nli9ht commented 3 years ago

avec celui là peut-être ? oai_primary=cocoon-3dd9341b-647a-33d3-b0fd-2b0ab0e7f638&oai_secondary=cocoon-46ae2130-95ad-342d-9606-ef3d47594bee

alexis-michaud commented 3 years ago

Entendu pour cet exemple (dont voici le DOI).

Il y a déjà une balise <FORM> au niveau du texte entier. Spécifiquement, une balise <FORM kindOf="ortho">. C'est le contenu de cette balise que le lecteur affiche quand on clique sur la case "ortho" de "Transcription du texte". image

En revanche, comme il n'y a pas encore de <FORM> au niveau du texte entier pour les 2 autres types de transcription ("phono" et "autre"), là, on concatène l'information fournie au niveau des unités <S>.

Ca marche très bien, et tout est pour le mieux.

Personnellement, je pense que ça serait bien d'insérer un retour chariot après chaque phrase (revenir à la ligne). Mais ce n'est peut-être pas gérable via XML / XSL, les retours chariots au sein du code XML étant traités comme des séparateurs, juste comme un simple espace (ce qui est un peu ennuyeux car certains déposants, dont moi, les utilisent avec une valeur 'sémantique'). Mais c'est une autre histoire, pas directement liée à ce ticket.

m8nli9ht commented 3 years ago

Pour les transcriptions/traductions au niveau de la phrase :

* On concatène les transcriptions au niveau du mot pour former une phrase s'il n'y a pas de transcription au niveau de la phrase

* On ne concatène jamais les traductions au niveau du mot

Traité, à vérifier

m8nli9ht commented 3 years ago

Pour les transcriptions/traductions au niveau du texte :

* On ne concatène jamais au niveau du mot (on concatène uniquement au niveau de la phrase si besoin)

Le parser ne concatène en réalité jamais directement au niveau du mot pour le texte, cela passe par la phrase.

La mécanique est récursive : elle part du niveau le plus bas (morphème) et remonte jusqu'au niveau le plus haut (texte); pour chaque niveau, elle crée les concaténations pour les kindOf ou Lang qui existent pour un niveau inférieur mais pas au niveau parent.

Si on prend l'exemple de la phrase S8 du texte Na (https://doi.org/10.24397/pangloss-0004342#S8) :

alexis-michaud commented 3 years ago

Oui, tout à fait. C'est un point à examiner attentivement, qui engage plusieurs questions.

Pour reprendre l'exemple de ce texte : le retour utilisateur de premier niveau, ce serait :

il ne faut pas proposer de niveau "transcription" : "autre" au niveau des phrases et du texte.

Les mots (W) (et les quelques morphèmes (M) qui font l'objet spécifiquement d'une transcription : sous-analyse du mot) sont transcrits dans des balises FORM, de type non spécifié. Il n'y a donc pas de choix à proposer pour la transcription des mots et des morphèmes : une seule case à cocher. Pour ça, c'est très bien tel que c'est.

Les phrases (S) sont transcrites dans des balises FORM de deux types : ortho(graphique) et phono(logique). Ce sont les deux choix qu'il faut proposer. Il ne faut pas proposer de troisième choix ("autre") concaténé à partir des mots.

m8nli9ht commented 3 years ago

il ne faut pas proposer de niveau "transcription" : "autre" au niveau des phrases et du texte.

OK, traité et livré. A contrôler.

sguillaume commented 3 years ago

il ne faut pas proposer de niveau "transcription" : "autre" au niveau des phrases et du texte.

OK, traité et livré. A contrôler.

Attention ! Il y a souvent des transcriptions au niveau de la phrase ou du texte qui ne sont pas étiquetées avec un "kindOf" ("ortho", "phono" etc etc). Parfois il n'y a rien d'indiqué, il faut quand même absolument afficher ces transcriptions (le kindOf est facultatif. Sinon il faudrait le systématiser ce qui n'est pas le cas actuellement). Et puisqu'on a pas l'info du kindOf, ces transcriptions se retrouvent forcément étiquetées "autre"

sguillaume commented 3 years ago

A part ce problème où il faut réafficher "autre" (tout à l'heure avant ta dernière livraison c'était ok, les "autre" s'affichaient bien il me semble), pour la non concaténation des TRANSL de mots ça a l'air tout bon ! Merci :)

alexis-michaud commented 3 years ago

Suite à discussion avec Séverine : on ne construit jamais de FORM au niveau S par concaténation de niveaux inférieurs. Si le niveau S ne comporte pas de FORM, on n'en affiche pas. Pareil s'il n'y a pas de TRANSL : on n'affiche rien.

Les seuls cas de concaténation d'un niveau inférieur pour créer du contenu pour le niveau supérieur sont ceux de :

Là normalement on sera bon :smiley:

Désolé pour les nombreuses hésitations et difficultés qu'il y a eu à tirer au clair ce qu'il en est. Ce n'est ni très simple ni très symétrique, quand on y pense en termes informatiques (pour savoir quoi concaténer, il faut des informations, exposées ici, qui sont sans lien direct avec la hiérarchie du fichier XML en tant que telle).

alexis-michaud commented 2 years ago

@sguillaume @m8nli9ht suite à cette discussion longue et intense d'il y a 18 mois, où on en est du traitement de ce ticket ? C'est tout bon et il peut être fermé ?

m8nli9ht commented 2 years ago

@alexis-michaud peux-tu confirmer qu'il ne faut pas concaténer au niveau S depuis W comme expliqué dans ton commentaire :

Il ne faut pas proposer de troisième choix ("autre") concaténé à partir des mots.

alexis-michaud commented 2 years ago

Absolument. Il ne faut pas proposer de troisième choix ("autre") concaténé à partir des mots.

L'essentiel des conclusions se trouve dans cette partie de la discussion, élaborée avec S.G. : https://github.com/CNRS-LACITO/eastlingplayer/issues/59#issuecomment-773922040

on ne construit jamais de FORM au niveau S par concaténation de niveaux inférieurs. Si le niveau S ne comporte pas de FORM, on n'en affiche pas. Pareil s'il n'y a pas de TRANSL : on n'affiche rien.

Les seuls cas de concaténation d'un niveau inférieur pour créer du contenu pour le niveau supérieur sont ceux de :

alexis-michaud commented 1 year ago

@m8nli9ht pourrais-tu nous redire où on en est de ce ticket ? Merci++

m8nli9ht commented 1 year ago

@alexis-michaud OK, je dois faire une petite modification dans le parser pour corriger ça.

alexis-michaud commented 1 year ago

'ping' juste pour savoir si ce ticket est maintenant périmé et peut être fermé ? @m8nli9ht

m8nli9ht commented 1 year ago

Traité et livré, à tester

alexis-michaud commented 1 year ago

:+1: