Salut Sorbus.
Sorbus a écritBref, ta proposition me convient très bien alteo_gange
🙂
Sorbus a écrit-> Dans "concept", "droits d'accès au site", tu indiques "accès en lecture ouvert à tous dès le début"... Oui pour l'essentiel du site et pour les outils linguistiques rendus disponibles. Par contre, certaines parties du site ne devraient être accessibles qu'en interne : je pense au suivi des contacts avec des auteurs de dictionnaires ou autres outils, qui peuvent inclure des données personnelles (notamment des adresses courriel...). De plus, si les détails de ce suivis sont importants pour l'équipe qui y travaille, ils sont sans intérêt pour les utilisateurs du site.
C'est juste.
Sorbus a écrit> licence (des dictionnaires et outils divers rendus disponibles)... il faudra bien sûr préciser quelles licences GPL, GFDL, CC-by-sa, etc...
Oui.
Sorbus a écrit-> et licence des documents produits par le projet lui-même : GNU-GPL ?
ou, du fait des problèmes de non-compatibilité entre licences, mettre d'emblée la production du site sous plusieurs licences, comme cela se fait parfois (GNU-GPL et cc-by-sa par exemple) ?
Pour les pages du site et même pour la production de données de type liste de mots ou dictionnaire, j'ai un faible pour les licences Creative Commons. Leur clarté, leur concision, leur modularité et leur francisation sont exemplaires.
Sorbus a écrit-> liste de dictionnaires classiques : il faut distinguer les dictionnaires propres à une langues (avec le schéma "mot / définition") des dictionnaires ou lexiques bilingues (avec le schéma "mot langue 1 /mot langue 2"). Donc, dans "contenu des dictionnaires", il faudrait juste remplacer "définition (évidemment)" par "définition ou traduction"
Oui.
Sorbus a écrit-> "faire en sorte qu'un utilisateur ne se lance pas dans l'apprentissage de ces mots s'il n'a pas la possibilité de savoir comment ils se prononcent!"
Je comprends bien l'idée... Le seul moyen pour cela serait de ne rendre disponible un "dictionnaire minimal" que s'il inclut les données phonétiques (audio si possible... ou écrites)... ça impliquera certaines priorités chronologiques du travail à réaliser... Mais tu as raison
Je nuance un peu mon propos. Au minimum, il faudrait dissuader l'utilisateur de se lancer dans l'apprentissage d'une liste du vocabulaire de base d'une langue s'il n'a pas un moyen facile de connaître la prononciation des mots. Prenons le cas de quelqu'un qui a appris un peu d'espagnaol à l'école il y a 20 ans. Il peut avoir oublié une grande partie du vocabulaire mais avoir retenu la pronciation des mots (du fait de la bonne correspondance entre l'orthographe espagnole et sa prononciation, et du fait que les accents toniques suivent des règles très précises). Lui n'aurait pas impérativement besoin des sons. Et s'il avait l'oublié les règles d'accent tonique, il pourrait rapidement se rafraichir la mémoire en lisant une page web qui traite du sujet (dont dont le lien serait donné sur notre site, à côté de la liste de mots ou du anki minimal de notre site). Ensuite il pourrait repartir de zéro (donc au niveau du vocabulaire, pas de la prononciation), et travailler à partir du *.anki minimal.
Sorbus a écritDans ce cas, pourquoi ne pas stocker tous les dicos au format texte... si on met à la disposition des utilisateurs des outils simples pour les convertir facilement et rapidement aux formats qu'ils désirent ?
C'est compliqué. Quelques problèmes se posent:
- si le dictionnaire *.tab voit son formatage modifié (ajout de numéros pour les définitions multiples, ajout de vrais tabulations supplémentaires à chaque ligne au lieu des «\t»), la taille d'un dictionnaire peut doubler. Et pour des dictionnaires de 20 Mo, c'est 20 Mo supplémentaires de griller. Avec SVN, si l'on revient en arrière, les 20 Mo ne sont pas libérés pour autant. La taille d'un dépôt SVN ne cesse d'augmenter. Il ne diminue que lorsqu'on le supprime entièrement.
- simple, je en sais pas. Les outils simples de conversions du format *.tab au *.dict passe tout de même par l'installation du paquet stardict-tools et l'utilisation de stardict-editor ou de /usr/lib/stardict-tools/tabfile. C'est limite pour un simple utilisateur.
Sorbus a écritTout à fait. On peut améliorer ou compléter des dictionnaires existants, parfois même seulement en corriger coquilles et fautes... D'où l'intérêt de disposer d'un moyen de suivi des versions.
Corriger des fautes? Est-ce que si un auteur maintient encore le dictionnaire de son côté, cela ne revient pas à créer un fork? Si le dictionnaire n'est plus maintenu, pourquoi pas. Mais est-ce qu'il ne faudrait pas créer en parallèle un logiciel pour construire et faire évoluer un dictionnaire (et moins de passer par l'ancien outil qui a permis de le créer et d'assurer le compatibilité avec le dépôt svn avec de simples scripts). Car certains auteurs potentiels de dictionnaires pourraient être alergiques aux éditeurs de texte. (q)stardict pourrait permettre l'ajout et la modification de mots ou définitions. Le *.dict ne serait pas modifié. Un fichier texte à part répertorierait les modifications apportées au dictionnaire (et en tiendrait compte au moment d'afficher les définitions juste après avoir reçu les informations du *.dict). Je manque de recul sur le sujet.
