Affichage d'une langue de traduction "autre" alors qu'il n'y en a pas
sguillaume opened this issue · comments
Indication d'une langue "autre" de traduction au niveau de la phrase (en plus du français) alors qu'il n'y a pas d'autre langue de traduction.
-> ex.
https://pangloss.cnrs.fr/corpus/show?corpus=Boomu&lang=fr&mode=pro&oai_primary=cocoon-f5ad26ac-ffbf-42a7-ad26-acffbf22a7cc&oai_secondary=cocoon-69556e97-90b3-45e5-956e-9790b365e5b9
(Est ce que cette info est prise au niveau du mot (W) ou morphème (W) qui eux n'ont pas d'indication de langue de traduction ?
Si oui, il faudrait rectifier pour ne pas donner l'impression qu'il y a une deuxième langue de traduction au niveau de la phrase (S))
Bien vu !
C'est lié à une question plus générale d'encodage des métadonnées (attributs). Une partie est implicite (non codée dans le texte structuré logiquement) et doit être "héritée" d'un autre niveau. Par exemple, dans un document qui n'a que des traductions dans une certaine langue, les traductions sans attribut lang sont vraisemblablement dans cette langue.
Dans un monde parfaitement balisé, chaque élément aurait ses attributs.
À réfléchir pour Eastling, de pouvoir ajouter les attributs automatiquement lors de la saisie : on indique la langue de traduction, et toutes les traductions qu'on saisit pendant la session en question (ou : jusqu'à ce qu'on change ce paramètre) portent toutes pour attribut la langue en question ? (question qui concerne Eastling-éditeur, du coup)
Vu, modifier le parser PHP que le player appelle au chargement
(Est ce que cette info est prise au niveau du mot (W) ou morphème (W) qui eux n'ont pas d'indication de langue de traduction ? Si oui, il faudrait rectifier pour ne pas donner l'impression qu'il y a une deuxième langue de traduction au niveau de la phrase (S))
C'est exactement ça qui se passe.
Je peux faire en sorte de considérer que lorsqu'il y a des traductions de niveau W ou M sans précision, elles sont donc dans la même langue que les traductions disponibles au niveau S, mais que se passe-t-il dans le cas où on a 2 langues de traductions disponibles au niveau S ? (et qu'elles ne sont pas précisées au niveau inférieur)
En fait, l'idéal serait de n'indiquer la langue de traduction qu'au niveau où elle est spécifiée.
S'il n'y a pas de langue indiquée au niveau W ou M on indique uniquement "autre" par exemple.
Par contre, il me semble que si jamais il n'y a pas de langue au niveau S alors on concaténe les mots de W et c'est uniquement dans ce cas qu'il faudrait indiquer la langue de traduction qui est indiquée au niveau W.
Et s'il y a 2 langues de traduction au niveau S alors on indique chacune dans une case à cocher différente.
(Mais pour cette dernière partie je ne suis pas certaine d'avoir bien compris la question)
C'est faisable ainsi ?
Et s'il y a 2 langues de traduction au niveau S alors on indique chacune dans une case à cocher différente. (Mais pour cette dernière partie je ne suis pas certaine d'avoir bien compris la question)
Je mentionne un cas qui n'existe peut-être pas, mais je pensais à 2 langues de traductions au niveau S (ex : fr et en) et des traductions existantes aux niveaux W et M sans précision de langue : que ferait-on dans ce cas ?
On indiquerait forcément "fr" ou "en" si une de ces 2 langues est présentes en traduction de S (s'il y a comme traduction le chinois et l'anglais on indique l'anglais par exemple).
Mais s'il y a les 2 ("fr" et "en") alors il faut choisir mais je ne saurai pas trancher car on a 1 chance sur 2 de se tromper.
Du coup peut être que le mieux est de ne pas répercuter et de mettre "autre" quand il n'y a pas de langue de traduction au niveau W et M.
Et j'essaierai d'homogénéiser à terme pour faire en sorte qu'il y en ait toujours une.
Ca serait une bonne solution non ?
ok, donc :
- si 1 seule langue de traduction au niveau S, on répercute sur toutes les traductions de niveau inférieur.
- si 1+ langues de traduction au niveau S, on met "autre" aux niveaux inférieurs si la langue n'est pas renseignée
Je dirais qu'on répercute uniquement quand il n'y a aucune langue de traduction au niveau concerné W ou M.
Comme ça quand j'homogénéiserai ça sera la langue au niveau W ouM qui remplacera celle transmise par S (je ne sais pas si je suis claire).
En gros oui on répercute si pas renseigné et que si une seule langue au niveau S.
Ca te parait assez carré comme ça ?
Sinon je suis preneuse si t'as une idée plus cohérente.
on va commencer comme ça et on verra!
ok !
Traité et livré, à tester
Il y a un souci d'affichage de certaines ressources (je ne sais pas si c'est lié).
Je n'arrive pas à visualiser les annotations du na de Yongning.
ex : https://doi.org/10.24397/pangloss-0004341
<S id="Sister_S175">
<AUDIO start="497.5668" end="500.4643"/>
<FORM kindOf="phono">tʰi˩˥, | ə˧zɯ˩ | zo˩no˥… | æ˧ʂæ˧-hĩ˧ | <dʑɤ˩˥ mɤ˧-do˩> [mɤ˧-dʑo˩-ze˩]!</FORM>
C'est l'utilisation de balise <dʑɤ˩˥ mɤ˧-do˩> qui pose problème car le player essaie de l'interpréter, a-t-on souvent ce cas d'utilisation ?
Quelle est l'utilité des balises < > et [ ] ?
Les gens utilisent régulièrement ces caractères effectivement.
Mais < et > sont transformés en < et >.
[ et ] par contre n'empêchent pas la validation du xml donc ils restent ainsi.
Ca serait difficile de demander aux gens de ne plus les utiliser.
Du coup ça concerne des documents d'autres corpus aussi.
Il y a moyen de régler ça sans modifier les fichiers d'annotations xml ?
J'ai trouvé d'où vient le problème. C'est en lien (et en contradiction) avec ce ticket : #204
dans lequel on a fait interpréter les balises <> (pour pouvoir interpréter <FOREIGN> et ne pas l'afficher en toute lettre).
Je n'ai pas de solution simple pour le moment, pour ne pas bloquer les utilisateurs du site, je pense que'il faut faire machine arrière et rouvrir le ticket #204 .
En effet, l'utilisation des balises <> dans des annotations nous contraint à ne pas interpréter de balises et à afficher le texte tel quel, et il faut donc trouver une autre solution pour traiter le ticket #204
J'ai remis le code du player sans interprétation des balises, mais du coup les balises FOREIGN Seront visibles en tant que texte, #204 à rouvrir
Ok. C'est surement le mieux en attendant.
Ca n'est pas possible d'interpréter les balises uniquement quand c'est une qui nous intéresse d'interpréter et de considérer les autres juste comme du texte ? :p
Si mais ça suppose qu'on whitelist exhaustivement les balises à interpréter, donc il faut penser à tout !
Ca devrait pouvoir le faire sans trop de pb. On en reparle lundi prochain si t'es là !
J'ai réglé le problème. A tester
J'ai réglé le problème. A tester
L'affichage est revenu (sur mon poste), dans toute sa splendeur !
Cette histoire d'avoir une balise à l'intérieur d'un champ <FORM>, c'est pas banal, et pas répandu... mais en effet il faut réfléchir aux cas d'usages éventuels. Ca pourrait également se poser pour des appels de notes. En effet, pour l'instant, les notes se placent à un niveau donné et on peut en mettre au niveau qu'on veut (TEXT, S, W, M). Alors que ça pourrait être bien de pouvoir placer des appels de note comme ça se fait dans des livres : à l'endroit qu'on veut dans un texte (à la fin d'un mot, au milieu d'une phrase, aussi bien qu'en fin de phrase).
Bref : à reprendre en effet, sur un plan aussi générique que possible.
Commentaire suite à bref échange : éviter le code à interpréter à l'intérieur d'une balise <FORM>
Il faudra donc re-coder les quelques documents qui font usage de la balise <FOREIGN>.
On peut utiliser des balises mais dans ce cas il faudra définir celles qu'on permet.
Le titre du ticket n'étant pas super-parlant, et le fil un peu long, je me permets de le fermer et d'en ouvrir un autre pour la question telle qu'elle ressort des échanges.