Projet dictionnaire débutant

Bonjour
Je ne sais pas si je suis dans la bonne rubrique, si ce n'est pas le cas veuillez m'excuser.
J'effectue mes premiers pas dans la programmation et j'ai choisi Java. Pour apprendre, j'ai lu quelques ouvrages et des tutos mais c'est tout. j'ai pour projet (certes ambitieux mais j'ai tout mon temps pour apprendre) la création d'un dictionnaire de traduction (ex Français/Anglais; Anglais/Français) ce programme (si j'y arrive) est destiné à être une application pour mobile .
Pourriez vous m'aider mans le choix des variables que je dois apprendre pour créer ce programme ?
Pourriez vous me donner vos avis (constructif si possible) sur le projet, la façon à construire l'ensemble? ou même m'indiquer le nom d'ouvrage qui pourraient m’être utile ?
merci

cordialement....

Salut,

Commences petit et ensuite améliore en ajoutant des fonctions : commences d'abord par faire un programme qui entrant un mot dans une langue en affiche la traduction dans une autre. Commences par décrire quelles informations sont nécessaires pour réaliser cette tâche, en dehors de tout aspect Java (modélisation). Ensuite choisi un moyen de stocker les informations : par exemple une base de données. Puis écris les requêtes SQL nécessaires pour retrouver la traduction d'un mot dans une table, à partir du mot en entrée. Ensuite, à partir des tutoriels que tu as lus, tu dois pouvoir déjà écrire le code qui fait ça. Quand ça fonctionne, tu t'attaques à l'interface graphique : tu sais ce qu'on doit saisir en entrée, ce qu'on doit afficher en sortie, donc comment concevoir les interfaces graphiques pour gérer ça, donc les coder.

Ensuite, tu peux améliorer, on ajoutant des fonctionnalités, progressivement : plusieurs traductions pour le même mot en entrée, contexte d'usage de telle traduction, etc.

