stratégies de développement pour le correcteur
La clef USB est pratique pour trimballer mon boulot où je veux. Consulter la documentation MySql, ou Perl/TK. En plus avec Perl/Tk je suis sur que le logiciel fonctionnera sur Unix, qui est ma plateforme de choix. Pour l'élaboration je me balade avec un vieux portable que je pose sur les genoux et j'y travaille dessus à temps perdu ou je branche la clef sur ma machine unix et je continue de travailler il suffit de réinjecter les données exportées dans une base de données Mysql locale. J'aime l'idée de m'affranchir des logiciels propriétaires et le code source doit être livré avec l'application pour qu'elle soit améliorée (licences Opensource GNU ou BSD). Quand le script de démarrage sera au point, je ferais un fichier zip de la clef et je te la mettrai à disposition en téléchargement.
Pour créer un correcteur sur un appareil mobile (téléphone, blackberry, palm, j'ai déjà épluché le projet. Tout est disponible en Java 2 Micro Edition pour les téléphones portables, la base de données est déjà là c'est une technologie Sybase sqlAnywhere, un beau travail. C'est un portage possible une fois que le correcteur tourne bien. Pour l'instant il est plus simple de travailler avec un prototype en langage script jetable.
Le prototype est une petite fenêtre contenant un menu, une barre d'outils, un boite éditrice et une zone de statut (lecture seulement). Pour l'instant on lit un fichier (toujours le même), on le modifie et on l'enregistre, éventuellement on analyse le mot, la phrase et on affiche le statut dans la zone de statut. C'est tout ce que je veux faire pour l'instant, c'est de l'expérimentation sans autre ambition car on doit tester facilement les différentes stratégies de programmation.
Oui, super, pour le codage des règles dans une table de la base de données, par contre tu conviendras qu'il sera plus simple de coder les types grammaticaux et leur genre et nombre sous forme d'entier plutôt que des chaines de caractères. Le traitement d'analyse syntaxique est considérablement plus rapide, puisqu'on comparera des codes entre eux. Les codes des phrases pourraient être une série d'octets que l'on comparerait.
Les règles de construction des phrases pourraient être typées afin que l'algorithme soit capable de n'appliquer que la correction qu'il désire (accord des genres et/ou accord du nombre et/ou concordance des temps et/ou détection des francismes et/ou ...)
La proposition de mettre toutes les productions dans le correcteur orthographique me semble difficile car il faudra entrer toutes les déclinaisons d'un mot (en genre et en nombre).Le génie de l'occitan repose sur sa capacité assez féconde à frimer des mots pour traduire les sentiments creant ainsi une foule de productions pas faciles à contrôler et à cerner. On sait qu'on peut décliner, par exemple, òme en omenas, omenon, omenet, omeneton, omenasàs voire des contradictions, (omenassonet). On peut créer des oxymores et des chimères au gré de son imagination. Il ne serait pas élégant de confiner l'auteur à un lexique qui aurait du mal à être exhaustif. Ce serait interessant de trouver un façon de détecter si ça sonne occitan ou non, mais c'est un peu utopique, on listerait ainsi tout ce qu'on peut ajouter à une racine pour faire un mot selon un nombre limité de règles de production.
Pour les congugaisons le bouquin de Sauzet et Ubaud contient 13000 verbes, penses-tu les conjuguer à tous les temps, sachant qu'il y a 48 conjugaisons * 13000 et mettre tout ça dans une base de données. Il doit y avoir un autre moyen médian (algorithmique + base de donnée)
On peut tout à fait considérer reprendre le travail de Sauzet et Ubaud et l'informatiser, c'est à dire mettre les racines + infinitif dans une table et mettre leur typage. Ensuite mettre les types et les conjugaisons dans une autre table. Enfin recomposer le verbe conjugué dynamiquement en connaissant son type et sa racine. Les racines peuvent être intéressantes pour décliner de la même façon des substantifs, des adverbes, des gentilées (Gentilé : nom des habitants d'un lieu). Le boulot du correcteur orthographique pourrait être de ce type là.
Voila j'ai mis un paquet d'idées à plat. Je vais coder un peu et régler le problème des scripts de démarrage.
Précisions sur les orientations de développement
Conjointement au projet "Lo Branguet" et à la livraison du lexique de Domergue Sumien grâce à Mòni, l'application Corrector a subi une modification de la stratégie de développement.
En priorité j'ai monté le modèle de données permettant d'accepter différentes traductions d'un mot occitan (francaise, catalane, anglaise). Bien sur dans un premier temps on se concentre sur la traduction occitan-française, mais ça peut évoluer.
Quoiqu'il en soit, l'utilisation de la base de données en mode dictionaire n'est pas primordiale pour Lo Branguet, seule la vérification orthographique est nécessaire.
Le corrector dans sa forme actuelle (script Perl/Tk + MySQL sur une clef USB) se révèle une plateforme interessante pour toutes sortes d'expérimentations.
Dans un premier temps le correcteur orthographique est mis en place, et l'éditeur incorporé dans Perl/Tk avec ses fonctionnalités de chercher/remplacer est assez bien dimensionné pour ce type de travail.
Comme d'habitude dans les projets Opensource tout le source est disponible et libre de modification, il en va de même pour les données.
Sont en ligne :
