Open alexis-michaud opened 6 years ago
> Dans un navigateur internet, ça paraît nettement plus compliqué http://www.cs.tut.fi/~jkorpela/small-caps.html.
non non. Dans HTML, l'usage des smallcaps est aussi très fastoche: il suffit d'utiliser un style CSS. Pas besoin de chercher midi à 14h, ça marche très bien. [voir les parties du discours dans ce dico http://alex.francois.free.fr/dict/Mwotlap/dictionaries/ViewOneCharacter.php5?dict=mwotlap&lang1=eng&lang2=*&langn=*&char=b, par ex.]
[image: programme] http://lacito.vjf.cnrs.fr/Alex François
2017-09-04 20:19 GMT+02:00 alexis-michaud notifications@github.com:
Le style recommandé pour l'affichage des gloses grammaticales abrégées (termes techniques: par exemple ABL pour ablatif, GEN pour génitif, PL pour pluriel, CLF pour classificateur), c'est les petites capitales.
(A titre d'exemple, voir la typographie des phrases interlinéarisées dans les bons livres de grammaire, comme les collections de Language Science Press http://langsci-press.org/catalog.)
Suivant une recommandation de Guillaume Jacques, moi dans les transcriptions de textes je mets le symbole degré ° avant ces gloses techniques, que je laisse en minuscules. L'idée c'est qu'un script repère ce symbole et mette en petites capitales la séquence qui suit, jusqu'au séparateur suivant. (Y'a un script qui fait ça pour le dictionnaire na, par exemple.) D'autres collègues ont leurs conventions à eux, par exemple Henriëtte Daudey (textes pumi) met entre barres obliques: par exemple /top/ (là où moi j'écris °top).
Dans LaTeX, fastoche: \textsc{} et le tour est joué.
Dans un navigateur internet, ça paraît nettement plus compliqué http://www.cs.tut.fi/%7Ejkorpela/small-caps.html.
Un des développements souhaitables à l'avenir ?
-
fournir une recommandation sur la façon d'encoder. Les barres obliques, moi je les utilise pour autre chose (variantes).
ajuster les scripts d'affichage en ligne et de conversion des textes (vers LaTeX notamment).
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/CNRS/Pangloss/issues/41, or mute the thread https://github.com/notifications/unsubscribe-auth/AG1kWkhsC9tF-gmI2l5IeRj1l4uXJMb7ks5sfD9HgaJpZM4PMKrE .
Facile d'afficher du texte en petites capitales oui. Mais pas du tout facile de sélectionner dans un même champ ce qu'on affiche ou non en petites capitales. Il faudra y réfléchir et instaurer des règles peut être et modifier la manière de représenter les gloses. On en reparle.
Bien entendu, l'idée d'utiliser le CSS suppose que le XML de départ permette d'identifier les gloses grammaticales (relevant de la classe Smallcaps) et celle qui ne le sont pas. Donc c'est là qu'il faut agir. Mais ce n'est pas le problème de petites capitales en lui-même, ou un problème de HTML: on aurait eu le même souci avec un export LaTeX, par exemple -- contrairement à la suggestion d'Alexis.
Logiquement, c'est au moment du glosage (sur EastLing? Toolbox??) qu'il faudrait identifier la classe de chaque glose, d'une manière ou d'une autre.
Oui c'est ça, il nous faudrait des conventions qu'on proposerait aux contributeurs. Qu'est-ce qu'on propose: ° avant et après, pour bien délimiter? (Jusqu'ici je mettais juste un degré ° avant la forme concernée) Si on choisit cet usage, et que Henriëtte s'est bien tenue à son usage des barres obliques, il suffira de remplacer tous ses \/ par des °
Il me semble qu'un symbole avant suffit après on peut utiliser une regex (en syntaxe notepad++) comme
°([\w\d.]+)
à remplacer par:
\textsc{\1}
Les gloses sont censées s'arrêter s'il y a un caractère autre que lettre (y compris _), chiffre ou point, donc par ex tab, tiret ou espace.
Si tu veux mettre un symbole avant et après, mieux vaudrait que ce ne soit pas le même symbole, sans quoi on pourrait avoir des ambiguïtés dangereuses.
-- Guillaume Jacques CNRS (CRLAO) - INALCO http://cnrs.academia.edu/GuillaumeJacques http://panchr.hypotheses.org/
Commentaire de Thomas (@tpellard) :
"on pourrait imaginer de rajouter des tags du genre \<glgram> ou \<glose type = "gram"> autour des marqueurs grammaticaux et avec une feuille de style ils seraient affichés en petites capitales. Un autre problème du préfixe de Guillaume est que sa portée est potentiellement ambigue, ou du moins peut créer des ambiguités si on n'est pas vigilant. Par exemple dans «°exist.animated_beings», on se doute que le préfixe marque tout ce qui suit comme étant une glose grammaticale, mais on pourrait imaginer des situations où ce n'est pas le cas, avec une glose grammaticale suivie d'une glose lexicale, les deux étant séparées par un point."
Un exemple comme «°exist.animated_beings» est tangent : "êtres animés", c'est un terme plutôt technique, sans être une abréviation. Moi je ne mettrais pas "animated_beings" en petites capitales, mais les avis peuvent diverger. Peut-être faudrait-il partir d'exemples bien simples, comme «°clf.books». Là, c'est clair que seule la première partie de la glose est un terme technique, et que ça doit être affiché (je mets des capitales pour simplifier) comme :
CLF.books (et pas CLF.BOOKS).
La portée du signe ° s'arrêterait donc au premier caractère autre qu'une lettre ou un chiffre ou un tiret bas (_). Contrairement à ce que suggère @rgyalrong, la portée devrait s'arrêter à un point, pour que °clf.books ne s'affiche pas comme CLF.BOOKS.
Ainsi, °1pl donnerait : 1PL, et "pluriel inclusif" devrait être noté comme : °1pl.°incl, avec un deuxième symbole "degré" pour la deuxième partie de la glose.
Est-ce qu'on est d'accord que cette syntaxe règle la question de l'encodage non ambigu des gloses techniques (à mettre en petites capitales)?
Question suivante : est-ce que la conversion des ° en balises \<glgram> autour des marqueurs grammaticaux concernés interviendrait lors du dépôt du document dans Pangloss, ou est-ce que ça serait interprété "à la volée" lors de l'affichage du XML dans l'interface Pangloss? Un avantage à la deuxième solution est que les fichiers après archivage resteraient faciles à modifier pour leurs auteurs. Tandis que si le fichier une fois déposé a un format qui n'est pas celui qu'on utilise pour la saisie, on se complique la vie pour modifier le document plus tard (il faut saisir toute une séquence \<glgram>\</glgram> au lieu d'un simple °.
Il me semble que dans l'attente de balises adéquates, les gloses grammaticales devraient être saisies en capitales. Pour l'instant le format adopté avec préfixe + minuscules ne correspond pas aux attentes des linguistes qui s'attendent à trouver des (petites) capitales. S'il faut utiliser un préfixe, le signe @ est peut-être plus simple à saisir sur n'importe quel clavier (et aujourd'hui tout le monde sait le trouver), même s'il est visuellement plus intrusif. La portée du préfixe devrait s'arrêter au premier signe de ponctuation ou symbole non-alphanumérique (.,:;\<>+~)
@sylvainloiseau : tu aurais des idées ?
en plaçant cette question dans un cadre plus général d'interopérabilité
il me semble que la plupart des cas, le travail d'annotation est fait dans un environnement (toolbox, flex), et que c'est dans cet environnement qu'il faut établir une convention pour distinguer les morphèmes grammaticaux et lexicaux, de façon à récupérer cela en aval et préserver cette information dans un document XML par exemple.
pour les textes déjà annotés dont on ne dispose que d'une version très pauvre, dans la mesure du possible, je dirais qu'il faut privilégier l'établissement d'une liste des gloses utilisées dans un document, et identifier les gloses grammaticales pour les mettre en forme, dans le flux du texte, sur la base de ce lexique. Cela permet une identification plus robuste et ça fournit en même temps une documentation des catégories grammaticales utilisées dans les gloses...
quand c'est impossible -- et quand il faut donc en passer par des expressions régulières un peu plus complexes pour identifier les gloses grammaticales dans le flux du texte -- je ne vois pas ce qu'apporte un caractère ad hoc (° ou @) par rapport au fait de mettre les gloses grammaticales en majuscules. Dans les deux cas c'est identifiable au moyen d'expressions régulières. En mettant les gloses grammaticales en majuscules, on a le meilleur état possible quand le texte est au format "texte brut". Pour identifier les gloses grammaticales et les mettre en petites majuscules notamment pour un format permettant de la mise en forme typographique, il suffit ensuite d'identifier toute séquence de caractères comprenant des majuscule + numérique + "_" bornée par des blancs, des tirets, des "\" des ":" ou des "." (non exhaustif, et variable en fonction des textes...)).
Merci @sylvainloiseau
Un des enjeux de la refonte du site peut consister à progressivement proposer la liste des abréviations de façon bien systématique. Actuellement, la liste des abréviations est parfois fournie au sein du simple document HTML non structuré (sans feuille de style recommandée) qui est construit pour chaque corpus (pour chaque langue) : le document qui s'affiche qd on clique sur le nom de la langue en tête de la liste des ressources.
Mais ce n'est pas systématique, pas lisible par machine...
Quel format proposer aux contributeurs pour fournir leurs abréviations ?
Un tableau en 3 colonnes, avec : abréviation en 1e colonne, glose complète en 2e colonne, et commentaires dans la 3e colonne ?
Ou quelque chose de plus structuré, en XML, qui spécifie dans quelle langue se trouvent la glose, les commentaires ?
C'est la bonne année où proposer des recommandations précises :-)
Outre l'affichage sur le site, ce document serait à archiver avec le même soin que les annotations elles-mêmes, et un lien par les métadonnées : "requires..." (le fichier XML d'annotations a besoin du fichier explicitant les conventions pour être exploité), éventuellement "IsRequiredBy" pour indiquer quels fichiers d'annotation (ressources) font appel au fichier contenant les conventions.
Par cohérence avec le format actuel des documents, un format XML paraîtrait bien approprié.
Transféré vers Eastling (lecteur). C'est un gros morceau : toute la question de l'affichage des gloses techniques.
S'agit-il d'appliquer cette mise en forme aux mots ou morphèmes ayant une classe renseignée ? (comme dans ce ticket : #57 )
Excellente question. En effet, il faut bien réfléchir non seulement à l'affichage par le lecteur Eastling, mais aussi aux questions d'encodage dans la base de données Pangloss elle-même, qui y sont directement liées. Un codage explicite serait bien, ça constituerait un net progrès : comme dans le #57, ainsi que tu le relèves. <M class="CL">
Mais on en est encore loin.
@sylvainloiseau pourrait avoir des idées et peut-être formuler des recommandations concernant le codage, pour les nouveaux dépôts et pour l'enrichissement de dépôts existants. Mais c'est un travail de moyen terme.
Le nombre de documents qui disposent de gloses techniques n'est pas extrêmement élevé, mais les pratiques sont peu homogènes. Dans l'immédiat, il faudrait parvenir à identifier les termes techniques, de façon à les afficher en petites capitales. Il faudrait partir des cas de figures existants :
Le style recommandé pour l'affichage des gloses grammaticales abrégées (termes techniques: par exemple ABL pour ablatif, GEN pour génitif, PL pour pluriel, CLF pour classificateur), c'est les petites capitales.
(A titre d'exemple, voir la typographie des phrases interlinéarisées dans les bons livres de grammaire, comme les collections de Language Science Press.)
Suivant une recommandation de Guillaume Jacques, moi dans les transcriptions de textes je mets le symbole degré ° avant ces gloses techniques, que je laisse en minuscules. L'idée c'est qu'un script repère ce symbole et mette en petites capitales la séquence qui suit, jusqu'au séparateur suivant. (Y'a un script qui fait ça pour le dictionnaire na, par exemple.) D'autres collègues ont leurs conventions à eux, par exemple Henriëtte Daudey (textes pumi) met entre barres obliques: par exemple /top/ (là où moi j'écris °top).
Dans LaTeX, fastoche: \textsc{} et le tour est joué.
Dans un navigateur internet, ça paraît nettement plus compliqué.
Un des développements souhaitables à l'avenir ?
fournir une recommandation sur la façon d'encoder. Les barres obliques, moi je les utilise pour autre chose (variantes).
ajuster les scripts d'affichage en ligne et de conversion des textes (vers LaTeX notamment).