Nouvelle version 2.3 de la bibliothèque francophone pour I6

Bonjour,
je jette un coup d’œil rapide sur la Version 2.3 du 05/09/2008 de la librairie française d’Inform 6.
Quelques propositions:

_Verb ‹ sortir ›: ajouter « par »
Sortir par la fenêtre

_Verb ‹ aller ›: ajouter « chez »
Aller chez le coiffeur, chez Toto

_Verb ‹ grimper ›: ajouter « dans »
Grimper dans l’arbre

_Verb ‹ poser ›: ajouter « par terre »

  • multiheld ‹ par › ‹ terre › → Drop
    (mais aussi poser au/sur le sol?!)

_Verb ‹ mettre ›: ajouter « en marche/route » et « par terre »

  • noun ‹ en › ‹ marche ›/‹ route › → switchon reverse;
  • noun ‹ par › ‹ terre › → Drop;
    (mais aussi mettre « le feu » à … ?!)

_Verb ‹ oui › : ajouter ‹ accepter › ‹ ok ›
_Verb ‹ non › : ajouter ‹ refuser ›

_Verb Actionner n’est pas gérer. Pourtant, comme « utiliser » c’est un verbe familier des joueurs d’aventure « point & click. »

_Verb ‹ manger ›
Est-ce que manger de l’ananas, manger l’orange fonctionnent?

Verb ‹ tirer › ‹ pousser ›
Est-il possible de pousser/tirer « dans » le trou?

_Verb ‹ fermer ›: ajouter « à clef/clé » (seul)
Fermer la porte à clef

[SlockSub; <lock noun (second = noun.with_key)>; ];
Verb ‹ fermer ›

  • noun ‹ à ›/‹ a › ‹ clé ›/‹ clef ›/‹ cle › → SLock;

Merci pour ces suggestions. Avant d’y répondre, je tiens à préciser que nous cherchons à faire évoluer la bibliothèque francophone de la manière la moins intrusive possible, et surtout d’une manière qui n’introduise pas une charge supplémentaire de travail pour les auteurs. Cela implique que nous ajoutons très rarement de nouvelles actions au jeu d’actions existantes. En revanche faire évoluer la reconnaissance des différentes formulations est souvent sans danger.

Il existe déjà « passer par » qui donne l’action Enter. En revanche, « sortir par » n’est pas reconnu, en effet.
Au plus simple, « sortir par la fenêtre » pourrait donner l’action <Enter fenêtre>. Ce serait donc équivalent à « passer par la fenêtre ».
La difficulté, c’est qu’on ne sait pas dire si le joueur est à l’intérieur ou à l’extérieur, mais vu qu’on reconnaît déjà « Entrer par la fenêtre » comme équivalent à « Passer par la fenêtre » indifféremment qu’on soit à l’intérieur ou à l’extérieur, je ne vois pas de raison de refuser cette formulation. Je l’ajoute donc, ainsi que « sauter par la fenêtre ».

Peut-être faudrait-il juste afficher un petit message si une telle action est utilisée ?
Exemple d’ordre incohérent, rattrapé par le message entre parenthèses :

Qu’en pensez-vous, les uns et les autres ?

Ça me semble trop relever d’un besoin ponctuel pour être intégré par défaut à la bibliothèque, surtout que je ne vois pas à quelle action existante on pourrait rattacher cette formulation. À mon avis c’est à laisser faire aux auteurs au cas par cas (quitte à réaliser une petite extension si tu vois plus précisément comment elle devrait se comporter).

Bien vu, j’ajoute.

Je me rappelle d’un auraes qui me disait qu’il ne fallait pas tout chercher à gérer avec les prépositions :stuck_out_tongue:
J’ajoute la grammaire pour « par terre » et pour « au sol ». « Sur le sol » était déjà géré car l’action PutOn sur l’objet d_obj donne l’action Drop au final.

