PDA

Afficher la version complète : Dictionnaire de Japonais - Openjisho - le Japonais pour vous, par vous



Pages : [1] 2

Azel
21/07/2012, 10h16
Bonjour, je vous présente aujourd'hui un tout nouveau site, un nouveau compagnon pour l'apprentissage du Japonais: Openjisho (http://www.openjisho.com)

Derrière ce nom se «cache» un dictionnaire[jisho] collaboratif[open] ; c'est à dire une plateforme type wikipedia, où vous, utilisateur, êtes à la fois consommateur et contributeur du site.

Le dictionnaire est architecturé autour de la langue japonaise. Une entrée dans le dictionnaire correspond à un mot japonais + sa(ses) traduction(s) dans différentes langues. Actuellement le site est en beta publique et supporte uniquement les traductions françaises mais d'autres langues viendront compléter le site prochainement.

Coté technique, on est face à une plate-forme novatrice et multilingue, basée sur un moteur d'indexation puissant, capable de bâtir tout un maillage entre les mots, de créer des connexions suivant l'orthographe, le sens, etc. afin de fournir des résultats de recherche précis et surtout pertinents.

Maintenant pour bâtir un dictionnaire de qualité nous avons besoin de vous, de votre contribution. Si chacun apporte sa pierre à l’édifice, petite ou grosse, on devrait réussir à faire quelque chose de chouette. J’ai confiance!

Allez ça comme par là: http://www.openjisho.com/user/register

Gnurou
22/07/2012, 05h49
Cool idée qui rappelle dictionnaire-japonais, j'espère qu'elle ira plus loin en évitant de buter sur les mêmes écueils.

En fait quelques questions me viennent à l'esprit concernant ce projet:
1) quelle est la licence des données contribuées?
2) le dictionnaire est-il utilisable uniquement sur le site, ou ses données sont-elles téléchargeables afin d'être utilisées ailleurs à l'image du JMdict?
3) pourquoi ne pas partir de la base conséquence fournie par le JMdict au lieu de recommencer à zéro?

Plutôt qu'un nième dictionnaire en ligne, je verrai bien un projet dans le style tatoeba qui fournisse les entrées en japonais (extraites par exemple du JMdict qui est très complet) et permettre d'éditer/ajouter une traduction dans différentes langues. Le résultat resterait compatible avec le JMdict et pourrait ainsi y être facilement réintroduit pour maximiser la diffusion du travail des contributeurs. J'avais commencé un effort dans ce sens-là sur Transifex, mais un site avec une interface dédiée (comme tatoeba) serait bien plus approprié pour ce genre de travail.

christian
22/07/2012, 09h52
Ouaih, un peu comme "http://www.dictionnaire-japonais.com/"... Super idée, mais chacun voulant sa propre version du dico collaboratif, cela devient antiproductif avec l'idée d'origine... Si vous repreniez des bases communes ce serait sympa au lieu de présenter continuellement des nouveaux sites... En tant qu'utilisateur, je ne me vois pas collaborer à un puis un autre et ainsi de suite...

Sinon bon courage pour la suite...

zev
22/07/2012, 10h07
Pourquoi pas un truc du genre http://www.alc.co.jp/ ? :)
Exemple:
http://eow.alc.co.jp/search?q=dictionary&ref=sa

avec des tournures et des textes techniques

Gnurou
22/07/2012, 12h21
Ouaih, un peu comme "http://www.dictionnaire-japonais.com/"... Super idée, mais chacun voulant sa propre version du dico collaboratif, cela devient antiproductif avec l'idée d'origine... Si vous repreniez des bases communes ce serait sympa au lieu de présenter continuellement des nouveaux sites... En tant qu'utilisateur, je ne me vois pas collaborer à un puis un autre et ainsi de suite...
C'est un peu mon sentiment également. Un dictionnaire japonais multilingue manque cruellement - mais plutôt que de réinventer la roue à chaque fois, il serait AMHA bien plus judicieux de capitaliser sur le JMdict, qui bien qu'étant à la base un dictionnaire japonais/anglais est déjà partiellement traduit dans d'autres langues (dont environ 16000 entrées en français). Pourquoi perdre du temps à retraduire tout cela?

Par ailleurs, les entrées japonaises du JMdict fourniraient un squelette complet et cohérent, avec tous les indices sémantiques nécessaires (un dictionnaire ne se limite pas à la traduction d'une langue à une autre, il faut également connaître le genre d'un mot, de type d'un verbe, etc.), et la traduction anglaise fournirait un "guide" pour la définition française. De plus en respectant le format du JMdict (voire en y contribuant les entrées traduites), le projet assurerait que les efforts des contributeurs sont utilisés dans un maximum de sites et de logiciels. Si je veux chercher une définition, j'irai sur jisho.org plutôt qu'ailleurs - autant faire en sorte qu'une traduction française y soit également visible.

J'adorerai voir un projet inspiré de Tatoeba pour l'interface visant à internationaliser le JMdict - là je suis sûr de son succès. Mais je ne vois pas comment un nouveau dictionnaire partant de zéro pourrait constituer une contribution significative, surtout s'il n'est accessible qu'à partir d'un unique site.

Just my 2c. Mais si le projet partait dans cette direction, j'abandonnerai joyeusement mon propre travail sur Transifex pour transférer les maigres ressources que je peux allouer sur ce nouveau projet.

zev
22/07/2012, 12h42
Ah tiens, je connaissais pas tatoeba ;)

Pour moi la reference pro/technique c'est alc, c'est dommage qu'il soit avant tout destine a des japonais (pas d'interface anglaise)

