rlepigre
commented
3 years ago (Ceci est un début de solution pour #11.)
Closed rlepigre closed 3 years ago
rlepigre
commented
3 years ago (Ceci est un début de solution pour #11.)
phyver
commented
3 years ago Beau boulot !
Je viens de créer une branche i18n-devel sur le dépôt.
Quelques remarques :
goal.txt dans un fichier texte, et inclure le bon fichier (goal-fr.txt, goal-en.txt, etc.), comme tu as fait pour localiser le chemin d'accès. On peut éventuellement substituer des variables dans le fichier texte avec envsubst, qui est livré avec gettext.gettext.sh (quitte a l'ajouter aux sources de GameShell) pour pouvoir utiliser la fonction eval_gettext.xgettext pour extraire les fichier .po automatiquement, ça facilite la traduction. On utilise gettext MESSAGE dans les sources. Les clés sont donc simplement le message par défaut (en francais ?), et ça permet de faire marcher GameShell sans gettext. (On redefinit gettext sur echo, et on n'a juste pas la localisation.)Tu en penses quoi ?
rlepigre
commented
3 years ago Je viens de créer une branche
i18n-develsur le dépôt.
OK, très bien. Par contre je ne dois pas avoir les droits pour pusher sur cette branche. (Normalement tu dois avoir les droits sur la branche de la PR donc normalement ce n'est pas utile d'en avoir une copie sur le dépôt principal.)
- Il faudrait laisser
goal.txtdans un fichier texte, et inclure le bon fichier (goal-fr.txt,goal-en.txt, etc.), comme tu as fait pour localiser le chemin d'accès. On peut éventuellement substituer des variables dans le fichier texte avecenvsubst, qui est livré avecgettext.
Bien vu, j'avais pas pensé à faire ça. Par contre ça veut dire que la traduction d'une mission demande de créer plusieurs fichiers, et on peut avoir des problèmes si on se trompe dans le chemin du fichier goal-*.txt. (Aussi, j'aimais bien l'idée que pour traduire une mission il suffice de copier le fichier .po anglais ou français, et de le modifier.) D'un autre côté l'avantage de ton approche c'est qu'on est pas contraint par la syntaxe des fichiers .po pour l'objectif de la mission.
- il faudrait inclure et utiliser le fichier
gettext.sh(quitte a l'ajouter aux sources de GameShell) pour pouvoir utiliser la fonctioneval_gettext.
En effet, ça me semble être une très bonne idée! A priori gettext.sh devrait toujours être disponible sur un système qui a gettext non?
- C'est probablement bien d'utiliser
xgettextpour extraire les fichier.poautomatiquement, ça facilite la traduction. On utilisegettext MESSAGEdans les sources. Les clés sont donc simplement le message par défaut (en francais ?), et ça permet de faire marcher GameShell sansgettext. (On redefinitgettextsurecho, et on n'a juste pas la localisation.)
Si on part pour ça il faut absolument que le message par défaut soit en anglais sinon ce sera très compliqué à traduire par des gens qui ne parlent pas français. Ce que je pensais faire après avoir intégré l'internationalisation c'est de poster un lien sur hackernews. Vu l'engouement sur linuxfr on peut espérer avoir beaucoup de contributions (pour des traduction, des améliorations, et des missions j'espère).
J'avais un peu des doutes sur ce que tu proposes en cas d'absence de gettext, mais après réflexion je pense que ça devrait fonctionner exactement comme il faut ! Je vais expérimenter dans cette direction ce soir.
rlepigre
commented
3 years ago J'ai un peu avancé, voilà ce que j'ai fait:
goal/en.txt / goal/fr.txt,goal.sh est toujours là: on peut difficilement s'en passer si on veut utiliser xgettext (le nom du fichier "goal" à utiliser doit apparaître dans les sources de la mission),xgettext est utilisé pour générer un fichier locale/template qu'un traducteur peut copier pour ajouter une langue.gettext.sh est utilisé pour eval_gettext (des variables sont utilisées dans les chaines à traduire maintenant).phyver
commented
3 years ago J'essaierais de regarder ce soir...
* le script `goal.sh` est toujours là: on peut difficilement s'en passer,On peut pas faire cette etape dans la fonction
_gash_show? Ça me parait plus logique, et ça évite ce fichiergoal.sh.
rlepigre
commented
3 years ago
- le script
goal.shest toujours là: on peut difficilement s'en passer,On peut pas faire cette etape dans la fonction
_gash_show? Ça me parait plus logique, et ça évite ce fichiergoal.sh.
Je ne sais pas comment on peut avoir à la fois:
_gash_show pour afficher l'objectif, et.po générique pour une mission.Pour (2) il faut que eval_gettext "\$MISSION_DIR/goal/en.txt" apparaisse dans les sources de la mission, mais si on fait (1) ce n'est pas le cas et donc xgettext ne génère pas ce msgid. Si au contraire on n'utilise pas xgettext alors on peut très bien décider qu'il y a un msgid obligatoire pour chaque mission, et on peut facilement éliminer goal.sh.
Perso je trouve qu'utiliser xgettext est très bien et permet d'éviter des erreurs idiotes, surtout quand les clés sont des messages complets en anglais (ou en français si tu insistes que ce soit la langue par défaut).
phyver
commented
3 years ago Ce que j'avais en tête, c'est que _gash_show fasse un cat $MISSION_DIR/$(gettext goal-en.txt). Le traducteur devra simplement ajouter une chaine dans le fichier .po global.
Il y a effectivement un problème : si le fichier goal-it.txt n'existe pas, il y aura une erreur. On peut faire un test dans _gash_show pour utiliser le fichier par défaut, mais ça ne permettra pas de gérer des locales comme LANGUAGE=fr_FR:fr:en_GB:en_US:en.
Je me demande toujours si c'est pas plus simple d'utiliser gettext pour gameshell, et de simplement dupliquer les missions pour la traduction.
rlepigre
commented
3 years ago C'est pas très modulaire de devoir ajouter quelque chose dans le .po global (tu parles bien du .po de gameshell?), je trouve que ce serait bien plus satisfaisant que la traduction d'une mission ne nécessite que l'ajout de fichiers dans le dossier de la mission. Et je trouve que ce serait un peu dommage de devoir dupliquer des missions pour les traduire.
Je ne comprend pas bien ce qui te pose problème avec le fichier goal.sh, mais on peut le virer si on demande que lors de la création du "template" de traduction pour une mission (le fichier .po produit avec xgettext) on ajoute manuellement une entrée avec msgid "goal/en.txt" à la fin du fichier. Et bien entendu, ce sera au traducteur de s'assurer que le fichier existe. On peut aussi garantir que le fichier goal/en.txt existe pour toutes les missions (en vérifiant que c'est bien le cas dans start.sh), comme ça pas d'erreur possible.
phyver
commented
3 years ago Pas vraiment eu le temps de regarder, mais après réflection, je valide le fichier goal.sh, et s'il n'existe pas, un fichier goal.txt. Comme ç, quelqu'un qui veut juste créer une mission n'est pas obligé de s'embêter avec gettext s'il ne veut pas la traduire.
On ajoute la dépendance gettext pour GameShell. Sous Debian, le paquet gettext-base doit suffire pour lancer GameShell. Il faut le paquet supplémentaire gettext pour traduire les missions.
Je n'aurais probablement pas beaucoup de temps cette semaine, mais le plan serait :
gettext dans les sources de GameShellSi ça t'amuse encore, tu peux continuer à bosser sur le point 3. (Dans les trucs à faire, y'a gérer le fichier treasure.txt, et tester un peu plus.)
Je m'occuperais des points 1 et 2, et la suite se décompose facilement en petits morceaux.
rlepigre
commented
3 years ago OK très bien! Je viens de pusher des traductions pour les missions 2 et 3. Je n'ai pas beaucoup de temps non plus cette semaine, mais je vais essayer de continuer un peu le soir si je peux.
Pour la mission 3 (la première à utiliser treasure.txt) ce que j'ai fait c'est d'afficher le message dans le script treasure.sh (à la manière de goal.sh). J'ai aussi pas mal testé les missions en anglais et en français, et jusque là ça a l'air de très bien marcher.
Pour les fichier .po utilisés par les sources de GameShell tu comptes générer les fichier .mo dans start.sh comme pour les missions? Peut-être qu'on devrait prendre les mêmes conventions de nommage que dans les missions et créer des fichiers des fichiers locale/fr.po, locale/en.po, et utiliser un dossier différent pour la génération des .mo (qui pour l'instant sont crées sous le dossier locale à la racine du dépôt).
phyver
commented
3 years ago Merci. Tu as du oublié de pousser tes changements.
Pour le fichier treasure.txt, l'idée originale est d'avoir un message (facultatif) lors du premier chargement de treasure.sh. Le fichier treasure.sh est ensuite copié dans un répertoire pour être chargé automatiquement par le bashrc de GameShell.
Il ne faut pas l'afficher à chaque chargement. Le plus simple est probablement de supprimer le fichier treasure.txt et d'afficher le message dans le fichier check.sh, lorsque la mission est validée. (Ou alors, avoir un fichier treasure-msg.txt / treasure-msg.sh : ça simplifie le déplacement du trésor dans une autre mission.)
Pour la traduction de GameShell, je pensais faire un truc similaire. Je trouve bien que les .mo soient dans le dossier locale. On peut peut-être mettre les .po dans un dossier i18n/en.po, etc. pour être uniforme, et laisser locale pour les .mo.
rlepigre
commented
3 years ago Tu as du oublié de pousser tes changements.
Ah oui...
Pour le fichier
treasure.txt, l'idée originale est d'avoir un message (facultatif) lors du premier chargement detreasure.sh. Le fichiertreasure.shest ensuite copié dans un répertoire pour être chargé automatiquement par lebashrcde GameShell. Il ne faut pas l'afficher à chaque chargement. Le plus simple est probablement de supprimer le fichiertreasure.txtet d'afficher le message dans le fichiercheck.sh, lorsque la mission est validée. (Ou alors, avoir un fichiertreasure-msg.txt/treasure-msg.sh: ça simplifie le déplacement du trésor dans une autre mission.)
Ah OK, je ne savais pas. Je vais corriger ça ce soir !
Pour la traduction de GameShell, je pensais faire un truc similaire. Je trouve bien que les
.mosoient dans le dossierlocale. On peut peut-être mettre les.podans un dossieri18n/en.po, etc. pour être uniforme, et laisserlocalepour les.mo.
OK très bien, je renommerai donc le fichier locale en i18n dans les missions, et on installe les .po dans locale (à la racine du dépôt).
VictorDubois
commented
3 years ago Salut ! J'ai fini le jeu hier, c'était super, merci :)
Je veux bien donner un coup de main, j'ai commencé sur la mission 10 (pour ne pas risquer de faire doublon sur une mission déjà traduite ^^) J'ai fais une pull request sur la branche de @rlepigre : https://github.com/rlepigre/GameShell/pull/1
Victor
phyver
commented
3 years ago Je veux bien donner un coup de main, j'ai commencé sur la mission 10 (pour ne pas risquer de faire doublon sur une mission déjà traduite ^^) J'ai fais une pull request sur la branche de @rlepigre : rlepigre#1
Merci ! Ne fais rien sur la mission 11. Elle va probablement disparaitre très prochainement...
rlepigre
commented
3 years ago Pour le fichier
treasure.txt, l'idée originale est d'avoir un message (facultatif) lors du premier chargement detreasure.sh. Le fichiertreasure.shest ensuite copié dans un répertoire pour être chargé automatiquement par lebashrcde GameShell. Il ne faut pas l'afficher à chaque chargement. Le plus simple est probablement de supprimer le fichiertreasure.txtet d'afficher le message dans le fichiercheck.sh, lorsque la mission est validée. (Ou alors, avoir un fichiertreasure-msg.txt/treasure-msg.sh: ça simplifie le déplacement du trésor dans une autre mission.)
Pour le message affiché quand on gagne le trésor, j'ai pris la second option: ajouter un fichier treasure-msg.sh. Je trouve que c'est plus natural de séparer la logique "test de la mission" de la logique "on gagne un trésor".
rlepigre
commented
3 years ago Ne fais rien sur la mission 11. Elle va probablement disparaitre très prochainement...
Oh non! C'est une des missions que je préfère! En fait, surtout à cause du magnifique tableau.
Peut-être qu'on pourrait la transformer en mission pour la commande cat? Du genre, tu mets trois tableaux tableau1, tableau2, tableau3 dans le chateau, et tu demande de copier uniquement celui qui est signé Picasso. Donc il faut afficher les tableaux avec cat pour savoir lequel c'est.
phyver
commented
3 years ago Pour le message affiché quand on gagne le trésor, j'ai pris la second option: ajouter un fichier treasure-msg.sh. Je trouve que c'est plus natural de séparer la logique "test de la mission" de la logique "on gagne un trésor".
C'est aussi ce qui me parait le mieux.
Oh non! C'est une des missions que je préfère! En fait, surtout à cause du magnifique tableau. Peut-être qu'on pourrait la transformer en mission pour la commande
cat? Du genre, tu mets trois tableauxtableau1,tableau2,tableau3dans le chateau, et tu demande de copier uniquement celui qui est signé Picasso. Donc il faut afficher les tableaux aveccatpour savoir lequel c'est.Bonne idée. C'est surtout l'idée de faire un
mvsuivi d'un déplacement qui est très artificiel.
Je viens de pousser plusieurs modifs sur la branche master, je ferais un merge dans un moment. Ne t'en occupe pas pour l'instant.
phyver
commented
3 years ago Pas mal de changement cosmétiques dans start.sh et gameshell.sh (renomé depuis game_shell.sh.
Idéalement, je vais pouvoir commencer à ajouter la traduction pour les sources de GameShell bientôt.
rlepigre
commented
3 years ago Cool! Tu vas le faire ici?
Une convention que j'ai prise dans les missions est d'avoir un dossier i18n, et d'utiliser un sous-dossier pour les fichiers textes qui sont à traduire (par exemple il y a un fichier i18n/goal/[en|fr].txt et un fichier i18n/treasure-msg/[en|fr].txt). Je pense que ce serait bien d'utiliser la même approche pour l'internationalisation de GameShell: un dossier i18n à la racine avec des sous-dossiers pour chaque segment de texte à traduire (message affiché par le -h de start.sh, instructions au lancement, ...).
Au fait, je sais pas si tu as vu mais j'ai commencé à étendre un peu la documentation (et à la traduire) dans le dossier doc. Je pense qu'il serait bien de clarifier (quand tout est stabilisé) quelle variable d'environment est disponible dans les scripts des missions.
phyver
commented
3 years ago Je vais commencer par faire une première version en local, puis je mergerais sur cette branche.
Quand ça marchera bien, je pourrais merger sur master...
Ah oui... La doc...
Le fichier TODO n'est pas du tout à jours. Je l'avais oublié celui là.
Je vais attendre d'avoir fait la traduction, parce que je vais probablement changer d'autres trucs. Après, il faudra effectivement formaliser un peu plus tout ça.
phyver
commented
3 years ago J'ai presque fini la traduction de start.sh !
Il faut juste que je finisse de générer les .mo au lancement...
Juste une question. Tu utilises msgmerge ?
Chez moi, je fais
xgettext -o tmp ...msgmerge -U i18n/template tmp, msgmerge -U i18n/en.po tmp, msgmerge -U i18n/fr.po tmprm tmpC'est bien pratique car ça met les fichiers à jours en conservant l'existant. Par contre, chez moi, il faut mettre le CHARSET`` dans l'entête du fichiertemplate. J'ai gardé un morceau de l'entête générée sans--omit-header` :
#, fuzzy
msgid ""
msgstr ""
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
...
...Petits problèmes de commit et autres, mais ça a l'air de marcher !
Je vais me mettre au fichier gameshell.sh...
Autre truc : il faut que je sauvegarde la locale : quand on relance une partie, il ne faut surtout pas utiliser une autre locale que celle utilisée pour l'initialisation. Sinon, les scripts check.sh risquent de ne plus fonctionner !
rlepigre
commented
3 years ago J'ai presque fini la traduction de
start.sh! Il faut juste que je finisse de générer les.moau lancement...
Cool!
Juste une question. Tu utilises
msgmerge?
Non, je ne l'ai pas du tout utilisé.
Chez moi, je fais
xgettext -o tmp ...msgmerge -U i18n/template tmp,msgmerge -U i18n/en.po tmp,msgmerge -U i18n/fr.po tmprm tmpC'est bien pratique car ça met les fichiers à jours en conservant l'existant. Par contre, chez moi, il faut mettre le
CHARSETdans l'entête du fichier`template. J'ai gardé un morceau de l'entête générée sans--omit-header
OK, je vois. Du coup c'est peut-être une bonne idée de ne pas inclure le --omit-header? Je ne voyais pas l'intérêt des méta-données (qui prennent plus de place que les messages dans beaucoup des fichiers des missions), donc c'est pour ça que j'ai utilisé --omit-header partout. Mais s'il est utile on devrait peut-être le rajouter partout.
rlepigre
commented
3 years ago Petits problèmes de commit et autres, mais ça a l'air de marcher ! Je vais me mettre au fichier
gameshell.sh...
J'ai corrigé un petit truc (une utilisation de gettext alors qu'il faut eval_gettext) dans start.sh, et des messages manquants pour la version anglaise.
Autre truc : il faut que je sauvegarde la locale : quand on relance une partie, il ne faut surtout pas utiliser une autre locale que celle utilisée pour l'initialisation. Sinon, les scripts
check.shrisquent de ne plus fonctionner !
Ah oui, bien vu. Je n'avais pas du tout pensé à ça. Par contre je sais pas trop quel variable il faut sauvegarder, tu as une idée? Tout ce que je sais c'est que LANGUAGE peut être utilisé pour passer outre la configuration du système. Peut-être qu'il faudrait sauvegarder la valeur de LANGUAGE si elle existe, et sinon en construire une à partir de LANG? En fait, le plus simple est surement de sauvegarder la sorite de locale plus la valeur de LANGUAGE.
phyver
commented
3 years ago Merci.
Je pense qu'en théorie, sauvegarder la valeur de $LANGUAGE est suffisant, mais il faudrait tester sur des systèmes autre qu'un Linux standard.
Sinon, voici ce que je pense faire pour gérer le goal :
goal.sh, on l'utilise (il doit écrire quelque chose sur stdout, et c'est GameShell ajoutera le parchemin)$MISSION_DIR/i18n/goal/LANG.txt$MISSION_DIR/goal/LANG.txt$MISSION_DIR/goal.txtDans tous les cas, j'utiliserais envsubst pour substituer d'éventuelles variables dans le texte.
Je pense que ça couvre toutes les utilisations !
rlepigre
commented
3 years ago Je pense qu'en théorie, sauvegarder la valeur de
$LANGUAGEest suffisant, mais il faudrait tester sur des systèmes autre qu'un Linux standard.
Chez moi la variable LANGUAGE n'a pas de valeur par défaut.
Sinon, voici ce que je pense faire pour gérer le
goal:
- s'il y a un fichier
goal.sh, on l'utilise (il doit écrire quelque chose surstdout, et c'est GameShell ajoutera le parchemin)
OK, je pense que c'est très bien.
- sinon, on cherche un fichier
$MISSION_DIR/i18n/goal/LANG.txt- sinon, on cherche un fichier
$MISSION_DIR/goal/LANG.txt- sinon, on cherche un fichier
$MISSION_DIR/goal.txt
J'avais pensé à faire ça, mais il y a un problème avec cette approche: il se peut qu'il y ait plusieurs versions du fichier goal pour une langue donnée (par example, une version anglais US et une version anglais UK, et il se peut que pour certaines language la différence soit importante entre les variantes régionales). Donc si on fait ça, il sera difficile de supporter un run du jeu avec LANGUAGE=en_UK:en_US:en par exemple. Il faudrait d'abort tester si la version en_UK existe, puis en_US, puis fr. Donc bref, je trouve que c'est bien de laisser gettext s'occuper de ça, tout en permettant au traducteur de réutiliser le même fichier (par exemple $MISSION_DIR/i18n/goal/en.txt) pour deux variantes d'une même langue (par exemple en_UK et en_US). En particulier ça veut dire qu'on ne peut pas décider de juste donner un nom de fichier comme LANG.txt et l'utiliser pour accéder à la fois i18n/goal/LANG.txt et i18n/treasure-msg/LANG.txt. L'un des deux pourrait avoir plusieurs variantes locales et l'autre non.
Dans tous les cas, j'utiliserais
envsubstpour substituer d'éventuelles variables dans le texte.Je pense que ça couvre toutes les utilisations !
Je n'aime pas trop l'idée de suggérer plein d'alternatives pour le format des missions. Je pense qu'il serait préférable d'avoir une structure plus rigide, quite à fournir un "template" pour créer une mission. Plus c'est flexible et plus les gens qui créent des missions vont faire des choses bizarres, donc je crois vraiment qu'il faut les guider de manière assez stricte. D'ailleurs je serais pour n'autoriser que un script $MISSION_DIR/goal.sh et laisser l'utilisateur faire cat "$MISSION_DIR/goal.txt". C'est un poil plus chiant que de juste créer $MISSION_DIR/goal.txt, mais si on fournit un template de mission le créateur n'aura pas à créer ce fichier lui-même. On pourrait d'ailleurs fournir deux templates: un pour une mission sans support pour la traduction, et un autre avec support pour la traduction. En particulier, on pourrait toujours générer les scripts comme goal.sh et treasure.sh de cette manière.
Qu'en penses-tu?
phyver
commented
3 years ago Ah... J'avais déjà oublié le problème des locales "multiples".
Ce qu'on pourrait faire, c'est :
goal.shgoal.sh, considérer qu'il fait juste cat "$(gettext "mission_goal_file")" (ou bien cat "$(eval_gettext "$MISSION_DIR/goal/en.txt")", à voir).Le problème de cette approche, c'est que la clé mission_goal_file ne sera pas détectée automatiquement, mais il suffit de fournir un template juste cette clé.
rlepigre
commented
3 years ago Oui, ça me semble déjà mieux ! Par contre à ce moment là pourquoi utiliser gettext/eval_gettext dans le cas où il n'y a pas de goal.sh? Si c'est le cas a priori la mission n'est pas traduite. On pourrait garder le comportement actuel: lire le fichier "$MISSION_DIR/goal.txt". Mais bon, encore une fois, je pense qu'il serait préférable de rendre le format de mission le plus simple possible en limitant les options (quite à avoir un peu de "boilerplate code" en plus, mais comme je le disais on peut fournir un template de mission).
phyver
commented
3 years ago Par contre à ce moment là pourquoi utiliser
gettext/eval_gettextdans le cas où il n'y a pas degoal.sh?Pour avoir quand même les traductions, quand elles existent.
Bon, une dernière proposition :
goal.txt, on l'utilise,goal.sh,goal.sh contient la seule ligne cat "$(eval_gettext '$MISSION_DIR/goal.txt')".(Je peux afficher un message d'erreur à l'initialisation statique s'il y a un goal.txt et un goal.sh ou goal/, pour éviter des surprises.)
L'idée est que :
gettext,goal.txt : il suffit d'ajouter le msgstr correspondant à $MISSION_DIR/goal.txt,gettext.J'aime bien l'idée de ne pas imposer gettext aux créateurs de missions. J'imagine que les créateurs et les traducteurs ne seront pas forcément les même personnes, et espère obtenir ainsi plus de nouvelles missions.
Non ?
On peut gérer le fichier treasure-msg.txt de la même façon.
Pour les emplacements par défaut, je propose $MISSION_DIR/goal/LANG.txt et $MISSION_DIR/treasure-msg/LANG.txt. Le répertoire $MISSION_DIR/i18n/ serait alors réservé aux fichiers LANG.po.
Tu en penses quoi ?
rlepigre
commented
3 years ago Par contre à ce moment là pourquoi utiliser
gettext/eval_gettextdans le cas où il n'y a pas degoal.sh?Pour avoir quand même les traductions, quand elles existent.
OK, je vois. Mais du coup on perd la génération complètement automatique du i18n/template avec xgettext, non?
Bon, une dernière proposition :
- si y'a un fichier
goal.txt, on l'utilise,- sinon, on utilise le fichier
goal.sh,- sinon, on suppose que le fichier
goal.shcontient la seule lignecat "$(eval_gettext '$MISSION_DIR/goal.txt')".(Je peux afficher un message d'erreur à l'initialisation statique s'il y a un
goal.txtet ungoal.shougoal/, pour éviter des surprises.)
OK. Et je trouve que c'est une très bonne idée de faire des vérifications à l'initialisation (j'imagine dans start.sh?). On pourrait aussi vérifier que les fichiers qui sont obligatoire existent bien tous.
L'idée est que :
- on peut créer une mission sans connaitre l'existence de
gettext,- on peut ne traduire que le fichier
goal.txt: il suffit d'ajouter lemsgstrcorrespondant à$MISSION_DIR/goal.txt,- on peut tout traduire en utilisant
gettext.
Je suis plutôt d'accord avec ça, mais je me demande combien de missions pourront être réellement traduites juste en changeant le goal.txt. La plupart des missions vont aussi demander de traduire au moins le nom de certains fichiers statiques (en particulier Chateau, Foret, ...), donc ça me semble assez peu utile.
J'aime bien l'idée de ne pas imposer
gettextaux créateurs de missions. J'imagine que les créateurs et les traducteurs ne seront pas forcément les même personnes, et espère obtenir ainsi plus de nouvelles missions. Non ?
Oui, je pense aussi que c'est très important de ne pas imposer gettext aux créateurs de missions. Par contre, on peut très bien imaginer que le développement d'une mission se passe de la manière suivant:
gettext ni dossier i18n) et utiliser le fichier "$MISSION_DIR/goal.txt" comme c'est a priori un peu plus simple,i18n/LANG.po et i18n/*/LANG.txt.On peut gérer le fichier
treasure-msg.txtde la même façon.
Oui, ce serait plus uniforme que goal.txt et treasure-msg.txt soient gérés de la même manière.
Pour les emplacements par défaut, je propose
$MISSION_DIR/goal/LANG.txtet$MISSION_DIR/treasure-msg/LANG.txt. Le répertoire$MISSION_DIR/i18n/serait alors réservé aux fichiersLANG.po.Tu en penses quoi ?
Pourquoi pas, c'est ce que j'avais dans une version précédente. Mais je trouvais que c'était un peu étrange que certains fichiers à traduire ne soient pas dans i18n/. (C'étais moins étrange avant de renommer locale/ en i18n/.)
Bref, au final je crois qu'on veut supporter deux scénarios :
"$MISSION_DIR/goal.sh" (qui peut très bien faire juste cat "$MISSION_DIR/goal.txt"),"$MISSION_DIR/goal.txt" qui est utilisé après avoir détecté l'absence de la version .sh.treasure-msg.[sh|txt].)gettext: comme je le disais plus haut, il ne sera probablement jamais suffisant de traduire goal.txt. Donc dans ce cas je pense qu'on peut éviter beaucoup d'erreurs en utilisant xgettext pour générer un template de traduction, et donc de toujours utiliser "$MISSION_DIR/goal.sh" et compagnie.Dans tous les cas je pense vraiment qu'on devrait fournir un script new_mission.sh qui permet de créer un template de mission. Comme ça on peut controller plus facilement le format des missions, et s'assurer une certaine uniformité. Ce script pourrait avoir une option --gettext qui, si elle est donnée, crée une mission avec support pour la traduction en générant automatiquement goal.sh et un template pour i18n/goal/en.txt. Chaque fichier crée par le script pourrait contenir des informations en commentaire sur le rôle du fichier. Par exemple, on pourrait toujours créer un fichier treasure.sh, mais expliquer qu'il peut être supprimé si on ne veut pas offrir de récompense. Sans l'option --gettext le script ferait plus ou moins la même chose, mais en créant un template pour goal.txt et pas de dossier i18n/. (On peut aussi décider que goal.sh est obligatoire, et générer automatiquement un script avec cat "$MISSION_DIR/goal.txt".) (On pourrait aussi avoir une option --minimal pour générer un template minimal sans treasure*, bashrc, et compagnie. Dans ce cas tous les fichiers sont utiles et doivent être édités, sauf peut-être goal.sh s'il est généré.)
(Un autre truc à garder en tête c'est qu'il est toujours plus facile de partir d'un format de mission plus rigide et de le relâcher plus tard si besoin, que de faire le contraire.)
Qu'en penses-tu? Au final c'est toi qui décide, donc n'hésite pas à trancher d'une manière ou d'une autre. :)
phyver
commented
3 years ago Je viens de pousser mes dernières modifs. Je n'ai pas beaucoup testé, mais ça devrait commencer à marcher.
J'ai implémenté la solution évoquée plus haut (goal.txt, puis gettext "$MISSION_DIR/GOAL/en.txt, puis goal.sh).
On verra ce que ça dit en traduisant les missions existantes.
(Je pense que la seule mission qui utilisera un vrai goal.sh est la mission 12 avec la date...)
J'ai passé les 3 missions que tu avais traduites pour utiliser ce format. (J'ai juste renommé le fichier goal.sh en _goal.sh, mais il pourra disparaitre.)
Je vais essayer de faire un petit script new_mission.sh pour générer un template de mission, avec quelques options (--no-gettext et consort).
Pour la mise à jour des fichier .po, je ne sais pas si c'est mieux de faire un script, ou de fournir un Makefile.
Je te mets aussi mon fichier TODO, pour voir si tu as des trucs à ajouter...
TODO.txt
rlepigre
commented
3 years ago Je viens de pousser mes dernières modifs. Je n'ai pas beaucoup testé, mais ça devrait commencer à marcher.
Cool ! J'ai testé les premières missions et ça à l'air de marcher. Je vais tester un peu plus en traduisant des missions dés que j'ai un moment.
J'ai implémenté la solution évoquée plus haut (
goal.txt, puisgettext "$MISSION_DIR/GOAL/en.txt, puisgoal.sh). On verra ce que ça dit en traduisant les missions existantes.
OK, très bien. Par contre quelle procédure on utilise pour générer le template de traduction du coup ?
Pour la mise à jour des fichier
.po, je ne sais pas si c'est mieux de faire un script, ou de fournir unMakefile.
Ouais, j'avais pensé à faire ça avec un Makefile, ce serait peut-être bien. Et puis on pourrait aussi l'utiliser pour générer des fichiers statiques ou des programmes (dans $MISSION_DIR/bin), et il suffirait que pour les missions start.sh commence par lancer make -C "$MISSION_DIR" si le fichier $MISSION_DIR/Makefile existe.
Je te mets aussi mon fichier
TODO, pour voir si tu as des trucs à ajouter... TODO.txt
J'ai jeté un œil, et je ne vois pas trop quoi ajouter pour l'instant. Peut-être que tu devrais mettre ce fichier dans le dépôt pour qu'on ajoute des idées et qu'on enlève ce qui a été fait. (Au passage, j'aime bien l'idée de désactiver la complétion au début et de la donner comme un trésor. Il faudrait l'ajouter juste avant la mission qui introduit la complétion !).
phyver
commented
3 years ago Je viens de pousser le script bin/new-mission.sh !
OK, très bien. Par contre quelle procédure on utilise pour générer le template de traduction du coup ?
Le script
new-missions.shgénère unMakefilequi permet d'ajouter un nouveau langage, et de mettre à jour un langage existant.
xgettext pour récupérer les clés dans un fichier i18n/templatemsgen pour générer un nouveau langage à partir de i18n/template, avec les valeurs égales aux clésmsgmerge pour mettre à jour un fichier .po existant à partir de i18n/templateY'a une petite incohérence que je corrigerais peut-être : la mise à jours du fichier met des valeurs vides, alors que l'initialisation met les valeurs identiques aux clés.
C'est probablement bien de rajouter une étape (un fichier i18n/en.pot) pour ajouter des valeurs idéntiques aux clés.
L'idée est que la clé est simplement la version anglaise (US?) du message, et ça permet donc qu'une traduction non faite utilise des messages anglais plutôt que des chaines vides.
J'ai jeté un œil, et je ne vois pas trop quoi ajouter pour l'instant. Peut-être que tu devrais mettre ce fichier dans le dépôt pour qu'on ajoute des idées et qu'on enlève ce qui a été fait.
Bonne idée. Pour les traduction, tu peux avancer sur les missions du début. Je commencerais par traduire les missions de la fin.
(Au passage, j'aime bien l'idée de désactiver la complétion au début et de la donner comme un trésor. Il faudrait l'ajouter juste avant la mission qui introduit la complétion !).
Je ne me souviens plus pourquoi je ne l'avais pas fait. Ça date des toutes premières versions de GameShell. Soit il y avait des problèmes sur certaines distributions, ou bien j'en avais simplement marre de ne plus pouvoir utiliser la tabulation lors de mes tests !
rlepigre
commented
3 years ago J'ai traduit plusieurs missions en utilisant ton Makefile pour générer les fichiers template.pot et compagnie, et c'est vraiment pratique pour ne pas avoir à se rappeler des commandes.
Par contre c'est vraiment très chiant de devoir ajouter à la main le chemin vers le fichier "goal" / "treasure-msg". Ce serait bien plus facile pour moi de copier-coller un fichier goal.sh "standard" pour chaque mission. Sinon, Il faudrait peut-être faire en sorte d'ajouter les clés manquantes en générant le fichier template.pot.
Un autre truc que j'ai remarqué : certaines mission ne sont pas "self-contained" dans le sens où leur static.sh ne s'assure pas de l'existence de certains dossiers. Je pense qu'il faut qu'on s'assure que toutes les missions ajoutent bien tous les fichiers nécessaires. Et ce serait peut-être pratique de pouvoir lancer le jeu avec une seule mission pour pouvoir s'en assurer facilement.
Encore une autre idée: ajouter dans les missions on dossier test dans lequel on pourrait donner plusieurs solutions ou non-solutions avec un résultat attendu. Avec ça on pourrait avoir facilement un mode de test automatique des missions, ce qui serait pratique pour vérifier qu'on a pas de régression.
L'idée est que la clé est simplement la version anglaise (US?) du message, et ça permet donc qu'une traduction non faite utilise des messages anglais plutôt que des chaines vides.
OK, ça me semble être une bonne idée. Mais du coup c'est le template.pot qui contrôle ça ? (J'ai vu que tu avais ajouté ce fichier au .gitignore, est-ce qu'on ne voudrait pas plutôt l'inclure dans le dépôt ?)
(Au passage, j'aime bien l'idée de désactiver la complétion au début et de la donner comme un trésor. Il faudrait l'ajouter juste avant la mission qui introduit la complétion !).
Je ne me souviens plus pourquoi je ne l'avais pas fait. Ça date des toutes premières versions de GameShell. Soit il y avait des problèmes sur certaines distributions, ou bien j'en avais simplement marre de ne plus pouvoir utiliser la tabulation lors de mes tests !
Une autre idée de trésor en passant : activer l'historique des commandes. Mais c'est peut-être déjà fait, je ne me rappelle plus.
phyver
commented
3 years ago J'ai traduit plusieurs missions en utilisant ton
Makefilepour générer les fichierstemplate.potet compagnie, et c'est vraiment pratique pour ne pas avoir à se rappeler des commandes.Par contre c'est vraiment très chiant de devoir ajouter à la main le chemin vers le fichier "goal" / "treasure-msg".
Le script
bin/new-mission.sha une option-Met-Tqui te génère unMakefileou untemplate.potsurstdout. Letemplate.potcontient les lignes pourgoal/en.txtettreasure-msg/en.txt.
Par contre, tu as raison, il faudrait que le Makefile génère aussi les lignes manquantes.
Et je vais enlever les template.pot du .gitignore. Un truc intéressant c'est qu'on peut y ajouter des commentaires qui sont propagés dans les fichiers .po.
Un autre truc que j'ai remarqué : certaines mission ne sont pas "self-contained" dans le sens où leur
static.shne s'assure pas de l'existence de certains dossiers. Je pense qu'il faut qu'on s'assure que toutes les missions ajoutent bien tous les fichiers nécessaires.C'est effectivement ce que je fais sur les missions que je traduis. C'est parfois un peu plus complexe car certaines missions utilisent les même fichiers auxiliaires. Parfois, ils sont dupliqués (ingrédients de la potion magique), parfois pas (génération de l'échoppe). Je ne sais pas ce qui est le mieux...
Et ce serait peut-être pratique de pouvoir lancer le jeu avec une seule mission pour pouvoir s'en assurer facilement.
Bonne idée ! Pour le moment, tu as vu que tu pouvais lancer
./start -FRD6pour commencer directement à la mission 6, sans avoir à répondre aux questions ?Encore une autre idée: ajouter dans les missions on dossier
testdans lequel on pourrait donner plusieurs solutions ou non-solutions avec un résultat attendu. Avec ça on pourrait avoir facilement un mode de test automatique des missions, ce qui serait pratique pour vérifier qu'on a pas de régression.Autre bonne idée. Il y a la commande
gash auto, mais elle ne fait de test négatif.OK, ça me semble être une bonne idée. Mais du coup c'est le
template.potqui contrôle ça ? (J'ai vu que tu avais ajouté ce fichier au.gitignore, est-ce qu'on ne voudrait pas plutôt l'inclure dans le dépôt ?)Oui. voir plus haut.
Une autre idée de trésor en passant : activer l'historique des commandes. Mais c'est peut-être déjà fait, je ne me rappelle plus.
Non, mais c'est dans le TODO... (Au minimum, expliquer la recherche dans l'historique.)
rlepigre
commented
3 years ago Le script
bin/new-mission.sha une option-Met-Tqui te génère unMakefileou untemplate.potsurstdout. Letemplate.potcontient les lignes pourgoal/en.txtettreasure-msg/en.txt.
Oh OK, je ne l'ai pas utilisé directement pour les traductions, juste le Makefile (que j'ai extrait du script).
Par contre, tu as raison, il faudrait que le
Makefilegénère aussi les lignes manquantes. Et je vais enlever lestemplate.potdu.gitignore. Un truc intéressant c'est qu'on peut y ajouter des commentaires qui sont propagés dans les fichiers.po.
Au oui, j'avais pas pensé aux commentaires, bonne idée.
C'est parfois un peu plus complexe car certaines missions utilisent les même fichiers auxiliaires. Parfois, ils sont dupliqués (ingrédients de la potion magique), parfois pas (génération de l'échoppe). Je ne sais pas ce qui est le mieux...
(Ce qui suit n'est pas super clair, mais je donne juste quelques idées en vrac.)
Je pense que ce qu'il faudrait faire c'est introduire une notion de "pack de missions". Dans certains cas on a des missions qui vont ensemble, et ce serait bien de pouvoir partager des trucs (par exemple une bibliothèque de fonctions shell, une partie de l'initialisation statique, les fichiers de traduction, ...). Ce qui serait bien avec ça c'est aussi que tu pourrais avoir un fichier de configuration de GameShell dans lequel tu choisis quels packs tu veux. Les missions seraient donc uniquement numérotées au sein des packs, ce qui simplifierait aussi l'ajout de missions "faciles" (pour l'instant c'est impossible d'ajouter une mission entre la mission 5 et la mission 6 sans renommer toutes les missions suivantes).
Alternativement, on pourrait virer les numéros du dossier des missions, et avoir un fichier de configuration avec un nom de mission par ligne: le numéro de mission serait ensuite généré à partir du numéro de ligne. Mais cette deuxième option ne permet pas de partager du code entre les missions. Par contre, on pourrait ajouter une notion de dépendance entre missions pour faire ça : si la mission A dépend de la mission B et que B vient avant A dans le fichier de configuration (ou que B apparaît sans A) alors erreur.
Et on peut très bien faire les deux: avoir des packs de missions, et un fichier de configuration qui permet de choisir quels packs on veut, et quelles missions on veut au sein des différent packs.
Et ce serait peut-être pratique de pouvoir lancer le jeu avec une seule mission pour pouvoir s'en assurer facilement.
Bonne idée ! Pour le moment, tu as vu que tu pouvais lancer
./start -FRD6pour commencer directement à la mission 6, sans avoir à répondre aux questions ?
Oui, c'est ce que je fais aussi !
phyver
commented
3 years ago Je pense que ce qu'il faudrait faire c'est introduire une notion de "pack de missions". Dans certains cas on a des missions qui vont ensemble, et ce serait bien de pouvoir partager des trucs (par exemple une bibliothèque de fonctions shell, une partie de l'initialisation statique, les fichiers de traduction, ...). Ce qui serait bien avec ça c'est aussi que tu pourrais avoir un fichier de configuration de GameShell dans lequel tu choisis quels packs tu veux. Les missions seraient donc uniquement numérotées au sein des packs, ce qui simplifierait aussi l'ajout de missions "faciles" (pour l'instant c'est impossible d'ajouter une mission entre la mission 5 et la mission 6 sans renommer toutes les missions suivantes).
Alternativement, on pourrait virer les numéros du dossier des missions, et avoir un fichier de configuration avec un nom de mission par ligne: le numéro de mission serait ensuite généré à partir du numéro de ligne. Mais cette deuxième option ne permet pas de partager du code entre les missions. Par contre, on pourrait ajouter une notion de dépendance entre missions pour faire ça : si la mission A dépend de la mission B et que B vient avant A dans le fichier de configuration (ou que B apparaît sans A) alors erreur.
Et on peut très bien faire les deux: avoir des packs de missions, et un fichier de configuration qui permet de choisir quels packs on veut, et quelles missions on veut au sein des différent packs.
Mmmm... GameShell reste un projet en shell. Je ne vais pas me lancer dans un truc aussi complexe, en tout cas, pas tant qu'il n'y a pas de vrai besoin.
Tu peux facilement ajouter des missions dans l'ordre que tu veux avec le script bin/archive.sh. L'execution dans le répertoire de développement reste une facilité lors du développement, mais ça n'est pas le mode "standard" d'exécution.
(Dans les projets, il y a aussi de créer un script "auto exécutable", cf https://www.linuxjournal.com/node/1005818)
Mon idée est d'avoir un répertoire missions avec toutes les missions "officielles", et un répertoire contrib avec les contributions. Pour les missions contrib, je ne suis pas sûr. Il faudrait au moins une manière de les tester individuellement, mais je ne pense pas faire plus. En gros, il faudra forcément générer une archive...
(Pour les missions géniales, je les ajouterais dans les missions officielles...
Ça te parait déraisonnable ?
rlepigre
commented
3 years ago GameShell reste un projet en shell. Je ne vais pas me lancer dans un truc aussi complexe, en tout cas, pas tant qu'il n'y a pas de vrai besoin.
Tout ça c'est juste des idée, on va clairement pas faire ce genre de chose tout de suite, et on n'en aura peut-être jamais besoin.
Tu peux facilement ajouter des missions dans l'ordre que tu veux avec le script
bin/archive.sh. L'execution dans le répertoire de développement reste une facilité lors du développement, mais ça n'est pas le mode "standard" d'exécution.
Ah OK, je vois. Je ne savais pas que tu pouvais faire ça avec ce script.
(Dans les projets, il y a aussi de créer un script "auto exécutable", cf https://www.linuxjournal.com/node/1005818)
Cool, c'est rigolo, j'avais jamais réalisé que c'est aussi facile de faire ce genre de chose. Du coup ça veut dire que pour installer et lancer le jeu il suffira de faire un truc du genre curl https://github.com/.../install.sh | sh?
Mon idée est d'avoir un répertoire
missionsavec toutes les missions "officielles", et un répertoirecontribavec les contributions. Pour les missionscontrib, je ne suis pas sûr. Il faudrait au moins une manière de les tester individuellement, mais je ne pense pas faire plus. En gros, il faudra forcément générer une archive...Ça te parait déraisonnable ?
Non, c'est tout à fait raisonnable dans un premier temps.
Mais je crois quand même que ce serait facile de pouvoir classer les missions dans de sous-dossiers, et que ce soit plus facile d'expérimenter dans le dépôt. En gros, j'imagine qu'on pourrait s'en tirer avec les deux modifications suivantes:
Autoriser une vraie arborescence dans le dossier missions, ce qui permettrait de classer les missions de manière plus satisfaisante je trouve. En gros ce que j'imagine c'est une arborescence comme ça:
missions
├── basics
│ ├── index.txt
│ ├── cd_1
│ ├── cd_2
│ ├── cd_3
│ └── ...
├── shell
│ ├── index.txt
│ └── ...
├── pipes
│ ├── index.txt
│ └── ...
├── ...
├── contrib
│ ├── git ← missions pour apprendre git
│ │ ├── index.txt
│ │ ├── clone
│ │ ├── add
│ │ └── ...
│ ├── ssh ← missions pour apprendre ssh
│ │ ├── index.txt
│ │ └── ...
│ └── ...
└── ...Ici chaque dossier contenant des missions a aussi un ficher index.txt qui donne l'ordre des missions (un nom de dossier par ligne), et permet aussi de ne pas include certaines missions par défaut (voir le point 2), ce qui est utile si tu as des missions en cours de développement ou qui sont redondantes.
Avoir un fichier de configuration qui permet de sélectionner les missions à packager dans l'archive, où à utiliser quand on lance start.sh dans le dépôt. Ce fichier pourrait contenir un nom de dossier par line, et chaque ligne pourrait correspondre soit à un dossier de mission soit à un dossier contenant un index.txt, auquel cas toutes les missions du fichier sont ajoutées dans l'ordre. Donc par exemple, avec l'exemple plus haut tu pourrais faire un truc du genre:
basics
shell
contrib/git/clone
contrib/git/addDonc si je comprend bien, c'est une petite généralisation de ce que tu fais avec l'option -M de bin/archive.sh.
Est-ce que ce genre de chose te semble trop compliqué ?
phyver
commented
3 years ago (Dans les projets, il y a aussi de créer un script "auto exécutable", cf https://www.linuxjournal.com/node/1005818)
Cool, c'est rigolo, j'avais jamais réalisé que c'est aussi facile de faire ce genre de chose. Du coup ça veut dire que pour installer et lancer le jeu il suffira de faire un truc du genre
curl https://github.com/.../install.sh | sh?Oui. Dans l'idéal, quand tu quittes, ça créera automatiquement un nouveau fichier "auto exécutable" pour reprendre ta partie où tu en étais. J'attends d'avoir fini (plus ou moins) la partie traduction pour faire des essais.
Mais je crois quand même que ce serait facile de pouvoir classer les missions dans de sous-dossiers, et que ce soit plus facile d'expérimenter dans le dépôt. En gros, j'imagine qu'on pourrait s'en tirer avec les deux modifications suivantes:
Très bonne idée. J'ai fait un test pour avoir les missions dans in fichier, et c'est très facile. (En gros, ça suprime des lignes de codes !) Pareil, je vais attendre qu'une première version des traductions soit faite avant de pousser un peu plus loin.
Le programme des prochains jours est de finir une première passe pour traduire toutes les missions, puis refaire un passage sur toutes les missions pour uniformiser un peu le style, et tester un peu plus. Il faudrait trouver un "native speaker" qui fasse une ou deux parties complètes pour qu'il relise aussi tout ça.
Après, je rapatrierais cette branche sur mon dépot (i18n-devel) et commencerais à regarder un peu le reste.
rlepigre
commented
3 years ago Le programme des prochains jours est de finir une première passe pour traduire toutes les missions, puis refaire un passage sur toutes les missions pour uniformiser un peu le style, et tester un peu plus.
OK. Ce serait bien de se mettre d'accord sur le style comme ça je peux aussi t'aider pour ça. Par exemple il y a des endroits où on indente avec quatre espaces, et d'autre où il n'y en a que deux (je préfère deux comme les lignes peuvent être assez longues).
Il faudrait trouver un "native speaker" qui fasse une ou deux parties complètes pour qu'il relise aussi tout ça.
Je pensais faire jouer Bran pour ça! :) Je lui ai déjà posé quelques question, mais je vais la faire jouer aussi.
Après, je rapatrierais cette branche sur mon dépot (
i18n-devel) et commencerais à regarder un peu le reste.
OK cool. Il faudrait trouver quelqu'un qui a un mac pour voir si on n'a pas cassé trop de trucs.
phyver
commented
3 years ago On y est presque ! Il manque encore les missions 11, 24 et 25, que j'aimerais revoir un peu :
mv puis cp pour conserver la date est un peu artificiel. Suite à ton idée, je pensais faire un truc avec quelques tableaux, et demander à en copier un en fonction de la date. J'ai commencé à faire quelque chose, mais ce n'est pas fini.sleep et du tail.Je ne bosserais pas la dessus demain, alors si tu veux faire un truc, vas y !
Suite à ta suggestion, je viens de rajouter deux commandes gash test et gash assert_check true / gash assert_check false pour qu'on puisse faire des tests.
rlepigre
commented
3 years ago Je ne bosserais pas la dessus demain, alors si tu veux faire un truc, vas y !
OK, je regarderai ce soir si j'ai un moment !
Suite à ta suggestion, je viens de rajouter deux commandes
gash testetgash assert_check true/gash assert_check falsepour qu'on puisse faire des tests.
Cool ! Donc j'imagine que les "solutions" qu'on testera devront se terminer par l'une ou l'autre de ces commandes?
phyver
commented
3 years ago J'ai fait une nouvelle mission 11, en gardant la pipe !
J'ai hésité à demander de conserver la date du tableau (avec cp -a par exemple). Tu penses que c'est mieux avec ou sans ?
rlepigre
commented
3 years ago J'ai fait une nouvelle mission 11, en gardant la pipe ! J'ai hésité à demander de conserver la date du tableau (avec
cp -apar exemple). Tu penses que c'est mieux avec ou sans ?
Cool, la mission est bien mieux comme ça !
Je pense que c'est pas la peine de conserver la date, mais bon ça se défend. Perso j'ai jamais utilisé cp -a (ou je ne m'en souviens plus), donc je pense pas que ce soit super utile.
Par contre on pourrait peut-être utiliser cp -a dans une autre mission: on pourrait demander de copier un fichier en conservant la date, mais ne pas donner l'option directement, l'idée étant que le joueur doive utiliser man cp pour la trouver. C'est typiquement le genre d'option dont il est difficile de se souvenir et pour laquelle on utilise le manuel.
phyver
commented
3 years ago Perso j'ai jamais utilisé
cp -a(ou je ne m'en souviens plus), donc je pense pas que ce soit super utile.C'est pourtant bien pratique ! Et avec
-l, ça permet de faire un backup temporaire rapide...
J'ai commencé à implémenter ton idée pour gérer l'arborescence de missions que tu décrivais. Je laisse les missions comme elles sont pour le moment, mais il ne devrait plus avoir gand chose à faire. Pour le moment, la nouveauté, c'est que tu peux restreindre les missions qui seront initialisées et disponibles. Par exemple
$ ./start.sh -FRD2 missions/01_cd_1/ missions/21_head missions/35_trlancera une partie avec seulement 3 missions (et commencera à la deuxième).
phyver
commented
3 years ago Je viens de finir les dernières traductions. Je suis pas hyper contents de ces missions, mais je laisse leur amélioration pour plus tard.
Je fais un message avec les trucs à faire (normaliser un peu le style, en français comme en anglais, tester, etc.) demain.
rlepigre
commented
3 years ago Pour le moment, la nouveauté, c'est que tu peux restreindre les missions qui seront initialisées et disponibles.
Cool ! C'est déjà bien pratique pour essayer des missions.
D'ailleurs ça m'a fait réaliser que la gestion de la fin du jeu n'est pas géniale. Comme tu n'as pas traduit la mission 99 j'imagine que tu penses faire autre chose ? Peut-être gérer la fin du jeu dans lib/gameshell.sh directement en détectant qu'il n'y a pas de mission suivante ?
Au passage, je pense que ça pourrait être un bonne idée de supporter une sorte de plug-in : en gros des scripts supplémentaires lancés à l'initialisation où à la fin du jeu. Par exemple on pourrais déléguer les trucs du genre "demander le nom des étudiants" à un tel script, comme ça les utilisateurs peuvent choisir exactement ce dont ils ont besoin (rien du tout, un simple formulaire, récupérer des données sur un annuaire LDAP, ...). Et pour la fin du jeu ça pourrait être pratique pour produire des données pour la notation, ou envoyer directement ces données et une archive vers un serveur par exemple.
Je viens de finir les dernières traductions. Je suis pas hyper contents de ces missions, mais je laisse leur amélioration pour plus tard.
OK très bien. Je vais essayer toutes les missions dés que j'ai un moment, et voir si j'ai des idées. Mais oui, on peut toujours améliorer tout ça plus tard.
Je fais un message avec les trucs à faire (normaliser un peu le style, en français comme en anglais, tester, etc.) demain.
Ce serait bien de définir vaguement ce qu'on veut, par exemple pour les fichier "goal". Par exemple j'ai viré des indentations dans la list des commandes des premières missions, mais ce n'étais probablement pas une bonne idée pour l'uniformité. D'ailleurs est-ce que la syntaxe que tu utilises correspond à un format particulier (genre txt2tag)? Ou c'est juste un format ad-hoc? (Ce serait vraiment cool c'est de pouvoir écrire ces fichiers avec un format de type markdown et avoir un outil qui fait un rendu automatique dans la console avec les séquences d'échappement ANSI qui vont bien : titres en gras et soulignés, un peu de couleur, ...)
phyver
commented
3 years ago D'ailleurs ça m'a fait réaliser que la gestion de la fin du jeu n'est pas géniale. Comme tu n'as pas traduit la mission 99 j'imagine que tu penses faire autre chose ? Peut-être gérer la fin du jeu dans
lib/gameshell.shdirectement en détectant qu'il n'y a pas de mission suivante ?Pour le moment, s'il n'y a pas de mission suivante, ça provoque une erreur avec un message. Je vair ajouter une meilleure gestion en proposant de recommencer à la première mission, mais probablement pas plus dans
gameshell.sh.
Je cherche toujours une idée de "fin" pour une partie, que l'on pourrait ajouter dans une mission spécifique. La seule idée que j'ai eu, c'est de proposer de relancer GameShell à la première mission, en donnant accès aux commandes admin. Ça permet de refaire certaines missions, et d'explorer un peu plus.
Au passage, je pense que ça pourrait être un bonne idée de supporter une sorte de plug-in : en gros des scripts supplémentaires lancés à l'initialisation où à la fin du jeu.
Mmmm... C'est probablement pas rentable pour le moment. Peut-être le jour où GameShell aura des milliers d'utilisateurs !
Ce serait bien de définir vaguement ce qu'on veut, par exemple pour les fichier "goal".
Y'a la question du style linguistique :
- style direct "Cherchez la pièce d'or..."
- style indirect "Chercher la pièce d'or..." Je ne pense pas qu'on soit unitorme la dessus, et je ne suis pas sûr d'avoir une préference. Et toi ?
Ensuite, il y a le formatage. Sauf si tu as des arguments contre, je decide
Ma config vim pour les fichiers goal serait donc
set tabstop=2
set softtabstop=2
set expandtab
set autoindent
set shiftwidth=2
set smarttab
set textwidth=68
set formatoptions=tawqPour le moment, ce n'est pas plus formalisé que ça. Il y a toujours 2 sections : "objectif" et "commandes utiles", et pas vraiment de balises à part sur une ou deux missions. On pourrait dire :
**emphasis**``code ou commande``(Ce serait vraiment cool c'est de pouvoir écrire ces fichiers avec un format de type markdown et avoir un outil qui fait un rendu automatique dans la console avec les séquences d'échappement ANSI qui vont bien : titres en gras et soulignés, un peu de couleur, ...)
Je rajoute dans le TODO. C'est pas prioritaire, et il faudra un peu modifier la génération des parchements, car la taille des chaines ne correspondra plus à la taille des lignes.
rlepigre
commented
3 years ago Pour le moment, s'il n'y a pas de mission suivante, ça provoque une erreur avec un message. Je vair ajouter une meilleure gestion en proposant de recommencer à la première mission, mais probablement pas plus dans
gameshell.sh.
Oui, c'est tout ce dont on a besoin je pense.
Je cherche toujours une idée de "fin" pour une partie, que l'on pourrait ajouter dans une mission spécifique. La seule idée que j'ai eu, c'est de proposer de relancer GameShell à la première mission, en donnant accès aux commandes admin. Ça permet de refaire certaines missions, et d'explorer un peu plus.
Je sais pas si ce genre de chose est nécessaire. Peut-être qu'on pourrait juste afficher un message de fin, et puis proposer à l'utilisateur de refaire les missions de son choix en affichant l'index des missions (avec un gash index par exemple) et activer gash goto N même en mode non admin. Et puis proposer la même chose à nouveau dés que la mission est validé en affichant un récapitulatif des commandes disponibles: gash index, gash goto N, exit (pour quitter le jeu).
Au passage, je pense que ça pourrait être un bonne idée de supporter une sorte de plug-in : en gros des scripts supplémentaires lancés à l'initialisation où à la fin du jeu.
Mmmm... C'est probablement pas rentable pour le moment. Peut-être le jour où GameShell aura des milliers d'utilisateurs !
C'est peut-être pas rentable, mais s'il suffit de sourcer une liste de fichiers c'est simple et ça peut t'être utile pour faire certaines choses que tu ne veux pas nécessairement avoir dans le dépôt, et qui est spécifique à ton utilisation.
Ce serait bien de définir vaguement ce qu'on veut, par exemple pour les fichier "goal".
Y'a la question du style linguistique :
- style direct "Cherchez la pièce d'or..."
- style indirect "Chercher la pièce d'or..." Je ne pense pas qu'on soit unitorme la dessus, et je ne suis pas sûr d'avoir une préference. Et toi ?
Je préfère le style direct personnellement.
Ensuite, il y a le formatage. Sauf si tu as des arguments contre, je decide
- indentation de 2
- largeur maximale de 68
- espace en fin de ligne lorsqu'on reste dans le même paragraphe
OK, ça me semble bien. J'aime pas trop l'espace en fin de ligne, c'est pas mieux d'avoir une ligne vide ?
Pour le moment, ce n'est pas plus formalisé que ça. Il y a toujours 2 sections : "objectif" et "commandes utiles", et pas vraiment de balises à part sur une ou deux missions. On pourrait dire :
Il y a aussi des sections "objectifs secondaires" qui sont parfois utiles.
**emphasis**``code ou commande``
OK pourquoi pas, et on continue avec les titres soulignés avec ====== ou ------ (pour les sous-sections) ?
(Ce serait vraiment cool c'est de pouvoir écrire ces fichiers avec un format de type markdown et avoir un outil qui fait un rendu automatique dans la console avec les séquences d'échappement ANSI qui vont bien : titres en gras et soulignés, un peu de couleur, ...)
Je rajoute dans le TODO. C'est pas prioritaire, et il faudra un peu modifier la génération des parchements, car la taille des chaines ne correspondra plus à la taille des lignes.
Si on a une génération à partir d'un format de fichier spécifique (markdown ou autre) on peut imaginer que le générateur prenne un argument qui définisse la largeur des lignes, et coupe donc les paragraphes au bon endroit. Mais bon, tout ça c'est clairement pas prioritaire.
rlepigre
commented
3 years ago Je viens de faire quelques corrections!
J'ai remarqué qu'il y a un truc un peu étrange avec la mission 13: le fichier de traduction contient une entrée pour un treasure-msg/en.txt bien que ce fichier n'existe pas. (D'ailleurs il y a une erreur de cat quand on termine la mission.) Dans le cas de cette mission le treasure.sh est utilisé pour s'assurer qu'on aura toujours l'alias la dans le future, mais pas pour offrir une vraie récompense. Donc c'est normal qu'il n'existe pas de message. Par contre je ne sais pas quelle est la bonne façon de corriger dans lib/gameshell.sh: d'abord construire le nom de fichier avec gettext dans une variable, vérifier qu'elle est initialisée, puis vérifier l'existence du fichier?
J'ai passé un peu de temps à essayer de voir comment pourrait fonctionner l'internationalisation des missions, et voilà le résultat. En gros l'idée est d'avoir un dossier
localedans chaque mission, avec des fichiers.popour chaque langue supportée. Par example, j'ai crée des fichierslocale/fr.poetlocale/en.popour la mission 1.Pendant l'exécution de
start.shces fichiers sont transformés en fichiers.mo(parmsgfmt) et placé sous un dossierlocaleà la racine GameShell (avec l'arborescence qui va bien). Les fichiers ainsi crées prennent le nom du dossier de la mission (plus l'extension), ce qui veut dire qu'ils sont activés en exportantTEXTDOMAIN=nom_de_la_mission. En gros, ça veut dire qu'il faut s'arranger pour que les scripts de la mission (et les éventuels fichiers binaires) soient toujours lancés dans un environnement ouTEXTDOMAINcontient le nom du dossier de la mission. (J'ai pris pour convention de définirTEXTDOMAIN="gash"en dehors de l'exécution du code des missions.)L'autre chose à faire c'est d'exporter
TEXTDOMAINDIR="$GASH_BASE/locale"dansstart.sh.Un autre point intéressant est qu'on peut utiliser la variable
LANGUAGEpour controller la langues des messages. On peut même faire un truc commeLANGUAGE=fr_FR:fr:en_GB:en_US:enpour que le système donne la priorité au Français mais se rabatte sur l'anglais s'il n'est pas disponible. Il faudrait quand même s'assurer que les locales soient dispo pour une des langues du système (et queLANGUAGEest définie) parce que sinongettextne donne que la clé en résultat.Dernière remarque : j'ai utilisé un fichier
goal.shdans la mission pour pouvoir utilisergettext. C'est plus uniforme, et j'imagine que pour des missions compliquées on pourrait avoir besoin de générer les instructions donc c'est pas idiot. Une autre possibilité serait de s'assurer que les fichiers locales définissent toujours une entrée avec la clé"Mission goal", et on pourrait appelergettextdirectement depuislib/game_shell.sh.Qu'en penses-tu Pierre?