Derniers messages
Dernier message par neodarz - 09 Août 2018 à 13:53:00
Cliquez pour afficher le message
Salut,
Techniquement searx intègre déjà un crawler maison (de ce qu'ai je compris à l'arrache lors de la création de mes crawlers perso pour le searx de khaganat) afin d'aller chercher les infos des moteurs de recherches.
Je vais voir comment fonctionne scrapy mais il y a des chances que searx intègre scrapy dans son crawler maison, il faut que je me renseigne à ce sujet.
Dans l'idée il faudrait un soft qui permet de crawler + indexer les résultats. J'ai testé YACY (https://yacy.net/fr/) qui fait ce genre sur deux/trois des sites de khaganat et ça marchait plutot bien mais j'ai pas trop réussi à le faire fonctionner comme je souhaitais...
Pourquoi indexer ? On va éviter de crawler tous les sites à chaque recherche non ?
Ah et YACY c'est fait en JAVA donc je suis pas trop pour, j'ai pas envie de jouer avec du JAVA...
Techniquement searx intègre déjà un crawler maison (de ce qu'ai je compris à l'arrache lors de la création de mes crawlers perso pour le searx de khaganat) afin d'aller chercher les infos des moteurs de recherches.
Je vais voir comment fonctionne scrapy mais il y a des chances que searx intègre scrapy dans son crawler maison, il faut que je me renseigne à ce sujet.
Dans l'idée il faudrait un soft qui permet de crawler + indexer les résultats. J'ai testé YACY (https://yacy.net/fr/) qui fait ce genre sur deux/trois des sites de khaganat et ça marchait plutot bien mais j'ai pas trop réussi à le faire fonctionner comme je souhaitais...
Pourquoi indexer ? On va éviter de crawler tous les sites à chaque recherche non ?
Ah et YACY c'est fait en JAVA donc je suis pas trop pour, j'ai pas envie de jouer avec du JAVA...
Dernier message par Zatalyz - 24 Juillet 2018 à 16:37:11
Cliquez pour afficher le message
Neodarz nous avait préparé une installation de searx pour faire de la recherche globale sur plusieurs sites autour de Khaganat, Ryzom, Ryzom core (trouver la doc !) : https://git.khaganat.net/neodarz/ryzomcore_searx
Le besoin d'un méta-moteur continue de se poser. Certaines parties de notre site ne sont pas bien indexées par les moteurs traditionnels, et si vous cherchez "site:khaganat.net brumes" sur votre moteur préféré, vous ne verrez rien venir du forum par exemple (alors que la recherche interne du forum ne marche pas trop mal). Si vous chercher un nom d'utilisateur sur le gitlab... vous n'allez pas avoir son profil, la liste de ses projets, ses contributions, ses issues... ou alors un peu, si vous avez de la chance. Le moteur de recherche interne de gitlab est pourri et c'est une volonté : le "bon" moteur est dans la version payante.
Searx répond au besoin d'agglomérer les résultats des divers moteurs internes, mais il n'a pas de crawler interne (ou araignée, c'est plus joli). Donc ça ne résous pas le souci de gitlab. Il faudrait donc ajouter un crawler, que Searx peut ensuite interroger ; ou faire un crawler qui récupère tous les sites.
J'ai commencé à regarder un peu https://scrapy.org/ , qui est en python. Je vous avoue que j'ai mis de côté les crawlers en java, peut-être à tort.
Je ne peux pas tester beaucoup plus avant, j'ai cassé Nuxru pour le moment et ma vm de test était dessus. De votre côté, si vous avez déjà croisé des trucs de ce genre, si vous connaissez des solutions à cette problématique, laissez vos infos ici
Le besoin d'un méta-moteur continue de se poser. Certaines parties de notre site ne sont pas bien indexées par les moteurs traditionnels, et si vous cherchez "site:khaganat.net brumes" sur votre moteur préféré, vous ne verrez rien venir du forum par exemple (alors que la recherche interne du forum ne marche pas trop mal). Si vous chercher un nom d'utilisateur sur le gitlab... vous n'allez pas avoir son profil, la liste de ses projets, ses contributions, ses issues... ou alors un peu, si vous avez de la chance. Le moteur de recherche interne de gitlab est pourri et c'est une volonté : le "bon" moteur est dans la version payante.
Searx répond au besoin d'agglomérer les résultats des divers moteurs internes, mais il n'a pas de crawler interne (ou araignée, c'est plus joli). Donc ça ne résous pas le souci de gitlab. Il faudrait donc ajouter un crawler, que Searx peut ensuite interroger ; ou faire un crawler qui récupère tous les sites.
J'ai commencé à regarder un peu https://scrapy.org/ , qui est en python. Je vous avoue que j'ai mis de côté les crawlers en java, peut-être à tort.
Je ne peux pas tester beaucoup plus avant, j'ai cassé Nuxru pour le moment et ma vm de test était dessus. De votre côté, si vous avez déjà croisé des trucs de ce genre, si vous connaissez des solutions à cette problématique, laissez vos infos ici
Dernier message par Zatalyz - 22 Juillet 2018 à 11:59:45
Cliquez pour afficher le message
Je suis en train de chercher une solution automatique pour les gens qui vont débarquer sur IRC après notre passage à XMPP (car il y en aura).
Ce que j'ai pu trouver d'utile :
http://web.archive.org/web/20080305043840/http://supybot.sourceforge.net:80/docs/plugins/Utilities.html
http://web.archive.org/web/20080227013210/http://supybot.sourceforge.net:80/docs/plugins/Note.html
http://web.archive.org/web/20090204171755/http://supybot.sourceforge.net:80/docs/plugins/Scheduler.html
et
https://github.com/ProgVal/Supybot-plugins/tree/master/Trigger
L'idéal serait que si quelqu'un se connecte ET parle, son premier message donne lieu à une réponse de pendorid, lui expliquant qu'on est sur XMPP. mais uniquement un message par jour par personne, sinon bonjour le flood. Ça élimine le trigger "si quelqu'un se connecte" car il y a des gens qui co/déco régulièrement (réseau instable). Faire aussi une whitelist avec les gens déjà prévenus et sur XMPP serait un plus, j'ai pas envie de me faire spammer si je débarque pour aider une perdue
Ce que j'ai pu trouver d'utile :
http://web.archive.org/web/20080305043840/http://supybot.sourceforge.net:80/docs/plugins/Utilities.html
http://web.archive.org/web/20080227013210/http://supybot.sourceforge.net:80/docs/plugins/Note.html
http://web.archive.org/web/20090204171755/http://supybot.sourceforge.net:80/docs/plugins/Scheduler.html
et
https://github.com/ProgVal/Supybot-plugins/tree/master/Trigger
L'idéal serait que si quelqu'un se connecte ET parle, son premier message donne lieu à une réponse de pendorid, lui expliquant qu'on est sur XMPP. mais uniquement un message par jour par personne, sinon bonjour le flood. Ça élimine le trigger "si quelqu'un se connecte" car il y a des gens qui co/déco régulièrement (réseau instable). Faire aussi une whitelist avec les gens déjà prévenus et sur XMPP serait un plus, j'ai pas envie de me faire spammer si je débarque pour aider une perdue
Dernier message par Zatalyz - 29 Juin 2018 à 22:15:02
Cliquez pour afficher le message
Artefact = artifact en anglais, ça aide pour les recherches.
Mon hypothèse actuelle est qu'il y a un ou des timeouts à régler dans /etc/gitlab/gitlab.rb. Mais je vais avoir besoin de plus de détails pour savoir ce qui est en cause. Typiquement : minuter et me dire quand ça plante, si c'est 30s, 1mn ou 1heure ça donne de sacrés indices. Les messages d'erreur complet, l'heure et la date si possible.
Comme je ne serais pas là jeudi, mieux vaut me laisser les infos ici, je verrais dès que je peux... Si Shepeng est là ce jour là et a envie de regarder, par rapport à la doc de gitlab, notre installation est celle baptisée "omnibus"
Log du soir à propos du souci.
Mon hypothèse actuelle est qu'il y a un ou des timeouts à régler dans /etc/gitlab/gitlab.rb. Mais je vais avoir besoin de plus de détails pour savoir ce qui est en cause. Typiquement : minuter et me dire quand ça plante, si c'est 30s, 1mn ou 1heure ça donne de sacrés indices. Les messages d'erreur complet, l'heure et la date si possible.
Comme je ne serais pas là jeudi, mieux vaut me laisser les infos ici, je verrais dès que je peux... Si Shepeng est là ce jour là et a envie de regarder, par rapport à la doc de gitlab, notre installation est celle baptisée "omnibus"
Log du soir à propos du souci.
Spoiler for Hiden:
bon c'est pas grave, y'a de la place en plus
Dernier message par Zatalyz - 27 Avril 2018 à 12:05:24
Cliquez pour afficher le message
Bonjour les Mages !
Ce sujet fait écho à cet aspect du cahier des charges : https://khaganat.net/wikhan/fr:gamedesign:khanat:start#gestion_de_compte
Pour les aspects web, ça se réglera au fur et à mesure, ce n'est pas vraiment le problème ; le travail de Tycho Brahe sur Django est un pas dans la bonne voie.
Mais il y a l'aspect client de jeu. En effet, il faudrait qu'on puisse lancer le jeu, se connecter avec son compte "joueuse", et de là choisir son perso en cassant la limite actuelle de "5 perso max par compte ; si un compte est connecté, impossible de connecter un des autres perso".
La solution propre et longue demanderais de réécrire le client. Pourquoi pas, un jour.
Mais j'ai l'idée d'un hack beaucoup plus simple, qui pourrait rapidement être mis en place.
L'idée est de faire une surcouche. C'est à dire de créer un lanceur (dans le langage de vos rêves, ou de reprendre ce que Ryzom a fait si c'est utile ?), indépendant du client. Ce lanceur permet de connecter son compte Khaganat (compte joueuse, donc), puis d'afficher la liste des personnages liés à ce compte, qu'on devrait pouvoir récupérer de la BDD, ainsi que de proposer la création d'un personnage.
Au moment où on choisit un personnage/on créé un personnage, alors le lanceur lance un client de jeu. Ce client-là reçoit automatiquement des infos de connexion (rien à entrer) et sélectionne le premier personnage. Ce qui veut dire que chaque sous-compte n'aura qu'un seul personnage, en fait.
Un petit schéma pour tenter d'expliquer...
https://liev.re/cloud/s/7m9ngh6MQlCGZoZ
Cela veut dire plusieurs choses :
Primo, il n'y a pas besoin de trop toucher aux clients de jeu actuel. Il faut juste trouver
- comment lancer automatiquement le slot 0
- comment créer automatiquement un compte dans la BDD. Il faut absolument enlever l'obligation du mail.
- comment lancer directement le créateur de personnage.
- quel appel envoyer pour supprimer un compte.
Et c'est tout côté client actuel, oui oui.
Secundo, côté lanceur maison, il faut construire un truc de zéro mais c'est assez basique et ne demandera pas un dev expert. Le plus compliqué sera l'habillage graphique mais y'a des bibliothèques pour ça. La gestion du compte devra se faire via la BDD de django.
Cela veut dire :
- une base de donnée qui sait que le compte général a accès aux comptes de jeu "clients X, Y , Z", et qui enverra ces infos au client de jeu (notez bien : l'association "compte général-comptes de jeu se fait côté maison, pas côté client de jeu, ce qui permettra de gérer la sécurité des comptes en amont de façon moderne avec django), qui peut aussi récupérer le nom des persos pour l'afficher.
- la possibilité, en cliquant sur "jouer" et "créer un perso", de lancer le client avec l'option correspondante. Dans le cas de "supprimer", c'est juste un envoi à la BDD pour vider l'info en question.
- les options "créer un compte", "mot de passe perdu", "Aide" renvoient toutes à la gestion générale des comptes, via Django.
- l'option "paramètres" doit permettre de gérer a priori la configuration graphique du client, afin de pouvoir le lancer en mode "minimum" si besoin. C'est secondaire pour le moment. Notez qu'il s'agit en principe juste de changer le fichier "client.cfg".
- Pour le moment, pas de prévisualisation 3d des persos, on se contentera d'afficher leur nom. Dans un second temps, je pense qu'on peut facilement associer un portrait à chaque nom, et dans un 3e temps ce sera possible de remettre la version 3d si vraiment on y tiens mais... ça ne me semble vraiment pas vital.
Cela veut aussi dire que via le lanceur de base, on peut lancer plusieurs clients en même temps et donc jouer avec plusieurs persos sous le même compte. Cela enlève la restriction de "5 perso max par compte" ainsi que "impossible de jouer 2 persos d'un même compte" : en réalité ces restrictions existent toujours dans le client, mais en tant que joueuse on ne les voit plus.
Il ne me reste que deux soucis.
D'abord, la gestion des patchs. On peut se dire que ça patche lors de la sélection du perso, et comme tout utilise le même dossier, si c'est patché pour un perso, c'est ok ; mais lors des patch il y a redémarrage des clients et dans ce cas précis ça va ptet mettre le bazar. Il faut voir avec nos experts du patch. Peut-être que le lanceur devra lancer un test en amont.
Ensuite, des détails lorsqu'on joue plusieurs perso en même temps (cas où on lance 2 ou 3 fois le client en parallèle sur son ordi. Déjà, ça prend plus de ressource qu'un seul client, donc quand je faisais ça, je mettais tous les paramètres au minimum. Là, est-ce qu'on pourra gérer ça proprement, switcher facilement entre "tout à fond parce que j'ai un seul client" et "tout au minimum parce que j'en lance 3" ?
De plus, gérer plus d'un personnage à la fois c'est prendre le risque de s'emmêler les pinceaux... personnellement je m'aidais un peu en mettant un fond de couleur différent pour mes fenêtres en jeu suivant le compte lancé. Or, pour que ça marche, j'utilisais plusieurs dossiers pour chacun de mes clients car il fallait modifier des fichiers locaux. Là, pourrait-on arriver à quelque chose de similaire sans dupliquer les dossier ?
Les détails à propos du multi-perso ne me semblent pas important pour le moment, mais si vous voyez comment gérer ça proprement, partagez vos idées.
Ce sujet fait écho à cet aspect du cahier des charges : https://khaganat.net/wikhan/fr:gamedesign:khanat:start#gestion_de_compte
Pour les aspects web, ça se réglera au fur et à mesure, ce n'est pas vraiment le problème ; le travail de Tycho Brahe sur Django est un pas dans la bonne voie.
Mais il y a l'aspect client de jeu. En effet, il faudrait qu'on puisse lancer le jeu, se connecter avec son compte "joueuse", et de là choisir son perso en cassant la limite actuelle de "5 perso max par compte ; si un compte est connecté, impossible de connecter un des autres perso".
La solution propre et longue demanderais de réécrire le client. Pourquoi pas, un jour.
Mais j'ai l'idée d'un hack beaucoup plus simple, qui pourrait rapidement être mis en place.
L'idée est de faire une surcouche. C'est à dire de créer un lanceur (dans le langage de vos rêves, ou de reprendre ce que Ryzom a fait si c'est utile ?), indépendant du client. Ce lanceur permet de connecter son compte Khaganat (compte joueuse, donc), puis d'afficher la liste des personnages liés à ce compte, qu'on devrait pouvoir récupérer de la BDD, ainsi que de proposer la création d'un personnage.
Au moment où on choisit un personnage/on créé un personnage, alors le lanceur lance un client de jeu. Ce client-là reçoit automatiquement des infos de connexion (rien à entrer) et sélectionne le premier personnage. Ce qui veut dire que chaque sous-compte n'aura qu'un seul personnage, en fait.
Un petit schéma pour tenter d'expliquer...
https://liev.re/cloud/s/7m9ngh6MQlCGZoZ
Cela veut dire plusieurs choses :
Primo, il n'y a pas besoin de trop toucher aux clients de jeu actuel. Il faut juste trouver
- comment lancer automatiquement le slot 0
- comment créer automatiquement un compte dans la BDD. Il faut absolument enlever l'obligation du mail.
- comment lancer directement le créateur de personnage.
- quel appel envoyer pour supprimer un compte.
Et c'est tout côté client actuel, oui oui.
Secundo, côté lanceur maison, il faut construire un truc de zéro mais c'est assez basique et ne demandera pas un dev expert. Le plus compliqué sera l'habillage graphique mais y'a des bibliothèques pour ça. La gestion du compte devra se faire via la BDD de django.
Cela veut dire :
- une base de donnée qui sait que le compte général a accès aux comptes de jeu "clients X, Y , Z", et qui enverra ces infos au client de jeu (notez bien : l'association "compte général-comptes de jeu se fait côté maison, pas côté client de jeu, ce qui permettra de gérer la sécurité des comptes en amont de façon moderne avec django), qui peut aussi récupérer le nom des persos pour l'afficher.
- la possibilité, en cliquant sur "jouer" et "créer un perso", de lancer le client avec l'option correspondante. Dans le cas de "supprimer", c'est juste un envoi à la BDD pour vider l'info en question.
- les options "créer un compte", "mot de passe perdu", "Aide" renvoient toutes à la gestion générale des comptes, via Django.
- l'option "paramètres" doit permettre de gérer a priori la configuration graphique du client, afin de pouvoir le lancer en mode "minimum" si besoin. C'est secondaire pour le moment. Notez qu'il s'agit en principe juste de changer le fichier "client.cfg".
- Pour le moment, pas de prévisualisation 3d des persos, on se contentera d'afficher leur nom. Dans un second temps, je pense qu'on peut facilement associer un portrait à chaque nom, et dans un 3e temps ce sera possible de remettre la version 3d si vraiment on y tiens mais... ça ne me semble vraiment pas vital.
Cela veut aussi dire que via le lanceur de base, on peut lancer plusieurs clients en même temps et donc jouer avec plusieurs persos sous le même compte. Cela enlève la restriction de "5 perso max par compte" ainsi que "impossible de jouer 2 persos d'un même compte" : en réalité ces restrictions existent toujours dans le client, mais en tant que joueuse on ne les voit plus.
Il ne me reste que deux soucis.
D'abord, la gestion des patchs. On peut se dire que ça patche lors de la sélection du perso, et comme tout utilise le même dossier, si c'est patché pour un perso, c'est ok ; mais lors des patch il y a redémarrage des clients et dans ce cas précis ça va ptet mettre le bazar. Il faut voir avec nos experts du patch. Peut-être que le lanceur devra lancer un test en amont.
Ensuite, des détails lorsqu'on joue plusieurs perso en même temps (cas où on lance 2 ou 3 fois le client en parallèle sur son ordi. Déjà, ça prend plus de ressource qu'un seul client, donc quand je faisais ça, je mettais tous les paramètres au minimum. Là, est-ce qu'on pourra gérer ça proprement, switcher facilement entre "tout à fond parce que j'ai un seul client" et "tout au minimum parce que j'en lance 3" ?
De plus, gérer plus d'un personnage à la fois c'est prendre le risque de s'emmêler les pinceaux... personnellement je m'aidais un peu en mettant un fond de couleur différent pour mes fenêtres en jeu suivant le compte lancé. Or, pour que ça marche, j'utilisais plusieurs dossiers pour chacun de mes clients car il fallait modifier des fichiers locaux. Là, pourrait-on arriver à quelque chose de similaire sans dupliquer les dossier ?
Les détails à propos du multi-perso ne me semblent pas important pour le moment, mais si vous voyez comment gérer ça proprement, partagez vos idées.
Dernier message par Zatalyz - 07 Mars 2018 à 14:51:44
Cliquez pour afficher le message
J'en suis à une interrogation de design... Et aussi la certitude que je devrais faire de cette fonctionnalité d'onglets un plugin et pas mettre ça dans le code. Mais bon avant que je fasse un plugin faudrait que je lise plus de doc, et comment dire... 
Bref, toujours est-il qu'il faut décider de certains comportements.
Option numéro 1 : on ne change presque rien à ce qui existe actuellement
Ça veut dire que :
- les pages "générales" sont sous la forme de lien "fr:page"
- les autres pages sont sous la forme "fr:onglet:page" (donc fr:gameplay:page, fr:animation:page, etc)
À noter que j'ai mis les pages discussions au même niveau que les autres : fr:talk:page (et plus talk:fr:page qui est le truc actuel).
Option numéro 2 : la page générale a son onglet
Ça veut dire qu'on n'aura plus, par exemple, de fr:branaz, mais fr:general:branaz.
La première conséquence c'est que tous les liens externes à l'um1 qui pointe vers une page de l'um1 deviendront faux (faudra rajouter "general"). On peut faire une redirection automatique, par contre : si on arrive sur fr:page, ça redirige en automatique sur fr:general:page. Mais cette redirection auto empêche du coup d'utiliser fr:page pour autre chose. Est-ce bien utile de la bloquer ?
La seconde conséquence, un peu trivial, c'est que je trouve moins intuitif de créer sa page en mettant "general" dans le namespace et que ça alourdit d'autant les liens. Mais bon c'est juste une habitude à prendre.
Enfin, ça demande de déplacer toutes les pages dans l'espace de nom fr ; y'a des outils pour assister ça, mais je ne sais pas trop comment ça va se passer, je crains un peu les soucis (faut pas faire du recursif).
Option bis : les onglets ne s'affichent que dans des espaces de noms précis
Ça, ce serait clairement plus simple si j'en faisais un plugin... bref, vu le fonctionnement de l'um1, les pages encyclopédiques sont intéressantes avec les onglets (branaz, ra, blasa, etc) mais c'est moins vrai dans certains espaces de noms. Les pages sous les espaces de nom tag(génération du menu par catégorie), user (pages persos), wiki (pages d'explication de comment marche le wiki) : on s'en fout des onglets.
C'est un peu plus complexe à faire pour moi mais si c'est un idéal à atteindre, je peux le mettre sur la todoliste. À voir si on s'en fout ou pas.
Il s'agit donc surtout de trancher entre l'option 1 et 2. J'attends vos retours.
Bref, toujours est-il qu'il faut décider de certains comportements.
Option numéro 1 : on ne change presque rien à ce qui existe actuellement
Ça veut dire que :
- les pages "générales" sont sous la forme de lien "fr:page"
- les autres pages sont sous la forme "fr:onglet:page" (donc fr:gameplay:page, fr:animation:page, etc)
À noter que j'ai mis les pages discussions au même niveau que les autres : fr:talk:page (et plus talk:fr:page qui est le truc actuel).
Option numéro 2 : la page générale a son onglet
Ça veut dire qu'on n'aura plus, par exemple, de fr:branaz, mais fr:general:branaz.
La première conséquence c'est que tous les liens externes à l'um1 qui pointe vers une page de l'um1 deviendront faux (faudra rajouter "general"). On peut faire une redirection automatique, par contre : si on arrive sur fr:page, ça redirige en automatique sur fr:general:page. Mais cette redirection auto empêche du coup d'utiliser fr:page pour autre chose. Est-ce bien utile de la bloquer ?
La seconde conséquence, un peu trivial, c'est que je trouve moins intuitif de créer sa page en mettant "general" dans le namespace et que ça alourdit d'autant les liens. Mais bon c'est juste une habitude à prendre.
Enfin, ça demande de déplacer toutes les pages dans l'espace de nom fr ; y'a des outils pour assister ça, mais je ne sais pas trop comment ça va se passer, je crains un peu les soucis (faut pas faire du recursif).
Option bis : les onglets ne s'affichent que dans des espaces de noms précis
Ça, ce serait clairement plus simple si j'en faisais un plugin... bref, vu le fonctionnement de l'um1, les pages encyclopédiques sont intéressantes avec les onglets (branaz, ra, blasa, etc) mais c'est moins vrai dans certains espaces de noms. Les pages sous les espaces de nom tag(génération du menu par catégorie), user (pages persos), wiki (pages d'explication de comment marche le wiki) : on s'en fout des onglets.
C'est un peu plus complexe à faire pour moi mais si c'est un idéal à atteindre, je peux le mettre sur la todoliste. À voir si on s'en fout ou pas.
Il s'agit donc surtout de trancher entre l'option 1 et 2. J'attends vos retours.
Dernier message par Zatalyz - 17 Février 2018 à 18:45:15
Cliquez pour afficher le message
J'ai pas mal avancé ; j'ai même pushé ça :
https://git.khaganat.net/zatalyz/khum1-doku
Depuis le dernier commit j'ai encore ajouté quelques trucs mais bon, flemme, tout ça. Même si ce n'est pas parfait, ça marche relativement bien. Il faut que je peaufine des détails, que je teste ça comme il faut et si c'est bon, je ferais le reste du thème façon Um1. Mon regret est qu'actuellement, vu comme c'est fait, les onglets ne sont pas dynamiques ; je vois bien comment faire pour qu'on déclare les onglets qu'on veut dans l'interface d'admin, mais pas comment les gérer dans le code, donc c'est tout en dur. Et flute. Mais qui sait, je finirais peut-être aussi par m'y attaquer... ou quelqu'un pourra refactoriser ce code qui a au moins le mérite d'être commenté et verbeux à l'extrême.
Alleluia !
https://git.khaganat.net/zatalyz/khum1-doku
Depuis le dernier commit j'ai encore ajouté quelques trucs mais bon, flemme, tout ça. Même si ce n'est pas parfait, ça marche relativement bien. Il faut que je peaufine des détails, que je teste ça comme il faut et si c'est bon, je ferais le reste du thème façon Um1. Mon regret est qu'actuellement, vu comme c'est fait, les onglets ne sont pas dynamiques ; je vois bien comment faire pour qu'on déclare les onglets qu'on veut dans l'interface d'admin, mais pas comment les gérer dans le code, donc c'est tout en dur. Et flute. Mais qui sait, je finirais peut-être aussi par m'y attaquer... ou quelqu'un pourra refactoriser ce code qui a au moins le mérite d'être commenté et verbeux à l'extrême.
Alleluia !
Dernier message par Zatalyz - 17 Février 2018 à 14:20:42
Cliquez pour afficher le message
Les onglets
Ha ce morceau...
Pour résumer : sur l'um1 nous avons, au dessus des articles, des onglets (général, animation, gameplay etc...). Ce qui est très bien, sauf que cela a été fait il y a plusieurs années, par quelqu'un qui ne maitrisait pas bien dokuwiki et php. Donc, le code est un assemblage de trucs piqués ici et là (dont des morceaux inutiles) et surtout : je ne peux pas remettre le thème à jour parce que cette fonction me bloque. C'est tentaculaire, tel que c'est fait, et je finis toujours par casser des trucs en nettoyant parce que c'est pas clair du tout. Il me faut un truc que je puisse ensuite coller où je veux dans mon nouveau thème. Mais c'est moins trivial que ça n'en a l'air car tous ceux à qui j'ai tenté de confier le job se sont enfuis en hurlant, visiblement rendus fous par les appels à des choses immondes dont nul ne devrait parler.
La problématique est aussi détaillé (avec le code actuel et des idées) ici : https://git.khaganat.net/khaganat/website_jukni/issues/8
Je finirais par y arriver. Si.
Un lien dans l'UM1 ressemble ensuite en gros à ceci (après https://khaganat.net/um1/ ) :
$lang:$tab:<ns>:$id
où :
- $lang est le code de langue déclaré dans le plugin translate
- $tab est le nom des onglets (chez nous, donc, "Général, Animation, Gameplay, Développement, Discussion")
- <ns> : il peut potentiellement y avoir des sous-espaces de nom, même si en théorie, non...
- $id : le nom de la page
En théorie, le lien commence toujours par "$lang:$tab:" et se termine toujours par ":$id". Et en gros, il faut que j'arrive à générer ces variables proprement, suivant où le visiteur se situe dans l'arborescence.
L'un de mes premiers problèmes est de détecter si on est sur du wiki multilingue, et si oui, prendre l'espace de nom avec le code de lang et le traiter à part. Alors, oui : sur Khaganat le multilangue est activé partout, mais je souhaiterais partager ce thème à la communauté Dokuwiki (quelle ambition) et donc je ne dois pas supposer que forcément, il existe...
Détecter si le plugin est actif, ça se fait comme ça :
Et il y a le code suivant qui me retrouve les langues configurées pour le wiki :
Seul souci, je ne sais pas comment traiter ce que je reçois avec explode. Ok, je récupère "en", "fr" et autre ; je sais que comme la condition du plugin existant est rempli, je trouve ça en début de chaine. Mais je ne vois pas trop la suite. Probable même que ça ne me serve à rien, tout ça...
Ha ce morceau...
Pour résumer : sur l'um1 nous avons, au dessus des articles, des onglets (général, animation, gameplay etc...). Ce qui est très bien, sauf que cela a été fait il y a plusieurs années, par quelqu'un qui ne maitrisait pas bien dokuwiki et php. Donc, le code est un assemblage de trucs piqués ici et là (dont des morceaux inutiles) et surtout : je ne peux pas remettre le thème à jour parce que cette fonction me bloque. C'est tentaculaire, tel que c'est fait, et je finis toujours par casser des trucs en nettoyant parce que c'est pas clair du tout. Il me faut un truc que je puisse ensuite coller où je veux dans mon nouveau thème. Mais c'est moins trivial que ça n'en a l'air car tous ceux à qui j'ai tenté de confier le job se sont enfuis en hurlant, visiblement rendus fous par les appels à des choses immondes dont nul ne devrait parler.
La problématique est aussi détaillé (avec le code actuel et des idées) ici : https://git.khaganat.net/khaganat/website_jukni/issues/8
Je finirais par y arriver. Si.
Un lien dans l'UM1 ressemble ensuite en gros à ceci (après https://khaganat.net/um1/ ) :
$lang:$tab:<ns>:$id
où :
- $lang est le code de langue déclaré dans le plugin translate
- $tab est le nom des onglets (chez nous, donc, "Général, Animation, Gameplay, Développement, Discussion")
- <ns> : il peut potentiellement y avoir des sous-espaces de nom, même si en théorie, non...
- $id : le nom de la page
En théorie, le lien commence toujours par "$lang:$tab:" et se termine toujours par ":$id". Et en gros, il faut que j'arrive à générer ces variables proprement, suivant où le visiteur se situe dans l'arborescence.
L'un de mes premiers problèmes est de détecter si on est sur du wiki multilingue, et si oui, prendre l'espace de nom avec le code de lang et le traiter à part. Alors, oui : sur Khaganat le multilangue est activé partout, mais je souhaiterais partager ce thème à la communauté Dokuwiki (quelle ambition) et donc je ne dois pas supposer que forcément, il existe...
Détecter si le plugin est actif, ça se fait comme ça :
Code Sélectionner
if ($translation)
echo "translate" ;
else
echo "notranslate";
Et il y a le code suivant qui me retrouve les langues configurées pour le wiki :
Code Sélectionner
$tab_lang = explode(" ", $conf["plugin"]["translation"]["translations"]) ;
Seul souci, je ne sais pas comment traiter ce que je reçois avec explode. Ok, je récupère "en", "fr" et autre ; je sais que comme la condition du plugin existant est rempli, je trouve ça en début de chaine. Mais je ne vois pas trop la suite. Probable même que ça ne me serve à rien, tout ça...
Dernier message par Zatalyz - 17 Février 2018 à 11:54:25
Cliquez pour afficher le message
Ce sujet est là pour discuter des diverses particularités de Dokuwiki. Comme tout le monde doit le savoir ici, je porte un amour immodéré à ce logiciel, qui n'a que des qualités (ou presque). Bon, malgré tout, je patine un peu sur certains aspects où de l'aide est toujours bienvenue... donc ce sujet permettra de discuter de ce genre de choses. IRC ne se prête pas trop à ces informations qui ont besoin de structure et de pérennité.
TychoBrahe travaille actuellement sur Django, qui va nous fournir la barre de navigation générale. Cette barre est multilingue (alleluia !). Pour l'intégration dans Django, il suffit de l'exporter en php, puis de l'inclure dans le thème Dokuwiki.
Premier aspect : l'internationalisation.
Dokuwiki détecte la langue de l'utilisateur selon plusieurs paramètres. Par défaut il donne au visiteur le wiki dans la langue pour laquelle son navigateur est configuré, ou l'anglais s'il n'a pas cette langue. Comme j'ai activé le plugin Translation, il y a une gestion multilingue du wiki et si le visiteur passe d'un article en français à sa version en anglais, l'interface passe aussi du français à l'anglais.
Les traductions du thème (ce qui sera notre cas ici) se placent dans un dossier du template. Le chemin précis est dokuwiki/lib/tpl/<template>/lang/<ISO-code>/ ; ce qui donne dans le cas de la barre de navigation pour le template "wikhan" quelque chose comme
dokuwiki/lib/tpl/wikhan/lang/fr/khanav.php et dokuwiki/lib/tpl/wikhan/lang/en/khanav.php
Pour l'interface générale, le fichier appelé doit être lang.php dans lang/<ISO-code>/ . Mais il est déjà utilisé pour d'autres choses dans le thème et ne devrait pas être écrasé si on régénère la barre de navigation. Ceci dit, c'est du php, donc il suffit d'ajouter à la fin
Voici l'exemple d'un fichier lang/fr/khanav.php :
Et voici le bout de code qui me permet de voir ce message dans dokuwiki (bout que j'ai ajouté dans le main.php du template, mais osef) :
Note : il y a très probablement plus élégant et si vous voyez comment faire ça, proposez-moi. Mais ça, ça marche.
TychoBrahe travaille actuellement sur Django, qui va nous fournir la barre de navigation générale. Cette barre est multilingue (alleluia !). Pour l'intégration dans Django, il suffit de l'exporter en php, puis de l'inclure dans le thème Dokuwiki.
Premier aspect : l'internationalisation.
Dokuwiki détecte la langue de l'utilisateur selon plusieurs paramètres. Par défaut il donne au visiteur le wiki dans la langue pour laquelle son navigateur est configuré, ou l'anglais s'il n'a pas cette langue. Comme j'ai activé le plugin Translation, il y a une gestion multilingue du wiki et si le visiteur passe d'un article en français à sa version en anglais, l'interface passe aussi du français à l'anglais.
Les traductions du thème (ce qui sera notre cas ici) se placent dans un dossier du template. Le chemin précis est dokuwiki/lib/tpl/<template>/lang/<ISO-code>/ ; ce qui donne dans le cas de la barre de navigation pour le template "wikhan" quelque chose comme
dokuwiki/lib/tpl/wikhan/lang/fr/khanav.php et dokuwiki/lib/tpl/wikhan/lang/en/khanav.php
Pour l'interface générale, le fichier appelé doit être lang.php dans lang/<ISO-code>/ . Mais il est déjà utilisé pour d'autres choses dans le thème et ne devrait pas être écrasé si on régénère la barre de navigation. Ceci dit, c'est du php, donc il suffit d'ajouter à la fin
Code Sélectionner
include('khanav.php'); et ça marche.Voici l'exemple d'un fichier lang/fr/khanav.php :
Code Sélectionner
<?php
$lang['khanav_test'] = "Ceci est un test incroyable.";
Et voici le bout de code qui me permet de voir ce message dans dokuwiki (bout que j'ai ajouté dans le main.php du template, mais osef) :
Code Sélectionner
<div><?php
$khanav_test = tpl_getLang('khanav_test');
echo $khanav_test ;
?></div>Note : il y a très probablement plus élégant et si vous voyez comment faire ça, proposez-moi. Mais ça, ça marche.
Dernier message par shepeng - 28 Janvier 2018 à 17:00:59
Cliquez pour afficher le message
xen-tools utilise debootstrap pour installer sa VM, il faut trouver un moyen d'installer la distribution cliente sur la partition prévue. Tu peux utiliser l'installateur prévu de la distribution, en faisant une VM utilisant hvm et démarrant depuis une image iso du CD d'installation, ou trouver un outil capable d'installer la distribution cible dans un chroot ou sur un répertoire précis. Ça va dépendre de la distribution cible.
Personnellement je n'utilise plus xen-tools pour créer mes VM mais un playbook ansible. Ce playbook fait toutes les étapes de xen-tools, plus certaines autres (pas exemple ajout de mes clés publiques dans la config ssh), il n'y aurait qu'à remplacer la partie concernant debootstrap dans ce playbook pour l'adapter à une autre distrib.
Personnellement je n'utilise plus xen-tools pour créer mes VM mais un playbook ansible. Ce playbook fait toutes les étapes de xen-tools, plus certaines autres (pas exemple ajout de mes clés publiques dans la config ssh), il n'y aurait qu'à remplacer la partie concernant debootstrap dans ce playbook pour l'adapter à une autre distrib.
