Re: [dev-fr] Issue 2838 : comportement attendu
Bonjour, Le 01/07/2010 16:30, Sophie a écrit : On peut soumettre à qui veut comme devoir de vacances, c'est très simple à faire :) Sinon, je me le bloque pour la prochaine version après la 3.3. Je suis en train de revoir ce qui a été fait. N'avais-tu pas proposé dernièrement une màj du fichier des autocorrections? J'ai vu passer ça dans les issues, mais je n'arrive pas à remettre la main dessus. Cordialement, Olivier - To unsubscribe, e-mail: dev-unsubscr...@fr.openoffice.org For additional commands, e-mail: dev-h...@fr.openoffice.org
Re: [dev-fr] Issue 2838 : comportement attendu
Bonjour Olivier, Olivier R. wrote: Bonjour, Le 01/07/2010 16:30, Sophie a écrit : On peut soumettre à qui veut comme devoir de vacances, c'est très simple à faire :) Sinon, je me le bloque pour la prochaine version après la 3.3. Je suis en train de revoir ce qui a été fait. N'avais-tu pas proposé dernièrement une màj du fichier des autocorrections? J'ai vu passer ça dans les issues, mais je n'arrive pas à remettre la main dessus. J'ai juste rajouté des mots avec un e dans l'o, je n'ai pas fait de nettoyage. L'issue est ici http://www.openoffice.org/issues/show_bug.cgi?id=112533 À bientôt Sophie - To unsubscribe, e-mail: dev-unsubscr...@fr.openoffice.org For additional commands, e-mail: dev-h...@fr.openoffice.org
Re: [dev-fr] Issue 2838 : comportement attendu
Bonjour, Le 01/07/2010 23:42, Jean-Baptiste Faure a écrit : oui mais passer par le correcteur orthographique est aussi couteux que remettre les majuscules si l'auto-correction les a supprimées. Peut-être, mais ça force à apprendre à mieux écrire directement du premier coup. :) L'autocorrection est un raccourci rapide pour corriger les fautes courantes et systématiques propres à chaque utilisateur ou communes. Cela permet d'éviter d'avoir le correcteur toujours en fonction. Oui, mais actuellement l'autocorrection ne propose pas que des fautes courantes. Épurer est nécessaire. De plus, le nombre de fautes possibles est immense, il me semble préférable de ne mettre que les erreurs que Hunspell ne sait pas corriger lui-même et ce qui est très courant comme trés == très. Je précise que j'avais déjà commencé ce travail. Je vais essayer de m'y remettre dans les jours qui viennent. De façon générale je pense que l'interprétation des intentions de l'utilisateur doit être bannie de l'auto-correction car c'est un moyen très sûr de mécontenter la moitié des utilisateurs . +1 Mais dans ce cas il faudra mettre dans la table d'auto-correction tous les cas possibles : aler - aller Aler - Aller ALER - ALLER et si l'utilisateur veut aussi aLer - aLLer il pourra le faire. Pas d'accord. Je ne vois pas pourquoi il faudrait se soucier de toutes les bizarreries possibles. Elles sont innombrables. A qui cela sera-t-il utile? L'utilisateur peut lui-même créer les autocorrections dont il a besoin. De toute façon, Hunspell ne tolère pas les aLLer, AlleR ou autre graphie arbitraire. Hunspell accepte le tout-bas-de-casse, le tout-haut-de-casse, ou la première lettre en majuscule, exception de ce qui est écrit explicitement dans le dictionnaire bien sûr. Songez aussi que si le fichier d'autocorrection n'est pas limité en taille, ça bouffe quand même des ressources au chargement et en mémoire. Sur les anciennes machines, ça se sent. Multiplier chaque mot par toutes ses possibilités sur la casse est irréaliste, àmha. Par exemple, pour aller, le bas de casse suffit, je pense. Hunspell peut aussi gérer le reste. Ceci dit, le contenu de l'autocorrection sort du champ de la spécification à écrire. Elle concerne chaque projet NL ou celui qui va se coller à la tâche. Au bout du compte je pense qu'une auto-correction qui fait exactement, ni plus ni moins, ce que l'utilisateur réclame est un outil bien plus utile et puissant, bien plus facile à spécifier et coder qu'une auto-correction qui aurait à décider si l'utilisateur ayant saisi aLer il voulait en fait aLLer, aLler ou simplement aller +1 Cordialement, Olivier - To unsubscribe, e-mail: dev-unsubscr...@fr.openoffice.org For additional commands, e-mail: dev-h...@fr.openoffice.org
Re: [dev-fr] Issue 2838 : comportement attendu
Bonjour, Le 01/07/2010 21:54, Arnaud VERSINI a écrit : La solution actuelle de remplacer aler par aller automatiquement a quand même le mérite de ne pas nécessiter d'action de l'utilisateur sur une faute qui est assez redondante lors de la saisie au clavier (personnellement la saisie de la même lettre deux fois de suite a tendance souvent poser pb), Comme je l'ai dit à JBF, je pense que vous ne devriez pas vous soucier du contenu spécifique de l'autocorrection pour écrire une spec, mais décrire un comportement. Mais le cas de la correction de le notre poserait probléme dans le cas d'une seule régle, avec la seule régle le notre = Le nôtre, 'Le notre ne serait pas traité, si on recherche dans la bd en tenant compte de la casse. Oui, mais il est impossible de gérer tous les cas, il faut sélectionner. Les variantes de casse sont-elles si importantes? Ce n'est pas si évident. Cordialement, Olivier R. - To unsubscribe, e-mail: dev-unsubscr...@fr.openoffice.org For additional commands, e-mail: dev-h...@fr.openoffice.org
Re: [dev-fr] Issue 2838 : comportement attendu
Bonjour, Le 02.07.2010 08:44, Olivier R. a écrit : Bonjour, [...] Le 01/07/2010 23:42, Jean-Baptiste Faure a écrit : [...] De façon générale je pense que l'interprétation des intentions de l'utilisateur doit être bannie de l'auto-correction car c'est un moyen très sûr de mécontenter la moitié des utilisateurs . +1 Mais dans ce cas il faudra mettre dans la table d'auto-correction tous les cas possibles : aler - aller Aler - Aller ALER - ALLER et si l'utilisateur veut aussi aLer - aLLer il pourra le faire. Pas d'accord. Je ne vois pas pourquoi il faudrait se soucier de toutes les bizarreries possibles. Elles sont innombrables. A qui cela sera-t-il utile? L'utilisateur peut lui-même créer les autocorrections dont il a besoin. De toute façon, Hunspell ne tolère pas les aLLer, AlleR ou autre graphie arbitraire. Hunspell accepte le tout-bas-de-casse, le tout-haut-de-casse, ou la première lettre en majuscule, exception de ce qui est écrit explicitement dans le dictionnaire bien sûr. Songez aussi que si le fichier d'autocorrection n'est pas limité en taille, ça bouffe quand même des ressources au chargement et en mémoire. Sur les anciennes machines, ça se sent. Multiplier chaque mot par toutes ses possibilités sur la casse est irréaliste, àmha. Oui tu as raison, la liste d'auto-correction fournie par défaut ne devrait pas se préoccuper de la casse. À l'utilisateur de compléter en fonction de ses besoins. La possibilité d'alimenter cette liste depuis le correcteur orthographique est très pratique pour ça. Bonne journée JBF -- Seuls des formats ouverts peuvent assurer la pérennité de vos documents. - To unsubscribe, e-mail: dev-unsubscr...@fr.openoffice.org For additional commands, e-mail: dev-h...@fr.openoffice.org
Re: [dev-fr] Issue 2838 : comportement attendu
Olivier, Le jeudi 01 juillet 2010 à 13:45 +0200, Olivier R. a écrit : Bonjour, Le 01/07/2010 12:10, Cédric Bosdonnat a écrit : Pour ma part je note quelques elements ici: * Toute spec de ce comportement ne doit pas tenir compte des autocorrections de corrections de majuscules (c'est autre chose) * La casse du mot devrait etre respectee apres le remplacement. Par exemple si l'utilisateur tape ceTrain, le mot devrait etre remplace par ceRtain. AMHA toute erreur de majuscule doit etre corrigee ailleurs. * Arrive un cas un peu delicat: lorsqu'il y a plus de caracteres dans le mot final. Par exemple: aler - aller * Si le mot de depart est tout en majuscules ou tout en minuscules, c'est facile... ALER - ALLER / aler - aller * Mais que faire quand on a un mix des deux? par exemple AleR. Je sais que c'est assez etrange comme cas... Je ne suis pas d’accord avec ce qui est écrit ci-dessus. S’il est demandé de transformer aler en aller, ça ne veut pas dire qu’on veut transformer ALER en ALLER. Cet exemple est tout bonnement tire de la liste d'autocorrections actuelle! Ce n'est pas de ma faute si l'on a besoin d'ajouter ce genre de choses pour les utilisateurs ecrivent francais correctement! Vous prenez trop l’autocorrection comme un simple service de correction orthographique. Ce n’est qu’un des usages de celle-ci. Non! Je cherche juste a corriger un bug enorme qui transforme actuellement ALER - aller. Si l'utilisateur a tape en majuscule c'est qu'il y avait une raison! Dans le cas ou l'utilisateur a tape ALER on ne va tout de meme pas le forcer a ecrire en minuscules! Celle-ci peut modifier une suite de mots en un seul ou l’inverse. Ex: RTFM = Lis le manuel. Lis la doc = RTFM Ca ne fonctionne que dans un sens a l'heure actuelle! Si je veux changer marc (de café), ça ne veut pas dire que je veux changer Marc ou MARC de la même manière. Il faut donc tenir compte de la casse et faire uniquement ce qui est demandé. S’il est écrit dans l’autocorrection: MARC === Mid-America Regional Council Marc === Marc, l’apôtre marc === marc de café A retenir, que c'est effectivement un bug Il ne faut pas interpréter ce qui est demandé, mais _faire juste ce qui est demandé_, et ne pas modifier la casse du texte de remplacement. Pour l’instant, le problème, c’est que l’autocorrection ne fait aucune distinction entre marc, Marc et MARC, et c’est ça qu’il faut changer. Ce comportement est diametralement oppose a celui que j'ai propose et qui est demande dans l'issue 2838. Cordialement, -- Cédric Bosdonnat Go-oo hacker http://go-oo.org OOo Eclipse Integration developer http://cedric.bosdonnat.free.fr - To unsubscribe, e-mail: dev-unsubscr...@fr.openoffice.org For additional commands, e-mail: dev-h...@fr.openoffice.org
Re: [dev-fr] Issue 2838 : comportement attendu
Bonjour Cédric, Le 01/07/2010 14:26, Cédric Bosdonnat a écrit : Je ne suis pas d’accord avec ce qui est écrit ci-dessus. S’il est demandé de transformer aler en aller, ça ne veut pas dire qu’on veut transformer ALER en ALLER. Cet exemple est tout bonnement tire de la liste d'autocorrections actuelle! Ce n'est pas de ma faute si l'on a besoin d'ajouter ce genre de choses pour les utilisateurs ecrivent francais correctement! Vous prenez trop l’autocorrection comme un simple service de correction orthographique. Ce n’est qu’un des usages de celle-ci. Non! Je cherche juste a corriger un bug enorme qui transforme actuellement ALER - aller. Si l'utilisateur a tape en majuscule c'est qu'il y avait une raison! Oui, c’est tiré de l’autocorrection actuelle, qui a été conçu comme un palliatif aux défaillances du correcteur d’alors, quand il peinait avec les doubles consonnes. Mais ce n’est plus le cas. Hunspell sait gérer la casse, et si on tape ALER, il suggère bien ALLER. Dans le cas ou l'utilisateur a tape ALER on ne va tout de meme pas le forcer a ecrire en minuscules! Celle-ci peut modifier une suite de mots en un seul ou l’inverse. Ex: RTFM = Lis le manuel. Lis la doc = RTFM Ca ne fonctionne que dans un sens a l'heure actuelle! Ah oui, tu as raison. L’autocorrection ne prend en compte que les 2 derniers mots tapés. Mon exemple est mauvais, ça ne fonctionne qu’avec 2 mots dans le 2e cas. Ce comportement est diametralement oppose a celui que j'ai propose et qui est demande dans l'issue 2838. En fait, les 2 cas sont demandés dans l’issue, et il sera effectivement difficile de concilier les deux. Dans le premier message, il est écrit: Also: I can not add in multiple entries of a same word in different case presentation into the AutoCorrect misspelled word list, and to have different replacement depending on the case presentation. * theparaoh will be AutoCorrected as the paraoh (the default, if none the below case presentations match) * TheparaoH could be AutoCorrected as Tutankhamun (case specific presentation override) * ThepaRaoH could be AutoCorrected as Nefertari (another case specific presentation override) Il y a bien deux demandes qui semblent un peu contradictoires. Peut-être faudra-t-il offrir la possibilité de choisir le type de correction pour chacune d’elle? -- Olivier R. == Adresse mail réservée aux listes de discussion.== == Les messages venant d’ailleurs sont _automatiquement_ effacés. == ** E-mail dedicated to mailing-lists. ** ** Messages from anywhere else are _automatically_ erased.** - To unsubscribe, e-mail: dev-unsubscr...@fr.openoffice.org For additional commands, e-mail: dev-h...@fr.openoffice.org
Re: [dev-fr] Issue 2838 : comportement attendu
Le jeudi 01 juillet 2010 à 15:59 +0200, Olivier R. a écrit : Non! Je cherche juste a corriger un bug enorme qui transforme actuellement ALER - aller. Si l'utilisateur a tape en majuscule c'est qu'il y avait une raison! Oui, c’est tiré de l’autocorrection actuelle, qui a été conçu comme un palliatif aux défaillances du correcteur d’alors, quand il peinait avec les doubles consonnes. Mais ce n’est plus le cas. Hunspell sait gérer la casse, et si on tape ALER, il suggère bien ALLER. Hum... dans ce cas, pourquoi ne pas degager cette pourriture de la table de remplacement, si ce n'est pas encore fait? Dans ce cas, il ne reste en effet plus que ce que tu specifies a implementer. Dans le cas ou l'utilisateur a tape ALER on ne va tout de meme pas le forcer a ecrire en minuscules! Celle-ci peut modifier une suite de mots en un seul ou l’inverse. Ex: RTFM = Lis le manuel. Lis la doc = RTFM Ca ne fonctionne que dans un sens a l'heure actuelle! Ah oui, tu as raison. L’autocorrection ne prend en compte que les 2 derniers mots tapés. Mon exemple est mauvais, ça ne fonctionne qu’avec 2 mots dans le 2e cas. Ooops, j'avais pas vu que ce n'etait pas exactement l'inverse... tu sous-entend ici qu'il faut deux entrees dans la table de remplacement, n'est-ce pas? Il y a bien deux demandes qui semblent un peu contradictoires. Peut-être faudra-t-il offrir la possibilité de choisir le type de correction pour chacune d’elle? Pour ce qui me concerne, je suis d'accord d'implementer la demande que tu soulignes: en plus c'est la plus simple en matiere de specifs et de cas particuliers. Par contre il faut ajouter a cette tache de nettoyer la table de remplacement de toutes les entrees faisant de la correction de faute de frappe (a relayer aussi dans les autres projets NL pour les tables anglaise, vietnamienne, et surement d'autres). -- Cédric Bosdonnat Go-oo hacker http://go-oo.org OOo Eclipse Integration developer http://cedric.bosdonnat.free.fr - To unsubscribe, e-mail: dev-unsubscr...@fr.openoffice.org For additional commands, e-mail: dev-h...@fr.openoffice.org
Re: [dev-fr] Issue 2838 : comportement attendu
Bonjour, Cédric Bosdonnat wrote: Le jeudi 01 juillet 2010 à 15:59 +0200, Olivier R. a écrit : Non! Je cherche juste a corriger un bug enorme qui transforme actuellement ALER - aller. Si l'utilisateur a tape en majuscule c'est qu'il y avait une raison! Oui, c’est tiré de l’autocorrection actuelle, qui a été conçu comme un palliatif aux défaillances du correcteur d’alors, quand il peinait avec les doubles consonnes. Mais ce n’est plus le cas. Hunspell sait gérer la casse, et si on tape ALER, il suggère bien ALLER. Hum... dans ce cas, pourquoi ne pas degager cette pourriture de la table de remplacement, si ce n'est pas encore fait? Dans ce cas, il ne reste en effet plus que ce que tu specifies a implementer. Dans le cas ou l'utilisateur a tape ALER on ne va tout de meme pas le forcer a ecrire en minuscules! Celle-ci peut modifier une suite de mots en un seul ou l’inverse. Ex: RTFM = Lis le manuel. Lis la doc = RTFM Ca ne fonctionne que dans un sens a l'heure actuelle! Ah oui, tu as raison. L’autocorrection ne prend en compte que les 2 derniers mots tapés. Mon exemple est mauvais, ça ne fonctionne qu’avec 2 mots dans le 2e cas. Ooops, j'avais pas vu que ce n'etait pas exactement l'inverse... tu sous-entend ici qu'il faut deux entrees dans la table de remplacement, n'est-ce pas? Il y a bien deux demandes qui semblent un peu contradictoires. Peut-être faudra-t-il offrir la possibilité de choisir le type de correction pour chacune d’elle? Pour ce qui me concerne, je suis d'accord d'implementer la demande que tu soulignes: en plus c'est la plus simple en matiere de specifs et de cas particuliers. Par contre il faut ajouter a cette tache de nettoyer la table de remplacement de toutes les entrees faisant de la correction de faute de frappe (a relayer aussi dans les autres projets NL pour les tables anglaise, vietnamienne, et surement d'autres). On peut soumettre à qui veut comme devoir de vacances, c'est très simple à faire :) Sinon, je me le bloque pour la prochaine version après la 3.3. À bientôt Sophie - To unsubscribe, e-mail: dev-unsubscr...@fr.openoffice.org For additional commands, e-mail: dev-h...@fr.openoffice.org
Re: [dev-fr] Issue 2838 : comportement attendu
Cédric Bosdonnat a écrit : Hum... dans ce cas, pourquoi ne pas degager cette pourriture de la table de remplacement, si ce n'est pas encore fait? J'avais commencé cette tâche, puis j'ai ajouté des entrées pour d'autres remplacements, puis d'autres encore, et c'est en fait extrêmement long à tester. J'ai justement eu des soucis avec cette histoire de casse dont je n'ai pris conscience que tardivement. Puis je suis passé à autre chose et je n'ai plus guère songé. Ooops, j'avais pas vu que ce n'etait pas exactement l'inverse... tu sous-entend ici qu'il faut deux entrees dans la table de remplacement, n'est-ce pas? Non, une seule entrée suffit. Par exemple: le notre == le nôtre Dans le fichier, ça donne ça: block-list:block block-list:abbreviated-name=le notre block-list:name=le nôtre/ C'est ce genre de modifications qui touchent à la grammaire qui sont longues à tester, car il faut penser à tous les cas. Par contre il faut ajouter a cette tache de nettoyer la table de remplacement de toutes les entrees faisant de la correction de faute de frappe (a relayer aussi dans les autres projets NL pour les tables anglaise, vietnamienne, et surement d'autres). En fait, pas toutes les entrées de correction, car le correcteur a aussi ses limites pour la suggestion des formes correctes, mais une très grosse partie. A vue de nez, 80-90% peut être enlevé. Cordialement, Olivier - To unsubscribe, e-mail: dev-unsubscr...@fr.openoffice.org For additional commands, e-mail: dev-h...@fr.openoffice.org
Re: [dev-fr] Issue 2838 : comportement attendu
Bonsoir, Je me propose de créer une page du wiki à cette adresse pour mettre en place le début de spécification en français : http://wiki.services.openoffice.org/wiki/FR/developpement/issue/2838/spec Au final on supprimerait le coté correction orthographique automatique et il serait plutôt un utilitaire de remplacement automatique en tenant compte de la casse dans la recherche. La solution actuelle de remplacer aler par aller automatiquement a quand même le mérite de ne pas nécessiter d'action de l'utilisateur sur une faute qui est assez redondante lors de la saisie au clavier (personnellement la saisie de la même lettre deux fois de suite a tendance souvent poser pb), Mais le cas de la correction de le notre poserait probléme dans le cas d'une seule régle, avec la seule régle le notre = Le nôtre, 'Le notre ne serait pas traité, si on recherche dans la bd en tenant compte de la casse. Cordialement Le 1 juillet 2010 18:39, Olivier R. dico.sav...@free.fr a écrit : Cédric Bosdonnat a écrit : Hum... dans ce cas, pourquoi ne pas degager cette pourriture de la table de remplacement, si ce n'est pas encore fait? J'avais commencé cette tâche, puis j'ai ajouté des entrées pour d'autres remplacements, puis d'autres encore, et c'est en fait extrêmement long à tester. J'ai justement eu des soucis avec cette histoire de casse dont je n'ai pris conscience que tardivement. Puis je suis passé à autre chose et je n'ai plus guère songé. Ooops, j'avais pas vu que ce n'etait pas exactement l'inverse... tu sous-entend ici qu'il faut deux entrees dans la table de remplacement, n'est-ce pas? Non, une seule entrée suffit. Par exemple: le notre == le nôtre Dans le fichier, ça donne ça: block-list:block block-list:abbreviated-name=le notre block-list:name=le nôtre/ C'est ce genre de modifications qui touchent à la grammaire qui sont longues à tester, car il faut penser à tous les cas. Par contre il faut ajouter a cette tache de nettoyer la table de remplacement de toutes les entrees faisant de la correction de faute de frappe (a relayer aussi dans les autres projets NL pour les tables anglaise, vietnamienne, et surement d'autres). En fait, pas toutes les entrées de correction, car le correcteur a aussi ses limites pour la suggestion des formes correctes, mais une très grosse partie. A vue de nez, 80-90% peut être enlevé. Cordialement, Olivier - To unsubscribe, e-mail: dev-unsubscr...@fr.openoffice.org For additional commands, e-mail: dev-h...@fr.openoffice.org
Re: [dev-fr] Issue 2838 : comportement attendu
Le 01.07.2010 16:20, Cédric Bosdonnat a écrit : Le jeudi 01 juillet 2010 à 15:59 +0200, Olivier R. a écrit : Non! Je cherche juste a corriger un bug enorme qui transforme actuellement ALER - aller. Si l'utilisateur a tape en majuscule c'est qu'il y avait une raison! Oui, c’est tiré de l’autocorrection actuelle, qui a été conçu comme un palliatif aux défaillances du correcteur d’alors, quand il peinait avec les doubles consonnes. Mais ce n’est plus le cas. Hunspell sait gérer la casse, et si on tape ALER, il suggère bien ALLER. oui mais passer par le correcteur orthographique est aussi couteux que remettre les majuscules si l'auto-correction les a supprimées. D'un autre coté si on utilise des styles de caractères il n'y a plus de problème car on peut configurer l'auto-correction pour qu'elle conserve le style utilisé (cocher la case texte seulement). Hum... dans ce cas, pourquoi ne pas degager cette pourriture de la table de remplacement, si ce n'est pas encore fait? Dans ce cas, il ne reste en effet plus que ce que tu specifies a implementer. Alors dans ce cas il faut aussi enlever la fonction du correcteur orthographique qui permet d'alimenter la table d'auto-correction. Mais je ne trouve pas que ce soit une bonne idée. L'autocorrection est un raccourci rapide pour corriger les fautes courantes et systématiques propres à chaque utilisateur ou communes. Cela permet d'éviter d'avoir le correcteur toujours en fonction. De façon générale je pense que l'interprétation des intentions de l'utilisateur doit être bannie de l'auto-correction car c'est un moyen très sûr de mécontenter la moitié des utilisateurs . Et donc cela a pour conséquence qu'il faut modifier l'auto-correction pour qu'elle distingue la casse. Mais dans ce cas il faudra mettre dans la table d'auto-correction tous les cas possibles : aler - aller Aler - Aller ALER - ALLER et si l'utilisateur veut aussi aLer - aLLer il pourra le faire. Au bout du compte je pense qu'une auto-correction qui fait exactement, ni plus ni moins, ce que l'utilisateur réclame est un outil bien plus utile et puissant, bien plus facile à spécifier et coder qu'une auto-correction qui aurait à décider si l'utilisateur ayant saisi aLer il voulait en fait aLLer, aLler ou simplement aller parce qu'il y a en fait deux erreurs, le simple l et la majuscule. Mes 2 cents. Bonne soirée JBF -- Seuls des formats ouverts peuvent assurer la pérennité de vos documents. - To unsubscribe, e-mail: dev-unsubscr...@fr.openoffice.org For additional commands, e-mail: dev-h...@fr.openoffice.org
Re: [dev-fr] Issue 2838 : comportement attendu
Bonjour, Le 29/06/2010 23:07, Arnaud VERSINI a écrit : Bonsoir, Afin de rédiger dans le cadre de cette issue une spécification, voici quelques idées en vrac sur le comportement attendu. Les tableaux prennent en compte les corrections déjà appliquées pour la casse. Cas d'une correction en début de mot, remplacement de deux lettres par une seule Je n’ai pas compris. Qu’importe le nombre de lettres qu’on substitue? Cas d'une correction à une autre position, remplacement d'une lettre par deux lettres [...] Cas d'une inversion de deux lettres [...] Il me semble qu’il y a une confusion sur le problème à traiter. L’issue 2838 ne traite pas du contenu du fichier d’autocorrections et du type d’erreurs à corriger. Il est demandé de tenir compte de la casse; que vient faire le remplacement d’une lettre par deux dans cette affaire, ou encore l’inversion de deux caractères? Les exemples de l’issue exposent déjà assez bien l’affaire, àmha. Ce qu’on mettra ensuite dans le fichier d’autocorrection, c’est un autre problème. :) J’espère ne pas répondre à côté de la plaque, car je ne suis pas certain d’avoir saisi tout le message. Cordialement, Olivier R. [HS] Ce message vient de paraître dans mon courrier ce matin, alors qu’hier soir, on m’avertissait de l’existence de cette discussion, dont je n’ai reçu jusqu’à présent que le premier message. Un problème avec la ML? [/HS] -- == Adresse mail réservée aux listes de discussion.== == Les messages venant d’ailleurs sont _automatiquement_ effacés. == ** E-mail dedicated to mailing-lists. ** ** Messages from anywhere else are _automatically_ erased.** - To unsubscribe, e-mail: dev-unsubscr...@fr.openoffice.org For additional commands, e-mail: dev-h...@fr.openoffice.org
Re: [dev-fr] Issue 2838 : comportement attendu
Bonjour, Le pb vient de la casse des lettres à remplacer. Si l'on veut conserver la casse comme celle du mot d'origine il y a quand même certains problémes à remarquer ; soeur ou SOEUR, pas de problème on met tout en minuscule ou en majuscule mais sOeur il faut décider si le œ on le met en majuscule ou en minuscule par exemple. Je ne pense pas que la question soit si triviale que ça mais bon sinon on peut se contenter d'avoir en minuscule si tout en minuscule ou en majuscule si tout en majuscule et en minuscule si mélanger Bon je vais voir ce soir ou je mets le tableau Cordialement Le 30 juin 2010 11:03, Olivier R. dico.sav...@free.fr a écrit : Bonjour, Le 29/06/2010 23:07, Arnaud VERSINI a écrit : Bonsoir, Afin de rédiger dans le cadre de cette issue une spécification, voici quelques idées en vrac sur le comportement attendu. Les tableaux prennent en compte les corrections déjà appliquées pour la casse. Cas d'une correction en début de mot, remplacement de deux lettres par une seule Je n’ai pas compris. Qu’importe le nombre de lettres qu’on substitue? Cas d'une correction à une autre position, remplacement d'une lettre par deux lettres [...] Cas d'une inversion de deux lettres [...] Il me semble qu’il y a une confusion sur le problème à traiter. L’issue 2838 ne traite pas du contenu du fichier d’autocorrections et du type d’erreurs à corriger. Il est demandé de tenir compte de la casse; que vient faire le remplacement d’une lettre par deux dans cette affaire, ou encore l’inversion de deux caractères? Les exemples de l’issue exposent déjà assez bien l’affaire, àmha. Ce qu’on mettra ensuite dans le fichier d’autocorrection, c’est un autre problème. :) J’espère ne pas répondre à côté de la plaque, car je ne suis pas certain d’avoir saisi tout le message. Cordialement, Olivier R. [HS] Ce message vient de paraître dans mon courrier ce matin, alors qu’hier soir, on m’avertissait de l’existence de cette discussion, dont je n’ai reçu jusqu’à présent que le premier message. Un problème avec la ML? [/HS] -- == Adresse mail réservée aux listes de discussion.== == Les messages venant d’ailleurs sont _automatiquement_ effacés. == ** E-mail dedicated to mailing-lists. ** ** Messages from anywhere else are _automatically_ erased.** - To unsubscribe, e-mail: dev-unsubscr...@fr.openoffice.org For additional commands, e-mail: dev-h...@fr.openoffice.org
[dev-fr] Issue 2838 : comportement attendu
Bonsoir, Afin de rédiger dans le cadre de cette issue une spécification, voici quelques idées en vrac sur le comportement attendu. Les tableaux prennent en compte les corrections déjà appliquées pour la casse. Cas d'une correction en début de mot, remplacement de deux lettres par une seule Original Correction début de phrase Correction autre position Oeuvre Œuvre œuvre oeuvre Œuvre œuvre OEUVRE ŒUVRE ŒUVRE OEuvre Œuvre œuvre ou Œuvre? oEuvre Œuvre œuvre ou Œuvre? Cas d'une correction à une autre position, remplacement d'une lettre par deux lettres Original Correction début de phrase Correction autre position Apel Appel appel apel Appel appel APEL APPEL APPEL aPel APPel aPPel Cas d'une inversion de deux lettres Original Correction début de phrase Correction autre position Dexu Deux deux dexu Deux deux DEXU DEUX DEUX deXu DeuX deuX Je pense avoir à peu près tout les cas de figures, si il en manque merci de le faire remonter. Voila donc un début de proposition à discuter. Cordialement
Re: [dev-fr] Issue 2838 : comportement attendu
Non non tu ne te trompes pas, une solution? Le 29 juin 2010 23:37, Éric Savary eric.sav...@sun.com a écrit : Bonsoir Arnaud, Me trompé-je ou ton message avait de jolis tableaux en HTML qui ne sont pas passés ou alors il est trop tard pour moi et je n'arrive plus à comprendre la structure de ton message. :) CordialemenÉric Arnaud VERSINI wrote: Bonsoir, Afin de rédiger dans le cadre de cette issue une spécification, voici quelques idées en vrac sur le comportement attendu. Les tableaux prennent en compte les corrections déjà appliquées pour la casse. Cas d'une correction en début de mot, remplacement de deux lettres par une seule Original Correction début de phrase Correction autre position Oeuvre Œuvre œuvre oeuvre Œuvre œuvre OEUVRE ŒUVRE ŒUVRE OEuvre Œuvre œuvre ou Œuvre? oEuvre Œuvre œuvre ou Œuvre? Cas d'une correction à une autre position, remplacement d'une lettre par deux lettres Original Correction début de phrase Correction autre position Apel Appel appel apel Appel appel APEL APPEL APPEL aPel APPel aPPel Cas d'une inversion de deux lettres Original Correction début de phrase Correction autre position Dexu Deux deux dexu Deux deux DEXU DEUX DEUX deXu DeuX deuX Je pense avoir à peu près tout les cas de figures, si il en manque merci de le faire remonter. Voila donc un début de proposition à discuter. Cordialement - To unsubscribe, e-mail: dev-unsubscr...@fr.openoffice.org For additional commands, e-mail: dev-h...@fr.openoffice.org
Re: [dev-fr] Issue 2838 : comportement attendu
Bonsoir Arnaud, Me trompé-je ou ton message avait de jolis tableaux en HTML qui ne sont pas passés ou alors il est trop tard pour moi et je n'arrive plus à comprendre la structure de ton message. :) CordialemenÉric Arnaud VERSINI wrote: Bonsoir, Afin de rédiger dans le cadre de cette issue une spécification, voici quelques idées en vrac sur le comportement attendu. Les tableaux prennent en compte les corrections déjà appliquées pour la casse. Cas d'une correction en début de mot, remplacement de deux lettres par une seule Original Correction début de phrase Correction autre position Oeuvre Œuvre œuvre oeuvre Œuvre œuvre OEUVRE ŒUVRE ŒUVRE OEuvre Œuvre œuvre ou Œuvre? oEuvre Œuvre œuvre ou Œuvre? Cas d'une correction à une autre position, remplacement d'une lettre par deux lettres Original Correction début de phrase Correction autre position Apel Appel appel apel Appel appel APEL APPEL APPEL aPel APPel aPPel Cas d'une inversion de deux lettres Original Correction début de phrase Correction autre position Dexu Deux deux dexu Deux deux DEXU DEUX DEUX deXu DeuX deuX Je pense avoir à peu près tout les cas de figures, si il en manque merci de le faire remonter. Voila donc un début de proposition à discuter. Cordialement - To unsubscribe, e-mail: dev-unsubscr...@fr.openoffice.org For additional commands, e-mail: dev-h...@fr.openoffice.org
Re: [dev-fr] Issue 2838 : comportement attendu
mh... je ne sais pas exactement ce qu'autorise ou non la liste... (pas de pièces jointes en tout cas je crois) 2 solutions: soit tu ASCIIse (c.a.d. faire le tableau en texte) soit tu créé un page sous http://wiki.services.openoffice.org/wiki/FR/ A+ Éric Arnaud VERSINI wrote: Non non tu ne te trompes pas, une solution? Le 29 juin 2010 23:37, Éric Savary eric.sav...@sun.com a écrit : - To unsubscribe, e-mail: dev-unsubscr...@fr.openoffice.org For additional commands, e-mail: dev-h...@fr.openoffice.org
Re: [dev-fr] Issue 2838 : comportement attendu
Ok merci, vais m'en occuper demain alors, tout en ASCII Le 29 juin 2010 23:47, Éric Savary eric.sav...@sun.com a écrit : mh... je ne sais pas exactement ce qu'autorise ou non la liste... (pas de pièces jointes en tout cas je crois) 2 solutions: soit tu ASCIIse (c.a.d. faire le tableau en texte) soit tu créé un page sous http://wiki.services.openoffice.org/wiki/FR/ A+ Éric Arnaud VERSINI wrote: Non non tu ne te trompes pas, une solution? Le 29 juin 2010 23:37, Éric Savary eric.sav...@sun.com a écrit : - To unsubscribe, e-mail: dev-unsubscr...@fr.openoffice.org For additional commands, e-mail: dev-h...@fr.openoffice.org
