Openjisho - le Japonais pour vous, par vous

[Akeru]

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

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

[Azel]

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 .

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

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]

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]

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

[Akeru]

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

Ca me semble un peu ambitieux ça

[Azel]

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

[Gnurou]

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...of-bad-design/ )

[Akeru]

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

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

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

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]

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/11167...OC_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

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/