.

  • OK pour mettre en marche/route (mais pourquoi reverse dans la grammaire ?).
  • OK pour mettre par terre.
  • OK pour mettre le feu (et mettre feu).

Il faudrait vérifier que les actions Yes et No sont vraiment utilisées dans ce sens (je ne les ai jamais utilisées personnellement)

OK, c’est maintenant un synonyme de utiliser.

A priori oui.

Non, mais j’ai du mal à voir les applications pratiques. Peux-tu développer ?

Je n’ai pas testé, mais il me semble qu’inform se débrouille déjà pour trouver la bonne clef si on l’a dans l’inventaire, non ? Si ce n’est pas le cas, tu peux noter une demande d’évolution sur flyspray pour ne pas qu’on oublie d’étudier cette proposition : informfr.tuxfamily.org/flyspray/ sur le projet informfr. L’inscription nécessite une validation de notre part mais elle sera rapide.

ces suggestions me semblent pleines de bon sens. Je suis en train de travailler sur Inform 7 en ajoutant le plus de tout cela.

Cela me semble très bon. Ne pas oublier que si quelqu’un tape « sortir par la fenêtre » alors qu’il est à l’extérieur, il a délibéremment tapé une commande un peu absurde. Transformer cela en « passer par la fenêtre » permet de montrer que l’interpréteur n’est pas trop bête, et je ne vois pas dans quel cas cela pourrait déranger.
Par contre maintenant que j’y pense, cela va donner quoi avec une porte ? « Enter door » n’est pas reconnu il me semble.

comme Stormi, je pense que c’est trop ciblé pour être utile : même si on l’ajoute, cela ne permettra pas d’implémenter dans le jeu une commande magique qui fera aller directement le joueur dans la bonne direction. Par contre on peut envisager de rajouter un « aller chez [topic] », qui dirait une phrase type genre « veuiller indiquer une direction avec les points cardinaux ». Mais si un auteur veut l’implémenter pour son jeu, cela lui fera plus de souci (remplacement de bibliothèque). Personnellement cela ne me dérangerait pas que cela soit rajouté, à voir.

C’est tentant, à condition de trouver un message qui reste valable quel que soit le mode de déplacement choisi par l’auteur dans son jeu : points cardinaux, avancer/reculer (comme dans Gun Mute), directions sur un navire, …

bonjour,

< Entrer chez > plutôt que < Aller chez >.

Verb ‹ asseoir › ‹ allonger › ‹ coucher ›
! * ‹ vous › → GoIn ! s’asseoir
Pourquoi ne pas renvoyer tout les VagueGo, VagueDig… sur un même VagueSaisie qui demanderait de préciser/compléter la saisie.
//-----------------------
Avant de modifier la grammaire d’un verbe il faut systématiquement vérifier son fonctionnement dans les fichiers verblibm.h et french.h. Pourquoi?

[code]Verb ‹ regarder ›

  • noun → Examine
  • ‹ sur › noun → Examine
  • ‹ dans ›/‹ atravers › noun → Search
  • ‹ sous › noun → LookUnder
  • ‹ derriere › noun → Search ! à la place de Turn[/code]
    et renvoient au même verbe: Examiner. Or ce sont deux actions très differentes.
    La routine [SearchSub;(voir plus bas)] gère notamment les attributs supporter container transparent.
    Donc « sur » pourrait être fusionner avec * ‹ dans ›/‹ atravers ›/‹ sur › noun → Search
    Et « derriere » pourrait être fusionner avec * ‹ sous ›/‹ derriere › noun → LookUnder