PS. Notes toutefois que tu auras un aspect fastidieux dans la réalisation de ton projet : entrer dans la base de données tous les mots dans les deux langues ! (Tu peux chercher sur Internet s'il existe des dictionnaires gratuits.)

Bonsoir,
Merci de ta réponse claire et rapide. Je pence suivre ton conseil mais j'ai une petite question, j'ai pu voir que la gestion de la mémoire est très importante
pour les programme destiné aux mobiles ( je sais que je n'en suis pas encore là mais c'est toujours bien d'avoir une vision globale avant de commencer), je compte donc effectuer un programme qui charge
les expressions au fur et a mesure. Je m'explique : en admettant que je tape A B R dans lectureClavier(ou autre), les seuls mot qui pourront être chargé seront abricot,abris, abrutis, etc......
en commençant petit a petit comme tu me le conseil, est ce que je ne me retrouverais pas coincé dans ce genre de gestion et de devoir tout recommencer ?
Pour ce qui est du travail fastidieux de rentrer tous les mots et leurs traductions, j'en suis conscient, il n'y a pas de base de donnée existante pour ce que je veux faire , c'est pour cela que je veut être sur de partir dans la bonne direction dès le début.
Cela m’évitera de recommencer deux fois ou plus un travail déjà très long.

merci encore

Salut,
effectivement il faut que tu anticipes beaucoup plus sur mobile. A priori tu devras coder un truc asynchrone sur la/les lettres tapées et ensuite récup la déf/traduction idem en async.
Bye

La gestion de la mémoire est une partie importante en particulier quand on en dispose de peu. Mais dans le cas que ton programme, à la base, il n'y a pas de consommation de mémoire particulièrement préoccupante. L'algorithme de base est : l'utilisateur saisit un mot, on cherche la traduction, on l'affiche. Ceci nécessite très peu de mémoire à priori. La mémoire est surtout consommée par les dictionnaires : ils posent donc la question de savoir comment on y accède, en ccès local (chargement complet en mémoire ou accès partiel), ou accès distant.

Ensuite, le comportement dont tu parles, qu'on appelle autocompletion, est pour moi, une fioriture cosmétique qui peut s'ajouter lorsque le programme de base est fonctionnel. Il n'y a pas vraiment besoin de l'anticiper : au contraire, je dirais que la façon de le réaliser dépend de choix préalables (Est-ce que l'interface est native, ou web ? Est-ce que l'application est locale, ou client-serveur, ou multi-tiers ? L'architecture est bien plus importante que ce genre d'aspect : si tu dois la modifier après avoir écrit le code, tu auras certainement un impact considérable sur la réécriture de code. Conçois, par exemple, le programme de manière modulaire, afin de n'avoir à réécrire que des sous-parties de manière indépendante.

Enfin, si l'ambition est louable, la modestie favorise l'aboutissement : quand on a jamais réalisé d'application, on a tendance à vouloir tout faire du premier coup, à penser à tout en même temps, et au final, on se perd ou on fait une usine à gaz, le projet traine, et, si on arrive finalement au résultat prévu, il a beaucoup de défauts techniques, qui font qu'il est très peu fonctionnel et utilisable, et sa mise au point devient interminable. Il devient difficile de ne pas abandonner ou de tout réécrire à zéro. Si tu procèdes par itérations successives, en réalisant d'abord un cas simple, puis en augmentant les ambitions progressivement, tu te construiras une expérience qui petit à petit te permettra d'anticiper justement les problèmes techniques. Et tu auras à chaque itération, un programme qui fonctionne, limité certes, mais que tu pourras faire facilement évoluer (comme ajouter l'autocomplétion). Il n'y a rien de plus frustant que de passer des mois à faire tout du premier coup, et ne n'avoir rien qui fonctionne correctement lorsqu'on met en production un projet.

Pour prendre un exemple, si on regarde le site WordReference, une référence dans les sites de dictionnaire de traduction, il a fonctionné des années sans la complétion.

Salut,
nos avis divergent sur plusieurs points :
- à mon sens le fait qu'il s'agisse d'un système de trad pose les mêmes problématiques qu'un dictionnaire (stockage et recherche/accès). Pour le stockage complet et local, même en arbre, a priori il y a moyen de faire exploser la RAM, d'autant plus qu'il faut gérer 2 lexiques (et de plus stocker des infos de liaisons entre les entrées des 2 lexiques). Donc effectivement, si tu commences à développer le système de recherche, de liaisons, etc. sans réfléchir à tout cela, en partant sur des structures de données inadaptées par exemple et/ou en travaillant sur un jeu de données partiel sans anticiper la taille réelle des données, il y a des chances qu'il faille tout recoder à un moment donné. En gros il y a 3 soluces globales, stockage en "RAM" à l'exécution, stockage sur mémoire/disque flash et accès à l'exécution, application client/serveur, si tu n'anticipes pas les conséquences de l'un ou l'autre des 3 choix il faudra sans doute recoder une bonne partie de l'appli
- il me semble que la phrase "en admettant que je tape A B R dans lectureClavier(ou autre), les seuls mot qui pourront être chargé seront abricot,abris, abrutis, etc." est clairement un des besoins utilisateurs à prendre en compte dès le début car ça peut aider à définir non seulement le type de structure de données mais aussi le type de communications même si sur mobile tu n'auras pas trop le choix justement à cause des contraintes techniques, concrètement il y a de fortes chances que la seule solution viable soit une appli client/serveur. (Par ailleurs, à mon avis, développer une surcouche d'auto-complétion sur un système qui a été basé sur des listes "plates" stockées localement a de grandes chances d'aboutir à de très mauvaises perfs (même sur PC ?))

Merci beaucoup à tous pour vos réponses, du coup j'hesite un peu (Lol).
Djakisbak votre réponse rejoint un peu ce que j ai pu trouver dans mes recherches.
Quand vous dite que la meilleur solution est d avoir une gestion Client/serveur, quesque c'est exactement ? Cela veut il dire qu'il faut avoir une base de donnée en ligne ? ( n'oubliez pas que je suis un réel débutant )
Merci encore .

Bonjour,
en fait j'ai dit que c'était "sans doute" la meilleure solution mais je ne connais pas exactement le volume des lexiques français et anglais. Pour ce qui est d'une appli client/serveur il y a plusieurs solutions mais dans tous les cas tu auras besoin d'une machine qui soit le serveur. Ensuite tu développes l'appli cliente Java qui va envoyer des requêtes/messages à la machine serveur. Sur la machine serveur les possibilités sont très larges, tu peux développer une appli serveur maison en Java qui répond aux requêtes du client ou utiliser des technologies existantes comme JSP/PHP/etc. + base de données SQL ou bien interroger directement le serveur de base de données. Pour débuter c'est très loin d'être le projet le plus simple car ça traite d'une multitude de méthodes informatiques en même temps.
Tu aurais peut-être intérêt de te rabattre sur un projet moins complexe si tu es réellement débutant. Tu pourrais aussi essayer d'estimer le volume de données final, il doit y avoir des fichiers de dicos qui trainent sur le net puis aviser en fonction. Si tu vises que les mobiles les plus récents il y a peut-être moyen de faire un truc qui tourne relativement bien uniquement en local, à voir.
Bye

À mon avis, cette histoire de mobile est la feature de trop. Je sais que tout le monde dit de "Penser mobile d'abord" mais comme tu es un débutant, je ne te conseille pas de commencer par le mobile. Fais toi ton programme Java desktop beau propre et tu va découvrir cette sensation d'accomplissement lorsque tu auras ta belle interface dans les mains. Avant cela, tu n'auras pas l'impression d'avancer et c'est frustrant.
Si tu fais une appli desktop de traduction, ça peut te prendre une petite semaine (1 jour pour la bdd (juste les tables, pas le remplissage parce que là c'est moins drôle...), 2 jours pour l'ihm (avec des panel stp, pas des setbounds), 1 jours de plus pour lier les requêtes, listener, vue, et un dernier jour de contemplation et de mini correction). Si tu fais ça, tu vas avoir qqchose de fini, et si tu conçois bien ton archi, tu peux avoir un programme qui peut évoluer facilement.
Rien que de partir sur un beau MVC, ça peut t'aider à gagner en capacité d'évolution.
Le vrai problème, ça va être ton implication. Car en étant un débutant, il y a beaucoup de concept que tu n'as pas (d'un côté, c'est une bonne chose de ne pas avoir les mauvaises habitudes comme peuvent avoir certaines personnes ayant un passif dans un autre langage (le bon vieux static main qui fait tout :D)), donc il y a un risque que tu prennes beaucoup de temps à comprendre le concept objet, et encore plus à savoir comment l'appliquer. Et ce temps ne va pas être consacré à ton appli mais à des connaissances que tu va trouver peut être pénible et qui vont grignoter ton capital confiance.
Mais tu as un avantage sur les autres, tu es venu sur DVP, ce que tu peux faire c'est faire un point sur ton avancement/questions sur ce topic, et nous pouvons d'aider, de soutenir, de dire si tu es sur la bonne voie ou non.

Bonjour,

Pourquoi dites-vous à propose de l'IHM

Citation:

---

(avec des panel stp, pas des setbounds)

---

Qu'ont les setbounds de mauvais ?
Merci pour votre réponse.

Les setbound ne permettent pas de faire une ihm adaptable. Les éléments sont fixés dans la fenêtre et si l'utilisateur veut redimensionner la taille de la fenêtre, et bien rien ne va changer. Les panels vont permettre de garder la structure de l'ihm quoique fasse l'utilisateur (et on a pas besoin de s'emmerder avec les x et les y, tu mets des boites dans des boites et ça marche tout seul)

C'est bien compris.
Merci.