Parker
23/07/2012, 21h43
C'est un peu mon sentiment également. Un dictionnaire japonais multilingue manque cruellement - mais plutôt que de réinventer la roue à chaque fois, il serait AMHA bien plus judicieux de capitaliser sur le JMdict, qui bien qu'étant à la base un dictionnaire japonais/anglais est déjà partiellement traduit dans d'autres langues (dont environ 16000 entrées en français). Pourquoi perdre du temps à retraduire tout cela?

Par ailleurs, les entrées japonaises du JMdict fourniraient un squelette complet et cohérent, avec tous les indices sémantiques nécessaires (un dictionnaire ne se limite pas à la traduction d'une langue à une autre, il faut également connaître le genre d'un mot, de type d'un verbe, etc.), et la traduction anglaise fournirait un "guide" pour la définition française. De plus en respectant le format du JMdict (voire en y contribuant les entrées traduites), le projet assurerait que les efforts des contributeurs sont utilisés dans un maximum de sites et de logiciels. Si je veux chercher une définition, j'irai sur jisho.org plutôt qu'ailleurs - autant faire en sorte qu'une traduction française y soit également visible.

J'adorerai voir un projet inspiré de Tatoeba pour l'interface visant à internationaliser le JMdict - là je suis sûr de son succès. Mais je ne vois pas comment un nouveau dictionnaire partant de zéro pourrait constituer une contribution significative, surtout s'il n'est accessible qu'à partir d'un unique site.

Just my 2c. Mais si le projet partait dans cette direction, j'abandonnerai joyeusement mon propre travail sur Transifex pour transférer les maigres ressources que je peux allouer sur ce nouveau projet.

Tout à fait d'accord. Moi aussi j'abandonnerai mes (encore maigres) contributions sur Transifex à condition que l'on se préoccupe de trois choses :

- la licence d'utilisation (c'est en étant vraiment libre qu'on peut s'assurer d'une diffusion large. Il faut aussi accepter les forks et jouer sur l'ouverture des formats : d'où la nécessité de permettre le téléchargement de la base pour inclusion dans d'autres produits)
- la structure du dictionnaire et notamment la possibilité d'inclure des exemples. C'est grâce aux phrases d'exemple que l'on peut vraiment saisir le sens d'un mot. Tenter d'inclure tous les sens (à la JMDict) sans contexte en fait un fait un outil peu utile.
- bien calibrer le niveau de langage et la fréquence des entrées : Encore une fois, le JMDict passe à côté en utilisant des lectures rares, voire rarissimes pour des mots courants, ou encore des mots rarement employés et aussi rarement connus des natifs. L'absence d'exemple renforce cette confusion.

Bref, si un si mauvais outil que le JMDict (si,si, j'insiste) se retrouve partout et même dans Tagaini, c'est quand même grâce à sa licence.

Repartir de sa base en le mariant avec des phrases d'exemple ? Pourquoi pas ? Mais il faudrait aussi le dévéroler de toutes ces références oiseuses (sérieusement : qui écrit とても en kanji ?). C'étaient mes deux cents à moi. D'autres veulent-ils contribuer au magot ?

Gnurou
25/07/2012, 03h16
- la licence d'utilisation (c'est en étant vraiment libre qu'on peut s'assurer d'une diffusion large. Il faut aussi accepter les forks et jouer sur l'ouverture des formats : d'où la nécessité de permettre le téléchargement de la base pour inclusion dans d'autres produits)
+1000


- la structure du dictionnaire et notamment la possibilité d'inclure des exemples. C'est grâce aux phrases d'exemple que l'on peut vraiment saisir le sens d'un mot. Tenter d'inclure tous les sens (à la JMDict) sans contexte en fait un fait un outil peu utile.
Tatoeba est bourré de phrases d'exemple avec leur traduction, c'est vrai que si on pouvait lier les sens à des phrases directement, cela serait extra. Peut-être en créant une extension au JMdict?


- bien calibrer le niveau de langage et la fréquence des entrées : Encore une fois, le JMDict passe à côté en utilisant des lectures rares, voire rarissimes pour des mots courants, ou encore des mots rarement employés et aussi rarement connus des natifs. L'absence d'exemple renforce cette confusion.
JMdict est volontairement très exhaustif concernant les lectures et les kanji employés, mais les cas rares et les sens obsolètes sont signalés par les tags uk (usually writting in kana) et arch (archaic). Le problème est que beaucoup de logiciels ne s'en servent pas (Tagaini essaie autant que possible mais là aussi les choses ne sont sans doute pas parfaites).

Je te trouve un peu dur avec le JMdict, mais suis totalement d'accord avec ton analyse. La collecte des données et leur utilisation sont deux préoccupations orthogonales, et l'ouverture des formats est essentielle. Il serait intéressant d'avoir le commentaire d'Azel à ce sujet.

Azel
25/07/2012, 14h08
Merci pour vos retours. Ça fait plaisir de voir que mon post génère quelques réactions.
Je réponds un peu tardivement, je m'excuse j'étais absent durant quelques jours.


Je vais essayer de résumer et répondre à l'ensemble des questions.


Utilisation et exploitation des données:
Pour bien clarifier les choses, le dictionnaire sera complètement ouvert, le nom OPEN est bien là pour quelque chose.
Pour le moment rien n'est mentionné sur le site, mais cela fait partir des top priorité de ma todo liste. Je traîne un peu sur ce point car je suis encore incertain quant à la licence à mettre en place. Je compte partir sur du Creative Commons 3.0 mais je ne sais pas s'il est intéressant d'intégrer la clause "Noncommercial — You may not use this work for commercial purposes". Vous en pensez quoi?
Qui dit OPEN, dit également exportable ; sous différents formats et différents types (full, lite, par langue, etc.). Cela fait également parti des todos et des fonctionnalités indispensables à la réussite du dictionnaire.


