En grattant un peu plus, c'est effectivement ce que j'ai cru comprendre. Voilà un point de régler! Merci.Et puis un jour quelqu'un m'a mis sous le nez le fait que cette licence était inexploitable pour la simple raison qu'elle était incompatible, notamment, avec la GPL, la politique de Debian, etc. Autrement dit, inexploitable pour n'importe quel projet libre. La raison? La clause non-commerciale interdirait par exemple à Debian de vendre des CDs de leur distro à prix coûtant si les données y étaient inclues. Du coup nous sommes rapidement passés à une CC 3.0 Share Alike, qui propose virtuellement la même guarantie : les produits dérivés doivent être livrés sous une licence compatible, guarantissant que personne ne peut fermer les données et se les approprier, tout en laissant l'opportunité de faire des logiciels commerciaux pourvu qu'ils restent ouverts dans leurs contributions.
On est d'accord sur ce point. J'étais plus ou moins balancé suite à vos différentes remarques et dernier post m'a convaincuC'est pour cela que j'insiste sur le fait que le moteur du dictionnaire est une préoccupation totalement orthogonale à la contruction de la base de données qu'il utilisera. Attention à ne pas courir deux lièvres à la fois ; c'est très difficile de faire un bon logiciel de dictionnaire, c'est très difficile de réunir des données de qualité. Faire les deux en même temps relève du miracle.
Là encore l'exemple du JMdict est révélateur : le dictionnaire officiel est pourri, par contre les sites alternatifs utilisant ces même données rencontrent un meilleur succès.
Techniquement, le boulot n'est pas monstrueux pour effectuer cette "légère" réorientation. Il va juste falloir venir plugger les données JMDict à mon modèle de données (ie: le site tourne sous Drupal et une entrée étant un node).
Après, il y aura sans doute quelques modifications pour internationaliser JMDict pour coller aux spécificités du français (et autres langues). Par exemple une chose que j'ai oublié sur Openjisho c'est de gérer le cas des adjectifs et noms ayant une forme masculine et féminine. Par exemple 白い → blanc, blanche. La plupart des dictionnaires ne propose que blanc. Pour un français cela ne pose pas réellement de problème mais pour un japonais il peut être intéressant d'avoir les 2 traductions. L'idéal est même de ne pas avoir 2 traductions mais qu'une traduction puisse avoir une forme masculine et féminine. Je ne pense pas que JMDict supporte ce genre de chose?
C'est avantage mais également un inconvénient car tu te retrouves avec un temps de latence pour récupérer les nouvelles données. (On est d'accord que ce n'est pas non plus bloquantTa dernière proposition est à mon avis exactement ce qu'il faut faire. Tu as des entrées du JMdict, identifiées par un numéro unique. A côté tu as les phrases d'exemple de Tatoeba, identifiées par un numéro unique. Il suffit juste de connecter les deux. Pour l'API, tu n'en as même pas besoin vu que tu peux importer les données de Tatoeba dans ton projet. Ne pas aller dans cette direction, ce serait un peu comme faire reconstruire ta maison à côté de l'ancienne sous prétexte que tu as perdu les clés, parce qu'il ne t'es pas venu à l'esprit qu'il suffirait de changer la serrure.)
Comment opères-tu pour mettre à jour tes données sur Tagaini? Le soft récupères tous les x jours la base JMDict et l'importe?
Il serait également envisageable d'utiliser ces données dans Openjisho?Jim était déjà ouvert pour intégrer les contribs de Transifex dans son JMdict - si ton projet va dans la même direction, je suis prêt à l'appuyer pour qu'il en prenne la place et t'aider dans la limite (très limitée) de mon temps disponible. Et il semble également que d'autres membres du site soient prêts à contribuer.
Répondre en citant
Envoyé par Renaud
