ah zut, cochonnerie d’encodage, il était passé en utf8. Est-ce que tu as changé autre chose dessus ? Parce qu’entre temps j’ai fait d’autres modifs.
J’ai fait le commit il y a quelques minutes, j’ai juste ajouté un guillemet manquant en fait.
ah oui, en remodifiant l’encodage et en gardant une sauvegarde, j’ai vu cela aussi, je ne sais pas ce que j’ai fait. J’ai recommité avec les autres modifs. Merci.
Pour le « parler avec », je viens de trouver, il me semble que j’avais remarqué cela auparavant, mais j’avais oublié.
J’avais redéfini le verbe ainsi :
Si on met en dernier « parler avec [someone] » , cela dit automatiquement « parler avec » dans la phrase de correction. C’est bien fait quand même !
Ah oui, ce serait parfait comme ça !
Je pense que l’intégration des différentes versions de la bibliothèque est une priorité, car j’ai déjà repéré au hasard de mes observations quelques divergences entres les différentes versions de la lib (sans parler des différences inform6 / inform7).
Pensez-vous qu’il soit réalisable de tout mettre en un seul fichier (pour tous les temps et personnes gérés, et aussi inform6/7), ou, si on est obligé d’avoir plusieurs versions comment gérer les évolutions en parallèle ?
pour le moment je fais tout à la main, et il est possible qu’il reste des divergeances. Si tu en trouves de trop graves, tu peux les corriger et le signaler.
Je pense qu’il doit être possible de tout regrouper dans une seule bibliothèque. Mais ce qui me dérange un peu, c’est qu’apparemment ils ne l’ont pas fait dans la version anglophone. En fait on a l’impression qu’ils ont laissé tombé Inform 6, tout en restant en beta de Inform 7. J’ai peur aussi qu’ils fassent de grosses modif dans le futur au niveau des bibliothèques existantes, c’est pour cela que je ne me suis pas trop investi dans toutes les traductions (les multiples petits fichiers qui font que certaines phrases dans les jeux francophones I7 sont en anglais)
Mais il me semble aussi que cela serait bien d’avoir une unique branche. (Mais les Espagnols ont toujours plusieurs branches par exemple)
Pour rajouter un verbe, existant ou pas dans la version anglais, j’indique cela dans l’extension « French » :
[code]Understand the command « swim » as something new.
Swimming is an action applying to nothing. Understand « swim » or « dive » or « nager » or « plonger » as swimming.
Carry out swimming:
if using the French Language option, say « Il n’y a pas assez d’eau pour nager dedans. »;
if using the French 3PSP Language option, say « Il n’y avait pas assez d’eau pour nager dedans. ».[/code]
Ainsi que ça dans mon fichier FrenchGN11.h :
#ifndef NI_BUILD_COUNT;
Verb 'nager' 'plonger'
* -> Swim;
#endif; ! NI_BUILD_COUNT
En fait pour la plupart des verbes ils ont été courtcircuité et remplacé par une définition en langage I7, par contre ils semblent avoir gardé certaines déf. pour les meta verbes etc.
J’ai beau essayer, je n’arrive pas à me convaincre que les choix qui ont été faits dans inform 7 ont été judicieux. J’espère que l’avenir me montrera que je me trompe. Je serais intéressé à plus long terme aussi par tester tads 3 bien que l’absence d’un client sous linux qui gère le son et l’image me semble génant.
Pour moi le langage idéal serait un langage qui garde les forces d’Inform 6, les améliorations d’inform 7, et codé comme un langage moderne :
- gestion puissante des chaînes de caractères et autres types de données (les bidouilles qu’on est obligés de faire dans LanguageToInformese sont dignes d’il y a 20 ans !)
- découpage net entre la logique liée à la modélisation du monde, et celles liées au parser et aux différentes langues.
J’avoue rester sur ma faim avec les langages existants.
Inform 7, que je n’ai pas réellement testé, apporte-t-il des plus de ce côté là ou est-ce plutôt un pas en arrière du point de vue des traductions ?
Je trouve malgré tout que l’on a un système qui ne va pas trop mal, en comparaison des premiers jeux où il y avait seulement 2 mots à interpréter, surtout compte tenu de la différence de difficulté entre l’anglais et le français.
Bien sûr cela pourrait être toujours mieux et on ne peut pas se contenter uniquement de l’existant, néanmoins I7 propose des choses très intéressantes, mais je ne vais pas revenir là dessus. Notamment Inform 7 gère les expressions régulières :
inform-fiction.org/I7/doc321.html
Je ne sais pas si cela pourrait aider de notre point de vue, mais on peut le garder sous le coude (attention car cela bouffe pas mal de ressources dans la machine virtuelle). Pour la traduction, vu que c’est une surcouche de I6, cela ne change pas grand chose à tout le travail qui a été fait dans le fichier french.h
Le pas en arrière c’est que si I6 était bien prévu pour les traductions, on dirait qu’ils ne se sont pas trop décidé au niveau de I7, cf. les anglicismes que l’on a parfois vu qu’ils ont éparpillés des chaînes de caractères là où cela n’avait rien à faire. Sarganar a relevé de telles phrases dans ces fichiers :
Actions.i6
ChooseObjects.i6
Main.i6
Printing.i6
Relations.i6
Tables.i6
Times.i6
Verbs.i6
parserm.h
verblibm.h
Parfois c’est juste une phrase qui vient pourrir le fichier. J’ai déjà posé la question 2 fois sur le forum RAIF sur ce qu’ils comptaient faire dans le futur, je n’ai toujours pas eu de réponse.
Faudrait juste qu’ils y aient de plus en plus de jeux en Inform 7, les Espagnols se sont bien lancés (ils ont 6 jeux déjà : wikicaad.net/Categoría:Aventuras_Inform_7), mais pas trop les Italiens par exemple. Mais j’ai bon espoir quand même 
Petit bug également dans la bibli de I6, au niveau du menu (comme dans Aventure, acessible via « aide »).
La mention « Q = retour » n’est pas au même niveau que « P = précédent ». Bon vous allez dire que je chipote mais bon… 
effectivement, on a :
Constant NKEY__TX = "S = suivant";
Constant PKEY__TX = "P = précédent";
Constant QKEY1__TX = " Q = retour";
Constant QKEY2__TX = "Q = menu précédent";
Constant RKEY__TX = "ENTREE = lire sujet";
mais je ne vois pas comment l’espace avant provoque ce décalage. Là à part aventure, je n’ai rien d’autre à compiler avec, alors je ne sais pas si cela corrigera ou amplifiera le problème. (il faudrait d’ailleurs envisager de recompiler aventure avec les améliorations apportée depuis, peut-être que l’on peut envisager de le mettre sur le svn ?)
Je me suis aperçu de ce problème car j’ai ajouté ce menu dans l’île du phare. J’ai essayé de corriger mais je n’y suis pas arrivé car ce texte fait partie de la bibliothèque… Pourquoi cet espace ?
S = suivant P = précédent
ENTREE = lire sujet Q = retour je ne sais pas.
Pourras-tu éditer le texte de la bibliothèque french.h, recompiler la version zcode de l’île, et nous dire si cela corrige le problème, comme cela on le modifiera dans la version officielle ?
Ok j’essaye dans la semaine et je vous tiens au courant.
Je crois qu’on devrait faire un tag de la version 2.2 afin qu’elle puisse être utilisée à la place de la 2.1 buggée par les auteurs, avant de continuer à faire des modifications sur le code (je vois que « 2.2 » est déjà marqué dans le code, mais comment faire la distinction entre la 2.2 de la révision x et la 2.2 de la révision y ?).
Le principe du tag, c’est de figer une version de « release ».
Si vous voulez je « taggue » la version actuelle et on décrète que c’est la 2.2, puis on continue de travailler sur la future 2.3.
Par ailleurs, j’aimerais utiliser subversion sur tuxfamily pour l’extension scenic5sens.h qu’on avait utilisée dans lieux communs. Est-ce possible ?
Ça doit être un oubli de la part du traducteur de la bibliothèque qui contient l’aide. Je viens d’essayer la version Inform en anglais d’Adventure, et dans l’aide, on a la mise en page :
P = previous
Q = resume gameAlors que la traduction française a :
P = précédent
Q = retour Autrement dit, le traducteur a pris la mise en page originale sans tenir compte du fait que « retour » a 5 caractères de moins que « resume game » et « précédent » a 1 caractère de plus que « previous ».
bien vu Eriorg !
Ok Stormi pour marquer cette version actuelle comme la 2.2. Par contre je ne sais pas comment on fait, si tu veux le faire c’est d’accord, et tu nous expliqueras comment le faire pour la suite.
Pour scenic5sens.h c’est une bonne idée, est-ce qu’on peut le mettre ainsi ou bien il faut l’adapter au temps de la version par défaut ?
Peut-être on peut le mettre dans le dossier « tools », avec le reste, à moins que tu aies une autre idée de réorganisation complète de l’espace, mais je préférais attendre que l’on réussisse à rejoindre les versions 6 et 7 en utilisant moins de fichiers. (pour la version grammar cela ne devrait pas trop poser de problème, c’est pour l’autre que c’est plus délicat)
Voici une proposition de structure pour le dépôt inform-fr.
J’ai mis les outils I6 et I7 à part, et créé deux tags (2.1.1 et 2.2) pour inform_fr
Je ne savais pas trop pour le fichier « French » du répertoire Eric Forgeot si je devais le mettre dans outils ou le laisser avec la lib, donc je l’ai laissé.
[code][sam@localhost informfr]$ tree
.
|-- informfr
| |-- branches
| |-- tags
| | |-- 2.1.1
| | | |-- French.h
| | | -- FrenchG.h | | – 2.2
| | |-- I6
| | | |-- French.h
| | | |-- French1PSP.h
| | | |-- FrenchG.h
| | | -- FrenchG1PSP.h | | |-- I7 | | | |-- Eric Forgeot | | | | – French
| | | |-- FrenchGN11.h
| | | |-- FrenchN11.h
| | | |-- FrenchN11_3PSP.h
| | | |-- MainFR.i6 → MainFR5J39.i6
| | | |-- MainFR4X60.i6
| | | |-- MainFR5G67.i6
| | | |-- MainFR5J39.i6
| | | |-- Selector.h
| | | |-- convertir_apostrophes.sh
| | | |-- install_inform7_french.sh
| | | -- install_inform7_french_win.bat | | |-- lisezmoi_InformLibFR.txt | | – makefile
| -- trunk | |-- I6 | | |-- French.h | | |-- French1PSP.h | | |-- FrenchG.h | | – FrenchG1PSP.h
| |-- I7
| | |-- Eric Forgeot
| | | -- French | | |-- FrenchGN11.h | | |-- FrenchN11.h | | |-- FrenchN11_3PSP.h | | |-- MainFR.i6 -> MainFR5J39.i6 | | |-- MainFR4X60.i6 | | |-- MainFR5G67.i6 | | |-- MainFR5J39.i6 | | |-- Selector.h | | |-- convertir_apostrophes.sh | | |-- install_inform7_french.sh | | – install_inform7_french_win.bat
| |-- lisezmoi_InformLibFR.txt
| -- makefile – outils
|-- divers
| |-- branches
| |-- tags
| -- trunk | |-- I6 | | |-- FrenchAlpha.h | | |-- Gtoolbar-fr.h | | |-- JustEnoughGlulx-fr.h | | |-- banner-fr.h | | |-- dirsmap-fr.h | | |-- moveclass-fr.h | | |-- notepad-fr.h | | |-- npc_engine-fr.h | | |-- npc_wait-fr.h | | |-- smartcantgo-fr.h | | |-- waittime-fr.h | | – whowhat-fr.h
| -- I7 | |-- Locksmith-fr | – Simple Chat fr
-- scenic5sens |-- branches |-- tags | – 1.0
| -- I6 | – scenic5sens.h
-- trunk – I6
`-- scenic5sens.h
26 directories, 54 files
[/code]
Edit : avantages de cette structure :
- la fusion I6/I7 pour certains fichiers reste possible à l’avenir
- on peut figer une version de la lib sans lui associer obligatoirement les divers outils indépendants, et inversement.
Remarque : scenic5sens a son propre répertoire contrairement aux autres outils, mais rien n’empêche de créer un répertoire par outil important donc on veut distinguer le codage (avec la structure proposée, il est actuellement impossible de figer un des outils sans figer les autres du même répertoire).
Pour les outils I7, il faut normalement les laisser dans un dossier qui s’appelle « Eric Forgeot ». D’un autre côté lors de l’installation ils vont se mettre là où il faut, alors si on peut éviter un dossier pourquoi pas. Mais sur le site d’inform ils se trouvent néanmoins dans le dossier avec le nom. Bon, tant qu’à faire, si c’est juste pour mettre ces outils (qui ne sont que des traductions) qui ne vont pas évoluer énormément (sauf évolution de la v.o), je pense qu’on peut les mettre dans le même dossier que French (qui est un élément vraiment nécessaire aux bibl. pour I7)
pour scenic5sens.h peut-être que cela n’est pas la peine de préciser I6 car il sera forcément pour I6, à mon avis cela aurait été plus simple de le laisser dans le tronc commun avec les autres outils, mais si tu veux bcp travailler dessus et garder une version indépendante c’est comme ça t’arrange. Les autres outils (traductions etc) déjà existants ne vont plus bcp évoluer quant à eux à mon avis.
De toute façon on continue encore à travailler sur les versions trunk c’est ça, les tags c’est juste pour les téléchargements et pour bloquer une version ? Du coup avec ces multiples répertoires il me semble que cela va éparpiller un peu (il y a comparativement beaucoup de dossiers par rapport au nombre réduit de fichiers), mais fait comme tu le sens, tu peux commiter ainsi si tu veux et que c’est ainsi que cela s’organise habituellement.
Oui, le principe c’est de faire un tag par version « diffusée », et garder le trunk comme version de développement. Faire un tag consiste simplement à copier le trunk avec la commande svn copy, qui présente l’avantage de conserver l’historique des modifications, et n’augmente pas la taille du dépôt (en interne les fichiers ne sont pas réellement dupliqués).
C’est bien ainsi qu’on organise habituellement, au boulot on a au moins 12 tags pour notre logiciel principal. Je ne crains pas qu’on se perde dans le méandre des répertoires car :
- ce qui est dans un tag ne bouge plus donc on n’a pas spécialement à s’en occuper une fois le tag créé
- les développeurs travaillant sur l’évolution des libs travaillent sur le trunk
Je ne sais pas trop comment c’est organisé sur le site internet d’inform. L’idée était de ne conserver dans informfr que les libs indispensables de base, et mettre le reste dans outils. Les extensions traduites me semblent être mieux à leur place dans outils, mais si tu considères qu’elles font partie de la lib francophone de base (donc que tout jeu francophone en I7 les utilisera), alors pas de problème pour les laisser dans le répertoire informfr.
J’ai précisé I6 juste au cas où un jour on ait soit un scenic5sens valable aussi bien pour I6 que I7, ou une version I7 présentant des fonctionnalités équivalentes. Je vais laisser comme ça pour l’instant, ça pourra toujours évoluer.
J’ai préféré la séparer des autres outils car j’ai déjà prévu quelques corrections dessus, ce qui conduira à une version 1.1, or si je la laisse avec les autres outils il ne sera pas simple d’identifier le changement de version.
ces outils pour Inform 7 n’auront pas à être utilisé dans chaque jeu, donc tu peux le mettre dans le dossier outils (sauf pour French donc), cela sera plus logique ainsi alors.
Pour la suite il faudra donc modifier le makefile pour qu’il puisse générer facilement une archive distribuable sur le site.
Ça roule donc