Motivations et raisons derrières Openjisho:
La première et la principale est que je ne suis pas satisfait par les dictionnaires existants. Moteur de recherche obsolète, des réponses douteuses ou inappropriées (comme le souligne justement Parker), ergonomie, etc. Le seul à ma connaissance qui sort du lot est jisho.org, mais il ne propose malheureusement que l'anglais.
Deuxièmement, l'absence de dictionnaire en ligne Français/Japonais. Le site dictionnaire-japonais.com a connu une longue période de vide, et c'est justement à ce moment là que je me suis lancé sur Openjisho. Le dictionnaire a fait peau neuve depuis, une appli mobile à vu le jour, mais il ne corrige pas ses lacunes du passé:
Dictionnaire fermé
Résultats de recherche beaucoup trop approximatif ; faites une recherche sur «maison» par exemple, vous allez obtenir une 50aine de résultats et avant de trouver 家, il faut scroller un peu.


From scratch vs JMDict:
A l'origine j'avais la même opinion que Parker sur JMDict ; des lectures rares, des mots anciens qui ne sont plus employés de nos jours, etc. Mais le plus gros problème dans tout ça c'est l'absence de mécanisme pour trier les entrées et proposer des résultats pertinents (voir remarque dans le paragraphe précédent).
Donc plutôt que faire une passe de nettoyage sur JMDict, j'ai opté pour l'option from scratch. Mais suite aux remarques de Gnurou, je suis un peu plus mitigé maintenant :) Le débat est ouvert!?


Évolutions à venir:
Intégrer de nouvelles langues ; l'anglais en priorité bien entendu
Ajouter des exemples aux traductions (tout bonnement indispensable). Je n'ai pas encore une vision claire de cette fonctionnalité.
Opter pour une solution simple, consistant à étendre les données d'un mot, en rajoutant des exemples. Un mot aurait ainsi 0 à n exemple(s)?
Ou mettre en place un système plus avancé, détaché des mots. Les exemples serait ajoutés indépendamment et les contributeurs pourraient ensuite rattacher un ou plusieurs exemples à un mot. Peut être venir se connecter à Tatoeba? Il propose une API ouverte?

Gnurou
25/07/2012, 16h06
Utilisation et exploitation des données:
Pour bien clarifier les choses, le dictionnaire sera complètement ouvert, le nom OPEN est bien là pour quelque chose.
Pour le moment rien n'est mentionné sur le site, mais cela fait partir des top priorité de ma todo liste. Je traîne un peu sur ce point car je suis encore incertain quant à la licence à mettre en place. Je compte partir sur du Creative Commons 3.0 mais je ne sais pas s'il est intéressant d'intégrer la clause "Noncommercial — You may not use this work for commercial purposes". Vous en pensez quoi?
J'ai un petit retour d'expérience à ce sujet. Il y a 4 ans et après moults effort, j'ai réussi à faire libérer KanjiVG (une base de données d'informations de compositions pour 6000 kanji avec leur tracé dans l'ordre au format SVG) qui était alors un projet universitaire non-accessible. L'un des arguments qui avait convaincu l'ayant-droit était la licence que j'avais proposé: Creative Common 3.0 Non Commercial Share Alike. Nous étions tombés d'accord sur cette licence et tout se passait bien.

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.


Qui dit OPEN, dit également exportable ; sous différents formats et différents types (full, lite, par langue, etc.). Cela fait également parti des todos et des fonctionnalités indispensables à la réussite du dictionnaire.
C'est en effet un point essentiel et je suis ravi de ta réponse. ;)



Motivations et raisons derrières Openjisho:
La première et la principale est que je ne suis pas satisfait par les dictionnaires existants. Moteur de recherche obsolète, des réponses douteuses ou inappropriées (comme le souligne justement Parker), ergonomie, etc. Le seul à ma connaissance qui sort du lot est jisho.org, mais il ne propose malheureusement que l'anglais.
Pour info, jisho.org est basé (comme tout le monde d'ailleurs) sur le combo JMdict/kanjidic2/KanjiVG/Tatoeba. Comme quoi les même données utilisées differemment donnent des résultats très différents. ;)

C'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.


Deuxièmement, l'absence de dictionnaire en ligne Français/Japonais. Le site dictionnaire-japonais.com a connu une longue période de vide, et c'est justement à ce moment là que je me suis lancé sur Openjisho. Le dictionnaire a fait peau neuve depuis, une appli mobile à vu le jour, mais il ne corrige pas ses lacunes du passé:
Dictionnaire fermé
Résultats de recherche beaucoup trop approximatif ; faites une recherche sur «maison» par exemple, vous allez obtenir une 50aine de résultats et avant de trouver 家, il faut scroller un peu.
dictionnaire-japonais est totalement mort en ce qui me concerne, j'avais essayé de contacter son propriétaire pour faire un rapprochement avec le JMdict mais rien de concret n'est jamais sorti.


From scratch vs JMDict:
A l'origine j'avais la même opinion que Parker sur JMDict ; des lectures rares, des mots anciens qui ne sont plus employés de nos jours, etc. Mais le plus gros problème dans tout ça c'est l'absence de mécanisme pour trier les entrées et proposer des résultats pertinents (voir remarque dans le paragraphe précédent).
Cela fait maintenant 5 ans que je programme sur le JMdict et son format, et crois-moi, il n'y a vraiment pas grand chose à lui reprocher en dehors du fait qu'il est trop complet et bien pensé, et que ceux qui s'en servent pour leurs softs n'y ont rien compris.

JMdict se fait souvent taper dessus, mais le seul problème, c'est que ceux qui écrivent des logiciels l'utilisant sont des tanches. Pour reprendre l'exemple de とても qu'a avancé Parker, j'ai attaché le résultat de la recherche faite sur ce mot avec Tagaini : l'écriture en hiragana apparaît bien comme l'écriture principale, et celle en kanji comme une écriture alternative. JMdict contient l'information que cette écriture n'est plus à l'ordre du jour ; seulement très peu de logiciels s'en servent et préfèrent juste afficher la première écriture en kanji qui passe. L'intérêt d'avoir cette écriture est que tu peux parfaitement vouloir faire une recherche sur un vieux livre utilisant cette écriture obsolète, et que tu auras alors le bon résultat ; mais la mettre en avant est une erreur.
2878

Jisho.org se plante d'ailleurs royalement sur cette entrée ; mais de toute façon je le soupçonne d'être surtout un moyen pour son auteur d'afficher des bannières de pub.


Donc plutôt que faire une passe de nettoyage sur JMDict, j'ai opté pour l'option from scratch. Mais suite aux remarques de Gnurou, je suis un peu plus mitigé maintenant :) Le débat est ouvert!?
Ben, c'est juste que si tu fais un petit calcul : il a fallu plus de 15 ans à Jim Breen et une équipe relativement large d'experts anglophones du japonais (potentiel plus important que les francophones donc) pour élaborer ce dictionnaire de 150.000 entrées, les classer par type, champ lexical, grouper les sens d'un même mot, et proposer un format suffisamment riche pour exporter toute cette information. Ce serait de la folie AMHA de ne pas tirer avantage de ce travail et du "squelette" que propose la partie japonaise du JMdict, déjà complète avec toutes les variante, écritures, et classifications. Je ne sais pas si tu te rend compte du travail énorme dont il s'agit. Combien de millier d'années penses-tu qu'il faudra à une poignée de francophones non-universitaires pour arriver au même résultat?