[code]
//----------- Fichier verblibm.h
[ LookUnderSub;
if (location == thedark) return L__M(##LookUnder, 1);
L__M(##LookUnder, 2);
];
[ SearchSub f;
if (location == thedark) return L__M(##Search, 1, noun);
if (ObjectIsUntouchable(noun)) return;
f = VisibleContents(noun);
if (noun has supporter) {
if (f == 0) return L__M(##Search, 2, noun);
return L__M(##Search, 3, noun);
}
if (noun hasnt container) return L__M(##Search, 4, noun);
if (noun hasnt transparent && noun hasnt open) return L__M(##Search, 5, noun);
if (AfterRoutines() == 1) rtrue;

if (f == 0) return L__M(##Search, 6, noun);
L__M(##Search, 7, noun);

];

//----------- Fichier French.h
LookUnder: switch (n) {
1: « Mais il fait noir ! »;
2: « Vous ne trouvez rien d’intéressant. »;
}
Search: switch (n) {
1: « Mais il fait noir ! »;
2: "Il n’y a rien sur ", (the) x1, « . »;
3: print "Sur ", (the) x1, « , vous voyez « ;
WriteListFrom(child(x1),
TERSE_BIT + ENGLISH_BIT + CONCEAL_BIT);
« . »;
4: if (x1 has animate) « Tenez donc vos mains tranquilles. »;
else « Vous ne trouvez rien d’intéressant. »;
5: « Vous ne pouvez pas voir à l’intérieur, puisque « , (the) x1, " « ,
(isorare) x1, " fermé »,(es) x1, ». »;
6: print_ret (The) x1, " « , (isorare) x1, " vide »,(s) x1, ». »;
7: print (The) x1;
if (x1 has pluralname) print " contiennent ";
else print " contient ";
WriteListFrom(child(x1),
TERSE_BIT + ENGLISH_BIT + CONCEAL_BIT);
« . »;
}[/code]
Il me semble que les messages par défaut devraient être le plus neutre et le plus sobre possible. Ils risquent d’entrer en conflit avec le « style » du jeu. Si le concepteur du jeu doit revoir tous les messages par défaut cela n’a plus de sens.
Exemple de message par défaut:

« Il est malheureusement fermé. »
Pourquoi « malheureusement »; on ignore le contexte du jeu; c’est peut-être une chance qu’il soit fermé!
« Il est fermé. »
Autres exemples:
"Vous ne pouvez pas sortir " / « Vous ne pouvez pas aller par là. »
"Vous êtes incapable de gravir " / "Vous êtes incapable de descendre par "
Peut-être faut-il faire des choix dans les formulations, pour que les réponses soient plus homogènes. « Vous ne pouvez pas… (ou) Vous êtes incapable de… » (« incapable » est un mot assez antipathique!)
« Vous ne pouvez pas gravir… » / "Vous ne pouvez pas descendre par… "

Autre exemple:
« Vous chantez un morceau de la première chanson qui vous vient à l’esprit. »;
Cette réponse est trop contextuelle pour être un message par défaut. Contexte dont on ne connait rien.

Bonjour Auraes.

Le problème reste le même : aucune action ne convient. Imaginons que je suis à côté d’un ménestrel : si je tape « Entrer chez le menestrel », quelle action cela devra-t-il donner ? Enter ? Dans ce cas inform va comprendre que je veux entrer dans le ménestrel, cela n’est pas souhaitable. Une autre action que Enter est donc nécessaire, et cela relève soit d’une extension, soit d’un développement à faire par l’auteur d’un jeu qui veut gérer cette formulation.

J’ai regardé : les messages sont très différents et bien plus clairs dissociés que tous dans un même VagueSaisie.

Pour regarder derrière, j’ai fait cette suggestion sur le fil dédié aux discussions sur la bibliothèque francophone : https://forum.fiction-interactive.fr/t/bibliotheque-french-h-pistes-damelioration/179/1 mais nous n’avons pas encore atteint une décision, c’est pourquoi la proposition est toujours ouverte sur flyspray : informfr.tuxfamily.org/flyspray/ … task_id=56

Pour regarder sur, il faut qu’on étudie la question, donc j’ai ouvert aussi une demande sur flyspray : informfr.tuxfamily.org/flyspray/ … task_id=60

D’accord sur le fait que les messages doivent être le plus neutre possibles.
Cependant le message de cet exemple intervient lorsqu’on tente de prendre un objet d’un conteneur fermé. Le malheureusement, quoique un peu fort, est lié au fait que le joueur a manifesté par une commande l’intention de prendre cet objet, or c’est (malheureusement) impossible.

Je pense que « incapable de » avait dû être retenu au départ comme traduction de « unable to », il faudrait voir au cas par cas, dans le contexte et en comparant aux messages en anglais, si c’est toujours pertinent.
Quand aux réponses homogènes, j’ai l’opinion inverse : je suis pour des messages hétérogènes car cela ennuie moins vite.

Tiens, ça devait être de moi ça, j’avais trouvé ce message plus neutre que le message précédent « Vous chantez abominablement faux. ». Pourquoi est-ce trop contextuel ? Et si ça l’est, que mettre à la place ?

La librairie anglaise le gère. (look on → Search)
Verb ‹ look › ‹ l// ›
* ‹ inside ›/‹ in ›/‹ into ›/‹ through ›/‹ on › noun → Search

En effet « look on » renvoie Search. J’ai effectué la correction.

J’ai noté la présence de l’extension " temporiser.h " dans les dépots.

Pourtant les fonction KeyDelay( time ), à peu près équivalente, existe depuis la version 6/11 de la librairie pour Inform6 (Z-machine et Glulx).
(ainsi que la fonction KeyCharPrimitive(),…)
Simplement pour rappeler de penser à lire le document " Inform Release Notes " qui énumère les apports de la version 6/11 de la librairie pour Inform6.
http://www.inform-fiction.org/source/library/functions.html
ReleaseNotes.pdf :
http://www.ifarchive.org/indexes/if-archiveXinfocomXcompilersXinform6.html

Quelques suggestions - et critiques - pour les librairies:
/*** French.h ***/
il y a une espace entre les deux mots?!

Constant BUT1__WD     = 'mais pas';

Pour les menus : P aligné sous Q

Constant PKEY__TX = " P = précédent"; Constant QKEY1__TX = " Q = retour"; Constant QKEY1__TX = " Q = retour";
Majuscule accentuée

Constant RKEY__TX = "ENTREE = lire sujet"; Constant RKEY__TX = "ENTR@'EE = lire sujet"; ! ENTRÉE
La présence de la propriété ‹ article › pour les objets CompassDirection ne semble pas justifiée.

CompassDirection -> in_obj "intérieur" with door_dir in_to, name 'dedans' 'interieur', article "l'"; CompassDirection -> in_obj "intérieur" with door_dir in_to, name 'dedans' 'interieur',
ê î manquent: ( ae oe Î…)!?

[ LanguageContraction text; if (text->0 == 'a' or 'e' or 'é' or 'è' or 'i' or 'o' or 'u' or 'h' or 'A' or 'E' or 'I' or 'O' or 'U' or 'H') return 1; return 0; ];
Et la table de pronoms ne fonctionne toujours pas.

/*** FrenchG.h ***/
Ajout de la préposition ‹ contre › : jetter, lancer, fraper, pousser… ‹ contre ›
Ajout de Nager ‹ vers ›
Ajout de ‹ mourir ›, présent dans la lib anglaise, comme synonyme de ‹ Quit ›

Verb meta 'quit' 'q//' 'die' *      -> Quit;

Un peu de rigueur dans la programmation et la lisibilité des documents serait la bien venu.
Au hasard :

[ TexteComprenantEt mot ok; ! pourquoi ok?! ok = false; do { mot = NextWordStopped(); if (mot == 'et') ok = true; } until (mot == -1); if (ok) return GPR_PREPOSITION; else return GPR_FAIL; ]; [ TexteComprenantEt mot; do { mot = NextWordStopped(); if (mot == 'et') return GPR_PREPOSITION; } until (mot == -1); return GPR_FAIL; ];
Il est possible - il me semble - de déployer une grammaire sur plusieurs lignes, ce qui permet de garder les " → Verbe " alignés. Ce qui facilite la lecture, surtout celle de l’impression papier du document.

[code]Verb ‹ parler › ‹ discuter › ‹ causer ›

  • ‹ a ›/‹ à › ‹ propos › ‹ de ›/‹ du ›/‹ des ›/‹ d^ › topic
    ‹ avec ›/‹ à ›/‹ a ›/‹ au ›/‹ aux › creature → Tell reverse
    ;[/code]
    J’ouvre mon bloc avec « Verb » et je le referme avec « ; » ce qui facilite les ajouts, corrections… plus besoin de déplacer sans cesse le point-virgule.

Verb 'xxx' * -> Xxxx ; Verb 'yyy' * -> Yyyy * -> Zzzz ;
Il serait souhaitable d’indiquer dans l’entête des librairies l’encodage avec lequel les documents ont été sauvegardés ( UTF-8, ISO-8859-1, …)

Appeler la version 2.3 des librairies une version « stable » c’est pas un peu abuser !?
http://fr.wikipedia.org/wiki/Phases_de_développement

Si je lis l’article de wikipedia cité, je trouve « Quand un logiciel peut accomplir toutes les tâches prévues, il arrive à sa version « finale » ou « stable ». »

Il me semble qu’inform et les bibliothèques associées peuvent parfaitement accomplir toutes les tâches pour lesquelles ils ont été prévus.
Bien entendu il est toujours possible d’améliorer, c’est ce qui est fait continuellement, mais il faut bien décider de tester et figer des versions à un moment donné.

Pour le coup de "J’ouvre mon bloc avec « Verb » et je le referme avec « ; » " cela me semble une bonne idée. On peut le rajouter au fur et à mesure.

Pour l’alignement des menus, il me semble que c’est justement corrigé par rapport à avant, pour que l’alignement soit fait tout à droite.

Pour ENTRÉE en majuscule, on peut l’écrire tel quel. C’est corrigé.

Pour l’article de « l’intérieur », je pense que cela a été ajouté pour pour écrire « l’intérieur » en entier. Je n’ai pas testé avec ou sans.

Pour « mourir », je ne vois pas trop l’intérêt. Si je joueur veut quitter, qu’il taper « quitter », on ne va pas non plus encourager le suicide :slight_smile: De toute façon cela a été retiré dans la version anglais pour inform 7.

pour « il y a une espace entre les deux mots?! » je ne sais pas à quoi sert ce « mais pas », mais de toute façon cela s’écrit bien ainsi.

pour « LanguageContraction » à priori c’est valable seulement pour le début des mots. On peut effectivement rajouter ê (ce que je viens de faire). Pour les « oe » il me semble qu’inform gère cela très mal, donc on ne peut pas l’utiliser dans un jeu de toute manière.

Pour « nager vers », aucun verbe connu ne gère cela de base, alors le rajouter dans les entrées possibles ne servira pas je pense, ou alors il faudrait l’utiliser en synonyme de « go », avec les contraintes que cela implique. « Swim » a d’ailleurs été retiré d’inform 7.

Pour ‹ contre ›, je peux le rajouter.

Pas la peine de préciser l’encodage de ces fichiers, Inform 6 ne supporte pas UTF-8 de toute façon, et il faut impérativement rester en iso8859.

Merci de tes remarques, propositions d’amélioration, et critiques, par contre on aimerait bien voir un de tes jeux à l’occasion :wink:

Oui, mais « Q » n’est plus aligné sous « P ». Avec < Constant QKEY1__TX = " Q = retour"; > l’alignement reste à droite mais « Q » saligne sous « P », ce qui me semble plus gracieux.

ou ou ne change que le milieu dans lequel on évolue.

Cela semble inutile, ainsi que pour Est, Ouest…

Non, c’est une erreur. Le parser décompose la saisie en mots par les espaces qui la compose. Il comprendra « mais », « pas »; certainement pas « mais pas ».

Et moi les votres. :stuck_out_tongue:

J’ai ajouté à ma librairie French.h à l’Array LanguageDescriptors table : au aux du

Array LanguageDescriptors table 'au' $$100000100000 DEFART_PK NULL 'aux' $$000110000110 DEFART_PK NULL 'du' $$100000100000 DEFART_PK NULL ; Il est possible aussi de les transformer au niveau de la saisie :
‹ au › devient ‹ à › ‹ le ›
‹ aux › devient ‹ à › ‹ les ›
‹ du › devient ‹ de › ‹ le ›
‹ des › (‹ de › ‹ les ›) et déjà considéré comme un article indéfini pluriel dans l’Array LanguageDescriptors table.
Après tout ce sont des articles. Plus besoin des ‹ au ›/‹ aux › ‹ du › dans la grammaire. (En Beta Test :mrgreen: )

Getoff n’est pas utilisé dans FrenchG.h !?
Pourtant, < descendre de/du/des noun > devrait renvoyer vers un '->GetOff ’ et non pas vers un ‹ ->Exit ›.

Verb 'descendre' * 'de'/'du'/'des' noun -> Exit Verb 'descendre' * 'de'/'du'/'des' noun -> GetOff
Ce qui est cohérant avec les routines Inform :

Verblibm.h : [ GetOffSub; if (parent(player) == noun) <<Exit>>; L__M(##GetOff, 1, noun); ]; French.h : GetOff: "Mais vous n'êtes pas sur ", (the) x1, " en ce moment.";

Pas de problème !

Pour l’instant je n’en ai qu’un petit (à part Ascenseur qui n’était qu’une démo/exercice) :

ifiction.free.fr/index.php?id=jeu&j=036

La version originale : retourne GPR_PREPOSITION pour tout un texte dont un des mots au moins est « et ».
La version proposée : retourne GPR_PREPOSITION dès qu’il rencontre le mot « et », laissant en plan la fin de la saisie que le parser ne saura pas évaluer.
La variable ok sert justement à ça, garder en mémoire le fait qu’on a trouvé le mot « et » pour répondre en conséquence une fois l’ensemble de la proposition analysée.
Remarque : ce qu’il faudrait en réalité c’est réussir à ce qu’une grammaire de type : « * noun ‹ et › noun » fonctionne, c’est certainement possible d’une manière ou d’une autre.

(remarque : si je tutoie ce n’est pas par manque de respect mais simplement parce que sur le forum on se tutoie à peu près tous)
Je vais être franc Auraes : une partie non négligeables de tes propositions est pertinente et intéressante, et nous permet même d’aller plus loin que notre connaissance actuelle d’inform. J’ai cependant un problème avec ta manière de les proposer, j’espère que ce n’est qu’une impression due à un style un peu lapidaire : il donne l’impression que tu assènes une liste de Vérités (avec un grand V), avec la certitude que ce qui a été fait avant toi est faux et que tes proposition sont LA seule manière de faire.
Je sais que notre travail sur les bibliothèques d’inform est loin d’être parfait, et je te suis reconnaissant de nous pointer les erreurs que nous pouvons faire (ou les points que nous n’avons pas encore pris la peine d’améliorer). Cependant je dois réellement faire un effort pour passer outre la première mauvaise impression que me font certains de tes messages pour réussir à réfléchir aux propositions qu’ils contiennent de manière objective.

Cordialement

Samuel

Question : quel est le sens de « pousser contre » ? PushDir est une action qui consiste à pousser vers une direction (nord, sud…) afin de déplacer un objet d’une salle à l’autre.

exact, je ne vois pas trop ce qui pourrait déroger à cela…
Mais d’un autre côté, c’est indiqué « noun », aussi peut-être que l’on peut utiliser cela comme « pousser le meuble contre la porte », et interpecter cela avec pushdir ? On peut le laisser, cela ne dérange pas, éventuellement faire un test.
[EDIT : je viens de tester, la remarque est pertinente, car on peut en effet utiliser cela ainsi, pousser un objet contre un autre. J’ai inclus cela dans l’intro ifiction, mais je n’arrive pas à commiter pour le moment]

Par contre pour « frapper », cela peut être nécessaire : « frapper contre la porte / contre le volet » par exemple.

Oui tout à fait d’accord pour les autres verbes utilisant la préposition ‹ contre ›.

J’ai peut-être dit une bêtise pour PushDir, on dirait qu’il n’y a pas de contrainte sur le second objet. Dans ce cas, ‹ pousser contre › est valable.

J’ai relu le DM4 (inform-fiction.org/manual/html/s15.html) et testé : si on fait un objet qui est déplaçable de lieu en lieu (auquel cas il faut faire appel à la routine AllowPushDir(), voir l’exemple du DM4), alors il est vérifié que la destination est bien une direction. Pousser la balle au nord fonctionnera, pousser la balle contre le frigo renverra « Ce n’est pas une direction ». Si on accepte cette modification cela aura donc plusieurs conséquences (pas gravissimes, mais suffisantes pour que je sois pas entièrement pour, même si je ne sais pas encore non plus si je suis contre) :

  • en standard un objet ne peut pas être poussé dans une direction ET poussé contre un objet. C’est l’un ou l’autre, au choix de l’auteur (selon qu’il fait appel à AllowPushDir ou non). Ou alors c’est à l’auteur de tester d’abord dans la routine before si second est une direction.
  • si dans un jeu on a à la fois un objet qui peut être poussé dans une direction et un qui doit être poussé contre un objet, ce ne sera pas clair pour le joueur : dans un cas on lui dit « Ce n’est pas une direction » quand il veut pousser un objet contre un autre, dans l’autre cas c’est précisément l’action qui est attendue de lui. Le problème se pose aussi d’un jeu à l’autre, si l’un retient une manière de faire et l’autre une autre. Au sein d’un même jeu, ce sera à l’auteur de garder une cohérence.

Je suis d’avis mitigé, mais tout de même plutôt contre son ajout en standard dans la lib, sachant qu’il reste possible simplement de redéfinir le verbe pour l’auteur qui en a besoin. Cependant, ce n’est pas un avis définitif, notamment parce qu’il semble que l’action ait été prévue pour accepter n’importe quel noun, au départ.

En effet ça ne peut pas marcher (et j’ai testé, ça ne marche pas) car ces constantes ne doivent contenir qu’un mot. On pourrait mettre ‹ maispas › et supprimer l’espace entre les deux dans LanguageToInformese, mais n’y a-t-il pas des cas où cela risque de poser problème ?

Je ne crois pas que P = précédent et Q = retour soient l’un au dessus de l’autre dans les menus, il me semble que l’un est à gauche et l’autre à droite. Si quelqu’un veut tester, mais on avait déjà fait en sorte que ça rende pas trop mal.

C’est possible, mais n’en étant pas sûr, je préfère qu’on n’y touche pas à moins d’avoir la preuve que cela cause un bug.

Peux-tu être plus explicite ?

Là il s’agit d’une question de goûts, moi les choses me semblent très bien comme elles sont, tant qu’au sein de chaque verbe les « -> » sont alignés (avec des espaces uniquement car sinon on a des mélanges tabulations/espaces qui dépendent de l’éditeur utilisé et cassent la mise en forme.
Pour le point virgule en début de ligne, ça se discute. Le plus important c’est de garder la même convention pour tous les verbes. En l’occurrence, on a déjà des points virgule en fin de la dernière ligne de grammaire, et on ne modifie pas assez souvent les grammaires pour que l’argument du « plus facile à modifier » soit réellement important. De toutes façons en cas d’erreur ça ne compile pas et on est censés vérifier que ça compile avant tout commit.

Bizarre, en effet, je ne sais pas pourquoi il n’a pas été repris en français, il vaudra regarder ça car cela peut toucher la grammaire de plusieurs verbes, voire même toucher la modification récente faite sur « se lever ».