J’ai finalement décidé de mettre toutes les fonctionnalités expérimentales dans une extension séparée, car pour un projet vide (un endroit seulement), ça mettait, chez moi, 8 secondes à compiler en incluant l’extension, contre 5 sans l’inclure. J’ai trouvé que ce n’était pas négligeable, alors je préfère ne pas forcer l’auteur à l’utiliser.
Mais l’extension est en ligne, avec une documentation et tout, donc si y en a que ça tente, ils peuvent essayer.
Autre changement important : on peut maintenant écrire par défaut les adjectifs après le nom plutôt qu’avant (« Le gâteau est une chose edible dans la cuisine » plutôt que « Le gâteau est une edible chose dans la cuisine »). C’est le seule truc que j’ai jugé important, sûr et qui ne risque pas de changer pour être inclus dans l’extension française.
Ne faudrait-il pas aussi mettre à jour l’ancienne extension ? Je pense notamment à Azathoth qui utilise 6G60, ou à ceux qui veulent mettre à jour leurs anciens jeux sans passer à 6L38. Parce qu’il y a des routines I6 qui ont été corrigées, des synonymes qui ont été ajoutés, etc.
C’est super d’avoir fait ça, et je suis d’accord qu’il faut réécrire le code I6, mais je pense que les modifications que tu proposes sont inutiles tant que personne ne réécrit LanguageToInformese.
Par exemple, tu as ajouté le pronom « -y », mais il ne sera jamais utilisé, car LanguageToInformese remplace le « y » en début de commande par un « -lui » en fin de commande. Le « -y » ne sera donc jamais utilisé, sauf si le joueur le tape lui-même (ce serait étonnant).
D’ailleurs, pourquoi les pronoms sont précédés par un trait d’union ? Ça causait un conflit avec les déterminants ?
Sinon, je veux bien essayer de pondre un nouveau LanguageToInformese (car j’ai à peu près compris comment ça fonctionnait), mais je ne suis vraiment pas le plus calé.
(mais j’ai remarqué qu’il y avait un « 1. » dans ton message, donc j’ose espérer que tu l’as déjà fait )
Si tu as déjà réécrit LanguageToInformese, pourquoi ne pas l’avoir dit quand je l’avais demandé ?… Et pourquoi ne pas montrer ta version ? (c’est bien beau de se plaindre que le code I6 est à refaire, mais si tu l’as déjà fait, t’as qu’à nous le montrer et je l’ajouterai dans l’extension.)
Et ça a un lien avec LanguageToInformese, car personne ne taperait le « -y » directement dans sa commande, comme je l’ai expliqué dans mon message précédent.
Pour l’histoire des traits d’union, les commandes que tu mentionnes ne les justifient pas, car c’est l’infinitif qui est utilisé, donc « y aller », pas « vas-y ».
Otto, ce serait possible de mettre une version éditable du tuto d’OpenClassrooms sur le dépôt ? Je veux bien essayer de l’adapter pour qu’on ait quand même un minimum de documentation en français.
Mule m’a fait une petite remarque concernant une traduction de la syntaxe que j’ai faite, mais je n’arrive pas à trouver comment l’améliorer. Je vous demande donc votre avis. Comme ça entre dans le tuto qui a été mis à jour, il faudrait trouver une solution assez rapidement.
Il s’agit de la traduction de la phrase permettant d’ajouter des synonymes : « Understand « arbre » as le palmier. »
Actuellement, j’ai fait une traduction sale de l’anglais : « Comprendre « arbre » comme le palmier ». Mule m’a fait remarqué que ce n’était pas très français, et je suis d’accord, donc il faut la changer. Voici ce qui a été proposé ou ce que j’ai trouvé.
Comprendre « arbre » comme étant le palmier.
Comprendre « arbre » comme faisant référence au palmier.
Comprendre « arbre » comme synonyme du palmier.
Ici, on garde l’idée générale, mais on ajoute des mots pour faire plus français. Je n’aime pas trop, parce que s’il faut taper « comme faisant référence » à chaque fois, ça devient un peu long (surtout par rapport à l’anglais, où il y a juste deux lettres…).
Considérer « arbre » comme le palmier.
Ajouter « arbre » en synonyme du palmier.
Là, on essaie de trouver un mot autre que « comprendre ». « Considérer » n’est pas trop mal, encore qu’il y a quelque chose qui me gêne.
Représenter le palmier par « arbre ».
Désigner le palmier par « arbre ».
Rien techniquement n’empêche d’inverser l’objet et le synonyme dans la phrase, donc on peut essayer de trouver une formulation dans l’autre sens, comme avec « désigner ».
Personnellement, je n’ai pas trop envie qu’il y ait « synonyme » dans la traduction, car il arrive qu’on n’ajoute pas un synonyme à proprement parler. Par exemple, dans le tuto, un moment il y a « Comprendre « interstice » comme les murs », mais interstice n’est pas véritablement un synonyme de mur, on fait ça juste pour qu’on ait pas à créer un objet « interstice » à part entière.
Donc voilà, proposez vos idées, ou dites ce que vous préférez parmi les propositions ci-dessus ! Il y a juste deux contraintes à respecter, contraintes que Graham Nelson en personne exige.
Il faut que la traduction reste le plus possible proche de l’originale, sans pour autant sonner artificielle et, selon cette citation :
On est obligé d’utiliser un infinitif (qui en français remplace l’impératif dans notre cas) et non pas une phrase déclarative au présent de l’indicatif. Donc pas de « « arbre » fait référence au palmier » ou « « arbre » signifie le palmier ».
Mes préférés c’est « Comprendre arbre comme étant le palmier » et « comme faisant référence », mais j’aime bien aussi « ajouter arbre comme synonyme du palmier ». Mais tes remarques + tout le monde ne sait pas épeler synonyme + c’est long alors bon…
(Considérer X comme Y c’est vrai que c’est un peu bizarre ; désigner ça veut dire ‹ palmier := « arbre » › dans ma tête (alors qu’on veut « arbre » := palmier’) ; représenter ça fait référence à des images pour moi.)
Cadeau de Noël ! La nouvelle version d’Inform 7, 6M62, vient de sortir (sur Mac uniquement pour l’instant) ! Je teste ça dès que possible, et je mets à jour l’extension bientôt. Ça va un peu me ralentir pour mon jeu, mais bon, je résisterai pas à l’envie de l’utiliser.
Comme Inform remplace toutes les espaces dans la source par des espaces normales, il est impossible de taper des espaces insécables directement dans son code. Le seul moyen d’en avoir est donc de passer par Unicode :
say "Bonjour[unicode 160]!";
Comme c’est un peu lourd pour l’auteur, j’ai décidé de mettre un raccourci dans l’extension. Mais je ne sais pas quel caractère utiliser.
J’ai pensé au tilde (~), car c’est ce qui est utilisé en LaTex, mais comme c’est déjà utilisé en I6 pour les guillemets droits, ça pourrait porter à confusion pour quelqu’un qui connait les deux langages.
Une autre option serait le tiret bas, car ça représente bien cette idée d’espace, tout en montrant que ce qui est de chaque côté doit rester lié. Et j’imagine que le tiret bas est plus accessible qu’un tilde.
Voilà ce que ça donnerait :say "Bonjour[~]!";
say "Bonjour[_]!";
Que préférez-vous ? Ou bien vous avez une autre suggestion ?
(J’imagine qu’il n’y a que moi qui utilise des espaces insécables, mais bon…)
Peut-être ne seras-tu bientôt plus seul , parce que dans mes commentaires envoyés aux auteurs du dernier concours, pour au moins deux des jeux (dont celui en Inform 7), j’ai signalé qu’il fallait mettre des espaces insécables parce que des signes de ponctuation (points d’exclamation, etc.) se retrouvaient tout seuls en début de ligne…
Pour être honnête, je n’ai jamais véritablement utilisé d’espaces insécables avec Inform : je les tapais bien dans ma source, mais j’avais oublié qu’Inform les convertissait en espaces normales. Aussi, il faut faire gaffe, certains interpréteurs ne les gèrent pas, comme Zoom (et donc aussi l’interpréteur de la version Mac d’Inform). C’est bon avec Quixe et Gargoyle par contre.
Et si tout le monde se met à les utiliser, alors là, hourra !
(au passage, est-ce que vous pensez qu’un post sur la typographie et autres erreurs de français que personne ne respecte serait bien, épinglé sur le forum ? Parce des erreurs de tirets vs traits d’union, de guillemets en chevrons vs droits, de œ vs oe, de majuscules non accentuées… j’en ai trouvées dans la quasi-totalité de nos FI…)
Ce serait une très bonne idée (on pourrait mettre ça aussi quelque part sur notre nouveau site quand il sera prêt), à condition d’y mettre comment faire pour respecter chacune de ces choses facilement au moins dans Inform 6 et 7 (et pourquoi pas Twine aussi), parce que visiblement ça n’a rien d’évident, d’après ce que tu dis… Il faudrait aussi prévenir s’il y a des problèmes avec certains interpréteurs, comme tu le dis (c’est vraiment gênant, ça !).
Oui, c’est ça que j’ai en tête, montrer comment éviter ces erreurs dans les différents langages. Mais je pense que la racine du problème, c’est vraiment que les gens ne connaissent pas ces règles (ou s’en fichent ?). Par exemple, quasiment tous mes profs (collège, lycée, université) écrivent au tableau avec des guillemets droits plutôt que des chevrons. On va pas me dire que c’est l’un est plus difficile que l’autre avec une craie…
Bref, j’y réfléchirai ; on peut revenir au sujet pour lequel ce fil a été destiné.
Je relance une suggestion, puisque apparemment je suis le seul qui utilise 6L38 : est-ce que ce serait une bonne idée ou bien une perte de temps de mettre à jour l’ancienne extension ? Il y a eu plein de corrections avec 6L (certaines réponses améliorées, écriture des nombres en lettres, des optimisations…) qu’il serait facile d’inclure dans l’extension 6G. Après ça m’est un peu égal pour l’instant, puisque je n’utilise plus 6G.
(je la mettrai sûrement à jour si jamais je retravaille sur un ancien projet que je n’arrive pas à porter sur 6L.)
)
Tant pis, il faudra attendre…
, parce que dans mes commentaires envoyés aux auteurs du dernier concours, pour au moins deux des jeux (dont celui en Inform 7), j’ai signalé qu’il fallait mettre des espaces insécables parce que des signes de ponctuation (points d’exclamation, etc.) se retrouvaient tout seuls en début de ligne…