Aussi, je vois très mal comment un projet "concurrent" pourra se faire de la lumière, étant donné que même la base francophone est déjà bien amorcée. Le seul souci qui fait que JMdict ne s'internationalise pas plus, c'est qu'il n'y a aucun moyen efficace de contribuer des traductions dans des langues autres que l'anglais. Voyant ce trou, mais manquant de temps pour faire un projet complet, j'ai bricolé un truc rapide en exploitant Transifex pour faire des traductions, mais c'est loin d'être idéal. Je rêve de voir un site qui serait basé sur le même modèle que Tatoeba et qui permettrait de traduire les entrées du JMdict dans toutes les langues pour ensuite les contribuer au projet d'origine et s'assurer de leur diffusion maximale. C'est le seul moyen d'avoir, à terme, une version française de jisho.org par exemple.


Évolutions à venir:
Intégrer de nouvelles langues ; l'anglais en priorité bien entendu
Ajouter des exemples aux traductions (tout bonnement indispensable). Je n'ai pas encore une vision claire de cette fonctionnalité.
Opter pour une solution simple, consistant à étendre les données d'un mot, en rajoutant des exemples. Un mot aurait ainsi 0 à n exemple(s)?
Ou mettre en place un système plus avancé, détaché des mots. Les exemples serait ajoutés indépendamment et les contributeurs pourraient ensuite rattacher un ou plusieurs exemples à un mot. Peut être venir se connecter à Tatoeba? Il propose une API ouverte?
Ta 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.

L'avantage étant qu'en faisant ainsi tu tireras parti des additions faits aux deux projets. Une phrase d'exemple de Tatoeba que tu références vient de recevoir une traduction en Allemand? Bam, tu viens de gagner la phrase pour la version allemande de ton dico gratuitement. Par contre, commencer un corpus par toi même, hum... Tu as une armée d'un millier de natifs dans les différentes langues que tu veux supporter pour te faire cela?

Je sais qu'il est moins excitant et moins glorieux de connecter et compléter des projets existants que de faire le sien from scratch. Mais il faut aussi regarder les moyens et les compétences que l'on a. Il sera très difficile de trouver suffisamment d'experts francophones en japonais pour construire un dictionnaire fiable. En revanche, il y a beaucoup plus de gens assez familiers avec le japonais et l'anglais pour fournir une traduction française correcte à partir de ces deux langues. Construire un corpus de phrases d'exemple représente un travail impossible à réaliser pour une poignée de personnes. Mais connecter un corpus existant avec un dictionnaire existant est déjà beaucoup moins effrayant.

Si tu as les compétences et le temps pour faire un projet similaire à Tatoeba et gérant la traduction du JMdict dans d'autres langues + la connexion avec le corpus de Tatoeba, je crois que tu auras une chance de mettre ton nom sur un projet extrêmement utile pour la communauté et qui rencontrera à coup sûr le succès. 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.

So, just do it! ;)

Azel
25/07/2012, 17h15
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.

En grattant un peu plus, c'est effectivement ce que j'ai cru comprendre. Voilà un point de régler! Merci.


C'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.

On est d'accord sur ce point. J'étais plus ou moins balancé suite à vos différentes remarques et dernier post m'a convaincu :)
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?


Ta 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.

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 bloquant :))
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?


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 :wink:) de mon temps disponible. Et il semble également que d'autres membres du site soient prêts à contribuer.

Il serait également envisageable d'utiliser ces données dans Openjisho?

Azel
25/07/2012, 21h30
Aparté - Il manque définitivement une vraie doc. pour JMDict :)

