| Re: [EGD-discu] [Vote] Touche morte + espace |
[ Thread Index |
Date Index
| More ergodis.org/discussions Archives
]
Du fait que les caractères précomposés sont déjà super bien accessibles, les
utilisateurs garderont le réflexe de taper autant de caractères précomposés que
possible, et de ne recourir aux diacritiques combinants que quand ils n’ont pas
le choix.
Je me demande… Oui, pour 99% des cas… mais il y a les tapes
accidentelles, pas si rares, et puis tous ceux qui trouvent toujours un
moyen d’utiliser ce qui est facile d’accès pour un usage différent de ce
qui est prévu. Et puis, je ne suis pas sûr que certains ne prennent pas
plaisir à vouloir cette méthode pour tout.
Dans ce sens, la stratégie des deux trois
caractères informatiques par {espace} et des combinants par {point} est totalement
ratée, car d’une elle complique la programmation, et de deux elle complique
l’écriture de nombreuses langues africaines, pourtant supportées au niveau des
lettres de base.
Je ne vois pas en quoi ça “complique” de mettre sur le point plutôt que
sur Espace. Est-ce seulement une question d’accessibilité (quoique le
point soit très accessible) ou y a-t-il quelque chose qui m’échappe ?
Certes, si tous les pays du monde
concernés par les caractères latins composés avaient fait autant de lobbying que
le Vietnam, on pourrait peut-être aujourd’hui tout écrire en précomposés, si
vraiment il y avait assez de place,
En fait je pensais plutôt à l’autre solution. Tout faire avec du
combinant. Taper “é” sur le clavier n’aurait été qu’un raccourci pour
créer en interne un chaîne e + ´.
Ainsi la gestion des chaînes eût été unifiée. Et les langages qui savent
gérer l’Unicode aurait directement implémenté des fonctions où
len("déjà") == 4, bien que tout soit fait avec des combinants.
La normalisation n’est qu’une rustine.
Pourquoi ?
Parce que c’est juste pour là pour basculer d’une méthodologie à une
autre dans un système bicéphale.
Parce que ça ne permet pas de combler tous les besoins.
Tout à fait, mais si la tâche consiste à travailler sur du français ou d’autres
langues européennes hors lituanien avec marques tonales, le problème est à la source
car ces langues ne sont pas censées être saisies avec des diacritiques combinants,
Mais, justement, certains, pas encore nombreux, se servent de ça pour
écrire en français. C’est en 2010 la première fois qu’on m’a contacté
pour me parler des combinants (je ne crois pas en avoir entendu parler
avant ça) qui posaient problème pour la reconnaissance orthographique
des mots écrits avec eux. Il a été facile de corriger le problème dans
le correcteur orthographique qui effectue en interne une conversion des
caractères combinés en précomposés.
Notons par ailleurs que la normalisation ne résout pas tous les
problèmes. La position d’un motif détecté par une expression régulière
dans un texte normalisé ne correspond pas à la position de ce même motif
dans le texte original. Autrement dit, même si on peut traiter le texte
pour analyse, les résultats renvoyés ne correspondent pas au texte à
traiter en ce qui concerne les positions.
C’est sûr, mais est-ce vraiment important ? Je n’ai pas de cas pratique en tête,
j’imagine qu’il faut corriger le texte d’origine sans y toucher par ailleurs, alors
oui ça va être dur. Mais ça me semble un cas limite.
Je ne voulais pas rentrer dans le détail, mais puisqu’il le faut…
Je conçois Grammalecte, un correcteur grammatical (CG) pour LibreOffice.
En l’état des choses, je ne peux pas proposer une correction
grammaticale correcte si on écrit avec des caractères combinants.
Examinons pourquoi:
Le CG, dans LibreOffice, n’est qu’un répondeur. LibreOffice lui fournit
du texte à examiner et attend en retour une liste d’erreurs contenant
chacune un message, une position, une longueur et éventuellement des
suggestions et une URL pointant sur des informations hors-ligne.
Mettons que le texte qui parvient au CG contient des combinants. Si le
CG le normalise, les erreurs qu’il détectera ne seront pas placées
correctement, puisque la chaîne sera modifiée, attendu que cette
normalisation ne peut se faire qu’en interne (le CG ne peut que
suggérer, il n’a aucun droit de réécrire le texte du traitement de
texte). Pareillement, si la zone d’erreur contient des combinants, le CG
ne renverra pas la bonne longueur de texte à souligner. Autrement dit,
on peut trouver les erreurs, mais leurs position et longueur seront
inadéquates.
Donc, normaliser, dans LO, ce n’est pas possible.
— Solution 1: Réécrire complètement le CG. Il n’est même pas certain que
ça résoudrait tous les problèmes. Hors de question.
— Solution 2: Réécrire toutes les regex, pour tenir compte des
combinants (ces regex sont parfois déjà bien compliquées). Envisageable,
mais pas le temps et vraiment pas motivé. C’est une usine à gaz.
— Solution 3: désactiver localement le CG s’il détecte des combinants
dans un paragraphe. Envisageable, mais comment le signaler à
l’utilisateur? C’est quand même mieux que des signalements mal placés.
— Solution 4: fournir un moyen de transformer en amont les caractères
combinés en précomposés via le formateur de texte (qui, lui, peut
modifier le texte écrit à sa guise). Envisageable, mais loin d’être
idéal, car ce n’est pas une solution automatisée et invisible.
— Solution 5: il y a peut-être une solution intermédiaire, mais le
diable est dans les détails, je ne suis pas sûr que ça fonctionnerait,
il faudrait que je prenne le temps de m’y attarder. Comme ça m’ennuie,
je n’y pense guère. Quoi qu’il en soit, les combinants compliquent la vie.
Le problème se pose pareillement pour le CG en mode serveur. S’il reçoit
du texte avec des combinants et qu’on lui demande de rendre des erreurs
avec leur position, normaliser n’est pas possible. Les combinants
comptent dans la longueur des chaînes, on ne peut pas les substituer
comme ça sans modifier ces longueurs de chaînes. Il faut faire avec.
Voilà pour l’exemple où on ne peut pas normaliser juste pour se faire
plaisir. Je ne suis certainement pas le seul qui voit ces choses d’un
œil mauvais.
C’est vrai, je ne l’avais pas remarqué. Donc en fait le bépo tente de se racheter
de son esprit de rupture avec l’azerty en gardant des caractères informatiques
par 'touche morte, espace' (et les chiffres en Maj) ? Je pense surtout à beaucoup
de symboles qu’on aurait pu laisser, mais ça ne serait plus le bépo, ce serait
l’asertuniop’ ou quelque chose comme ça. Pour être vraiment le bépo, le bépo devrait
maintenant ergonomiser TOUS les caractères informatiques qui ne le sont pas encore.
Mais pas en les proposant par 'touche morte, espace'…
Je ne suis pas sûr de comprendre pleinement cette remarque. Je n’ai pas
forcément suivi toutes les conversations. En ce qui concerne les
caractères informatiques sur des positions moins favorables, les gens
sont très divisés… je ne vois pas comment remédier à ça.
Ce qui est actuellement relégué dans des « coins obscurs », ce sont les caractères
informatiques proposés par 'touche morte, espace', le ^ et le `. Une fois qu’ils
seront sur des positions adaptées à leur usage, la position en accès direct sur
la barre d’espace sera libre pour éviter de reléguer les combinants de la barre
d’espace vers les touches point et virgule.
En ce qui me concerne, ce n’est pas du tout pour ces raisons que je ne
veux pas des combinants sur Espace. Ça n’a aucun rapport. Je suis opposé
à l’idée de trop faciliter leur accès intrinsèquement, indépendamment de
toute autre considération.
alors qu’on voudrait juste avoir un Espace avec un comportement
normal et mettre les combinants sur une place presque aussi correcte,
Bien sûr que ce comportement est encore “normal”.
J’aurais dû écrire “usuel”, ou “attendu”, parce que connu.
Olivier (Flamme)
--
Pour ne plus recevoir les messages de cette liste de discussion, envoyez un courriel avec pour destinataire discussions-REQUEST@xxxxxxxxxxx et pour sujet "unsubscribe".