Re: [dev-fr] Issue 2838 : comportement attendu

2010-07-03 Par sujet Olivier R.

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

2010-07-03 Par sujet Sophie

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

2010-07-02 Par sujet Olivier R.

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

2010-07-02 Par sujet Olivier R.

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

2010-07-02 Par sujet Jean-Baptiste Faure
 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

2010-07-01 Par sujet Cédric Bosdonnat
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

2010-07-01 Par sujet Olivier R.

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

2010-07-01 Par sujet Cédric Bosdonnat
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

2010-07-01 Par sujet Sophie

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

2010-07-01 Par sujet Olivier R.

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

2010-07-01 Par sujet Arnaud VERSINI
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

2010-07-01 Par sujet Jean-Baptiste Faure
 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

2010-06-30 Par sujet Olivier R.

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

2010-06-30 Par sujet Arnaud VERSINI
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




Re: [dev-fr] Issue 2838 : comportement attendu

2010-06-29 Par sujet Arnaud VERSINI
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

2010-06-29 Par sujet Éric Savary

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

2010-06-29 Par sujet Éric Savary
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

2010-06-29 Par sujet Arnaud VERSINI
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