Renaud
25/07/2012, 22h31
(Non, pas "définitivement" mais assurément. Grrr. À part ça, bon courage pour l'entreprise ;))

Azel
25/07/2012, 22h56
(Non, pas "définitivement" mais assurément. Grrr. À part ça, bon courage pour l'entreprise ;))

C'est peut être l'occasion de proposer/réaliser quelque chose :D
Rien qu'une version propre et claire du DTD

Azel
26/07/2012, 10h37
Par ailleurs, les entrées japonaises du JMdict fourniraient un squelette complet et cohérent, avec tous les indices sémantiques nécessaires (un dictionnaire ne se limite pas à la traduction d'une langue à une autre, il faut également connaître le genre d'un mot, de type d'un verbe, etc.), et la traduction anglaise fournirait un "guide" pour la définition française. De plus en respectant le format du JMdict (voire en y contribuant les entrées traduites), le projet assurerait que les efforts des contributeurs sont utilisés dans un maximum de sites et de logiciels. Si je veux chercher une définition, j'irai sur jisho.org plutôt qu'ailleurs - autant faire en sorte qu'une traduction française y soit également visible.

Par contre les indices sémantiques se limitent uniquement à la version anglaise, c'est un peu dommage, il faudrait également ces informations sur les gloss... par exemple 自転車→vélo (nm) , bicyclette(nf)

Gnurou
26/07/2012, 10h53
On est d'accord sur ce point. J'étais plus ou moins balancé suite à vos différentes remarques et dernier post m'a convaincu :)
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).
Et aussi t'assurer que tu puisses mettre à jour ton modèle à partir des nouvelles versions du JMdict, en prenant en compte certaines subtilités comme le fait que les sens d'une entrée sont réordonnés. C'est loin d'être trivial, mais pas impossible non plus.


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?
Non, mais en ayant deux gloss sur le même sens, tu auras l'effet désiré. Ce moyen est déjà employé dans le JMdict actuel.


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 bloquant :))
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?
Non, les données sont téléchargées à la compilation et restent donc fixes pour une version donnée. Ceci pour éviter les problèmes liés à d'éventuelles évolutions du format de ces dernières. Et me forcer à sortir une nouvelle version de temps en temps. ;)


Il serait également envisageable d'utiliser ces données dans Openjisho?
Bien entendu - soit elles seront déjà fusionnées dans le JMdict et ce sera automatique, soit ce ne sera pas le cas et je te refile le tout.


Par contre les indices sémantiques se limitent uniquement à la version anglaise, c'est un peu dommage, il faudrait également ces informations sur les gloss... par exemple 自転車→vélo (nm) , bicyclette(nf)
Je suppose que tu voulais dire qu'ils se limitent à la version japonaise. C'est normal, vu que JMdict est un dictionnaire de japonais - les traductions n'ont pas à avoir d'indices sémantiques.

Azel
26/07/2012, 11h09
Non, mais en ayant deux gloss sur le même sens, tu auras l'effet désiré. Ce moyen est déjà employé dans le JMdict actuel.

Il faudra faire avec :)


Je suppose que tu voulais dire qu'ils se limitent à la version japonaise. C'est normal, vu que JMdict est un dictionnaire de japonais - les traductions n'ont pas à avoir d'indices sémantiques.

Oui pardon. Effectivement, JMDict est un dictionnaire de japonais ça semble logique. Par contre dans ma vision d'Openjisho je voyais plutôt quelque chose qui va dans les 2 sens ; langue(s) étrangère(s)/japonais et japonais/langue(s) étrangère(s). Je me place dans la peau d'un utilisateur japonais, il est intéressant (et utile) d'avoir des indices sémantiques sur la traduction d'un mot japonais. Principalement avec le français sur le genre.


Bon voilà une bonne base de départ. Je vais pouvoir attaquer le boulot :)
J'espère pouvoir mettre en ligne une nouvelle version d'Openjisho prochainement. Si des personnes sont intéressées je peux vous rajouter au projet. Le projet est versionné sous GIT (via bitbucket).

J'ai mis en place une petite lib PHP également qui permet de travailler avec la langue japonaise. Elle propose rien de révolutionnaire mais elle centralise des fonctionnalités utiles: https://github.com/mbilbille/jpnforphp
Ainsi que le module permettant la lib dans Drupal : http://drupal.org/sandbox/mbilbille/1613510

Gnurou
26/07/2012, 11h35
Oui pardon. Effectivement, JMDict est un dictionnaire de japonais ça semble logique. Par contre dans ma vision d'Openjisho je voyais plutôt quelque chose qui va dans les 2 sens ; langue(s) étrangère(s)/japonais et japonais/langue(s) étrangère(s). Je me place dans la peau d'un utilisateur japonais, il est intéressant (et utile) d'avoir des indices sémantiques sur la traduction d'un mot japonais. Principalement avec le français sur le genre.
Un dictionnaire bidirectionnel (ou dans ce cas, multi-directionnel) est quelque chose de très difficile (impossible?) à réaliser correctement. La raison est que la couverture sémantique des mots n'est pas équivalente dans les différentes langues. Un exemple avec 許す: c'est un mot en japonais, mais en français il prendra deux concepts: autoriser et pardonner. De la même manière un mot français peut couvrir (complètement ou partiellement) plusieurs concepts en japonais. C'est pour cela que les dictionnaires sont uni-directionnels et que l'utilisateur du JMdict n'est pas un japonais qui cherche à apprendre l'anglais ou le français, mais bien l'étudiant ou l'académique non-japonisant. Se mettre dans la peau d'un utilisateur japonais est ici hors-sujet.


Bon voilà une bonne base de départ. Je vais pouvoir attaquer le boulot :)
J'espère pouvoir mettre en ligne une nouvelle version d'Openjisho prochainement. Si des personnes sont intéressées je peux vous rajouter au projet. Le projet est versionné sous GIT (via bitbucket).
Git, cool! :) Tu comptes tout gérer en PHP ou passer par des languages plus adaptés au traitement de données (genre Python) pour la partie non-web?

Azel
26/07/2012, 11h46
Un dictionnaire bidirectionnel (ou dans ce cas, multi-directionnel) est quelque chose de très difficile (impossible?) à réaliser correctement. La raison est que la couverture sémantique des mots n'est pas équivalente dans les différentes langues. Un exemple avec 許す: c'est un mot en japonais, mais en français il prendra deux concepts: autoriser et pardonner. De la même manière un mot français peut couvrir (complètement ou partiellement) plusieurs concepts en japonais. C'est pour cela que les dictionnaires sont uni-directionnels et que l'utilisateur du JMdict n'est pas un japonais qui cherche à apprendre l'anglais ou le français, mais bien l'étudiant ou l'académique non-japonisant. Se mettre dans la peau d'un utilisateur japonais est ici hors-sujet.

Peut-être pas pousser le multi-directionnel à 100% mais au minimum proposer le même niveau de détails que sur la version actuelle d'Openjisho: http://www.openjisho.com/en/jidensha/7 (pour rester dans le vélo :))



Git, cool! :) Tu comptes tout gérer en PHP ou passer par des languages plus adaptés au traitement de données (genre Python) pour la partie non-web?
Le PHP n'est surement pas le language le plus adapté pour ce genre de traitement mais le site (front et back) repose sur Drupal, donc il me paraît plus simple de partir sur du 100% PHP pour profiter de toutes l'API Drupal.
Le traitement des données n'est pas non plus monstrueux. Il faut juste attaquer le fichier proprement car il est assez lourd :)

Parker
28/07/2012, 22h25
Un dictionnaire bidirectionnel (ou dans ce cas, multi-directionnel) est quelque chose de très difficile (impossible?) à réaliser correctement. La raison est que la couverture sémantique des mots n'est pas équivalente dans les différentes langues. Un exemple avec 許す: c'est un mot en japonais, mais en français il prendra deux concepts: autoriser et pardonner. De la même manière un mot français peut couvrir (complètement ou partiellement) plusieurs concepts en japonais. C'est pour cela que les dictionnaires sont uni-directionnels et que l'utilisateur du JMdict n'est pas un japonais qui cherche à apprendre l'anglais ou le français, mais bien l'étudiant ou l'académique non-japonisant. Se mettre dans la peau d'un utilisateur japonais est ici hors-sujet.

+1000 !

L'écueil le plus important de ce type de projet est l'excès d'ambition (on l'a tous). Un (bon) dictionnaire multi-directionnel est très difficile à réaliser et probablement impossible si on mixe plus de deux langues.

@Azel
je n'ai pas consulté le blog pendant qq jours mais je note que Gnurou t'a apporté les bons conseils, notamment pour la licence (je suis toujours surpris par cette obsession pour le non-commercial. Que serait devenu Linux si Torvald avait eu la même approche ?...).

@Gnurou
Je n'ai pas ton expérience concernant JMDict et tu as raison, mon aversion (un peu malsaine, hein, parce que je continue à l'utiliser) au JMDict vient probablement de la mauvaise utilisation qu'en font les différents logiciels qui y ont recours (tous ?).
Mon reproche principal vient de la volonté sous-jacente des contributeurs à en faire un outil exhaustif alors que beaucoup d'entrées ne trouvent leur sens qu'à la lecture d'un exemple. Et pour la nuance entre différents termes, il faut repasser.
Le moyen que j'ai trouvé de rendre cet outil utilisable est le recours à des listes (mais encore faut-il les constituer). Car, ce n'est pas simplement un problème de mots/écritures obsolètes que celui de mots réellement utilisés par des natifs. Faites le test auprès de vos amis japonais. Je ne fréquente pas que des linguistes !
Repartir du JMDict présente l'avantage de pouvoir construire beaucoup plus rapidement une base conséquente en français car on peut alors s'appuyer sur des japonisants débutants qui parlent anglais (voire même pas japonisant du tout !). Cela dit, Transifex reste un peu rigide (obligation d'avoir des parenthèses en français quand elles existent dans la version anglaise, interdiction d'en créer sinon) alors que la plupart des mots ne peuvent se contenter d'une traduction directe. mais je te suis reconnaissant de l'initiative.


Enfin, même si cela dépasse le cadre de ce post (car on est quand même partis sur l'idée d'un dictionnaire), je reste convaincu que le recours à des phrases exemples reste le meilleur moyen d'acquérir une langue. C'est pourquoi je suis beaucoup plus impressionné par un projet comme Tatoeba que par le JMDict et les 15 années de contribution d'universitaires. Je reconnais toutefois que c'est un peu cracher dans la soupe ;).

Akeru
29/07/2012, 09h46
Erf, je ne découvre ce sujet que sur le tard. Pratiquement tout à été dit et correspond aussi à ce que je pense d'un tel projet. Je suis surtout d'accord avec Parker quand il dit que les phrases d'examples sont ce qu'il y a de plus efficace pour aborder une langue.

Bref, bon courage à toi Azel et écoutes tonton Gnurou, il est un peu sénile mais ne dit pas que des bêtises :-D

Ah autre chose, sympa la lib ! J'ai pratiquement la même pour mes propres projets :-)

Azel
29/07/2012, 15h42
L'écueil le plus important de ce type de projet est l'excès d'ambition (on l'a tous). Un (bon) dictionnaire multi-directionnel est très difficile à réaliser et probablement impossible si on mixe plus de deux langues.

J'ai déjà apporté ma réponse sur ce point ; il n'est pas question de faire un dictionnaire multidirectionnel, mais accompagner les traductions de quelques informations, comme le type et surtout le genre. C'est indispensable selon moi.


je n'ai pas consulté le blog pendant qq jours mais je note que Gnurou t'a apporté les bons conseils, notamment pour la licence (je suis toujours surpris par cette obsession pour le non-commercial. Que serait devenu Linux si Torvald avait eu la même approche ?...).

Aucune obsession, une simple réflexion :) Une fois la licence en place, je ne pourrais pas faire marche arrière.


Enfin, même si cela dépasse le cadre de ce post (car on est quand même partis sur l'idée d'un dictionnaire), je reste convaincu que le recours à des phrases exemples reste le meilleur moyen d'acquérir une langue. C'est pourquoi je suis beaucoup plus impressionné par un projet comme Tatoeba que par le JMDict et les 15 années de contribution d'universitaires. Je reconnais toutefois que c'est un peu cracher dans la soupe :wink:.

Plus que l'un ou l'autre des systémes, la solution est selon moi dans la fusion des deux. C'est sans doute pour cela que jisho.org a réussi à tirer son épingle du jeu (même si le dictionnaire est perfectible sur certains points).


Ah autre chose, sympa la lib ! J'ai pratiquement la même pour mes propres projets :smile:

Merci bien. Effectivement ça ne révolutionne rien mais je n'ai rien trouvé de tel. Je t'invite à contribuer si tu le souhaites :)

Akeru
29/07/2012, 22h29
Merci bien. Effectivement ça ne révolutionne rien mais je n'ai rien trouvé de tel. Je t'invite à contribuer si tu le souhaites :)

Pourquoi pas... En fait, je n'ai que deux fonctions que tu n'as pas (encore) :

une permettant de retirer le marquage RTL (http://en.wikipedia.org/wiki/Right-to-left_mark), trim ne le faisant pas
une autre qui enlève toutes forme d'accents : Kyōto devient donc Kyoto, Noël -> Noel, etc etc. J'ai vu une quantité infinie de solutions plus foireuses les unes que les autres... L'intérêt est de pouvoir faire des recherches dans une DB qui ne supporte pas complètement les "collations" (sqlite).

Si ça t'intéresse, je peux faire un pull request :-)

Azel
29/07/2012, 23h19
Si ça t'intéresse, je peux faire un pull request :-)

Volontiers! Si cette lib réussit à unifier tout ce qui fait autour de la langue japonaise, ça sera une petite victoire :-P

Akeru
30/07/2012, 09h45
Volontiers!

Ok, je fais ça prochainement et si j'ai d'autre fonctions à ajouter, je te préviendrai. (Par contre, le nom de la lib est un peu moche, faut dire que la mienne s'appelle Strings, pas sur que ça soit mieux :-p)


Si cette lib réussit à unifier tout ce qui fait autour de la langue japonaise, ça sera une petite victoire :-P

Ca me semble un peu ambitieux ça :-D

Azel
30/07/2012, 10h55
Ok, je fais ça prochainement et si j'ai d'autre fonctions à ajouter, je te préviendrai. (Par contre, le nom de la lib est un peu moche, faut dire que la mienne s'appelle Strings, pas sur que ça soit mieux :-p)

JpnForPhp non? J'y ai réfléchi au moins 5 minutes pourtant :D

Gnurou
30/07/2012, 11h49
Le PHP n'est surement pas le language le plus adapté pour ce genre de traitement mais le site (front et back) repose sur Drupal, donc il me paraît plus simple de partir sur du 100% PHP pour profiter de toutes l'API Drupal.
Même avec l'API Drupal je ne suis pas sûr que je voudrais traiter des données en PHP... Et en fait, la solution que tu utilises pour servir d'interface à l'utilisateur n'a pas besoin d'être la même que celle qui insère/exporte les données de ta base et qui les tient à jour. Car mine de rien tu auras quand même pas mal de choses à gérer.

La question de la pérennité se pose aussi, en faisant le choix de PHP/Drupal pour cette partie également, tu es sûr que tu ne changera jamais la solution du front-end (à moins de tout réécrire). Avoir quelque chose d'indépendant en back-end te laisse plus de liberté de ce côté-là aussi, des fois que l'illumination Python te touche un jour. ;)


J'ai déjà apporté ma réponse sur ce point ; il n'est pas question de faire un dictionnaire multidirectionnel, mais accompagner les traductions de quelques informations, comme le type et surtout le genre. C'est indispensable selon moi.
C'est à mon avis hors-sujet ici. Celui qui veut trouver le genre d'un mot français ira le chercher dans un dictionnaire de français. M'enfin si tu veux quand même faire cela, cela ne devrait pas poser de problème pour l'export JMdict, il suffira juste d'omettre cette information.

Ca me semble bien parti en tout cas, mais c'est maintenant qu'il faut prendre les bonnes décisions. Je crois que dans un premier temps tu peux essayer de regarder et comprendre la structure du JMdict et voir comment tu vas l'intégrer dans ton site. N'oublie pas qu'il te faudra gérer les choses suivantes:
1) Fusion des nouvelles versions: certaines entrées disparaissent, d'autres apparaisent, certaines fusionnent et enfin les differents de certaines changent d'ordre! comment faire pour ne pas (trop) perdre tes traductions?
2) Maintenance des données: qui est responsable de telle ou telle entrée? Si l'entrée d'origine du JMdict est modifiée, comment s'assurer que la traduction recevra l'éventuelle révision nécessaire? C'est là qu'un système de possession des entrées à la Tatoeba pourrait s'avérer judicieux.
3) Export des traductions dans un format utilisable par le JMdict pour leur intégration, Jim accepte un format très simple qui ne devrait pas poser de problème à créer.

Les points 1 et 3 peuvent se faire en dehors de PHP tout en gardant le site public sous Drupal. Ca dépend bien sûr de tes affinités, mais perso je n'ai jamais accroché à ce language (au passage, voici un article qui résume assez bien ce qui ne va pas avec: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ )

Akeru
30/07/2012, 12h35
JpnForPhp non? J'y ai réfléchi au moins 5 minutes pourtant :D

Waip, c'est ce que je dis :-) Pull request envoyée avec quelque bonus au passage :-D


Avoir quelque chose d'indépendant en back-end te laisse plus de liberté de ce côté-là aussi, des fois que l'illumination Python te touche un jour. ;)

Oui et non... Avec la même techno des deux côtés tu peux réutiliser tes composants (surtout les modèles du MVC et les accès db genre DAO)


perso je n'ai jamais accroché à ce language (au passage, voici un article qui résume assez bien ce qui ne va pas avec: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ )

Je dirais qu'il faut prendre cet article avec pas mal de recul : il y a du très vrai (Fatal errors (e.g., new ClassDoesntExist()) can’t be caught by anything, une catastrophe !) et du complètement stupide (Appending to an array is done with $foo[] = $bar.). Pour rétablir l'équilibre de la Force : http://news.ycombinator.com/item?id=4177516.

La vraie malédiction du PHP est le nombre d'idiots qui ont publiés de code infâme qui a ensuite été repris en l'état par d'autres idiots et ainsi de suite (sans compter la cacophonie de framework qui dilue l'effort et pourri l'écosystème).

Azel
30/07/2012, 15h05
Oui et non... Avec la même techno des deux côtés tu peux réutiliser tes composants (surtout les modèles du MVC et les accès db genre DAO)

Oui, c'est principalement pour cela que je préfère opter pour une solution 100% PHP. Drupal me fournit des outils pour gérer l'import mais surtout toutes les fonctionnalités pour sauvegarder les données dans son modèle (avec toutes les dépendances que ça implique). Après pourquoi Drupal? Pour la beauté du sport, mon p'tit challenge personel. (Je sais c'est nul et vous allez pas aimer :))
Et quant à PHP, là on entre dans un débat sans fin... PHP vs le reste du monde :)


Je crois que dans un premier temps tu peux essayer de regarder et comprendre la structure du JMdict et voir comment tu vas l'intégrer dans ton site. N'oublie pas qu'il te faudra gérer les choses suivantes:
1) Fusion des nouvelles versions: certaines entrées disparaissent, d'autres apparaisent, certaines fusionnent et enfin les differents de certaines changent d'ordre! comment faire pour ne pas (trop) perdre tes traductions?

Je suis à fond dessus actuellement, mais je bataille pour trouver les informations. Ca manque clairement de documentation, c'est dommage.
J'ai tout de même réussi à saisir le modèle de données et je suis en train de créer les types de contenus en fonction dans Drupal.
Par contre, tu parles de fusion de deux (ou plus) entrées. Comment tu repères cette modification? Le champ <audit> est plutôt léger upd_date, upd_detl


2) Maintenance des données: qui est responsable de telle ou telle entrée? Si l'entrée d'origine du JMdict est modifiée, comment s'assurer que la traduction recevra l'éventuelle révision nécessaire? C'est là qu'un système de possession des entrées à la Tatoeba pourrait s'avérer judicieux.

Tu parles de système de tags? http://tatoeba.org/eng/activities/improve_sentences Je connais peu Tatoeba, je découvre leur système.
On pourrait imager un système de tags similaire à l'import: @ok, @entry_change, @translation_change, @translation_create, @translation_conflict, etc. A approfondir.

Azel
04/09/2012, 23h27
Bonjour tout le monde, déjà un mois depuis mon dernier post, l'été, les vacances, le temps coule!

Dans tout ça, j'ai réussi à trouver un peu de temps pour travailler sur les modifications d'Openjisho ; beaucoup de réflexion sur la modélisation et le stockage de tout ce tas de données fournit par JMdict. Je suis arrivé à un modèle qui colle bien à mon besoin et assez évolutif.
Les entités sont les suivantes:

Entry: contient toutes les données globales à une entrée dans le dictionnaire, c-a-d les éléments K_ELE et R_ELE ainsi qu'une partie de l'élément SENSE. Pour le moment je n'ai pas vraiment vu d'utilité à stocker les données de l'élément INFO.
Translation: contient les données relatives à une traduction dans une langue donnée, on retrouve là les données contenues dans l'élément GLOSS. L'entité Translation se décline ensuite en sous-entités pour stocker des données spécifiques à une langue. Exemple le genre pour le français.

TranslationFR
TranslationEN
etc.



Côté IMPORT j'ai bien avancé, toute la partie ENTRY est finalisée, par contre il me reste un peu de boulot du côté des entités TRANSLATIONs.

En parallèle, je réfléchis au fonctionnalité du front et j'aimerais avoir votre avis sur le mockup suivant: https://plus.google.com/photos/111676089697760661734/albums/5784433139663004833?authkey=COC_rLC8toj1pQE

Par rapport à l'existant (http://goo.gl/uzqhg), j'aimerais réorganisais un peu le tout. Le bloc « Japanese » contiendrait les informations globales: version romaji + lien audio, détails des kanjis, niveau JLPT, etc. et en dessous on aurait un bloc à onglets contenant les traductions. Le choix de l'onglet par défaut prendra en compte la langue courante de l'utilisateur ; si la traduction n'existe pas alors on aura la traduction anglaise en substitution avec un message invitant à contribuer.

En espérant que vous soyez nombreux à réagir :D

PS: J'en profite également pour glisser un petit mot sur la lib JpnForPhp (lib PHP pour le japonais) qui a bien évolué. Un grand merci à Akeru pour sa contribution!
La version 0.4 est en préparation avec une refonte complète de la structure! Découpe de la librairie en composant, support de COMPOSER, compatible PSR-0 (au minimum), etc. Vous trouverez toutes les infos ici: http://mbilbille.github.com/jpnforphp/