Passer le menu

Messages récents

Pages: [1] 2 3 ... 10
1
Programmation / Re : Dokuwiki, quelques détails
« Dernier message par Zatalyz le 17 février 2018 à 18:45:15 »
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 !  :ola:
2
Programmation / Re : Dokuwiki, quelques détails
« Dernier message par Zatalyz le 17 février 2018 à 14:20:42 »
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 :
if ($translation)
echo "translate" ;
else
echo "notranslate";


Et il y a le code suivant qui me retrouve les langues configurées pour le wiki :
$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...
3
Programmation / Dokuwiki, quelques détails
« Dernier message par Zatalyz le 17 février 2018 à 11:54:25 »
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 include('khanav.php'); et ça marche.

Voici l'exemple d'un fichier lang/fr/khanav.php :
<?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) :
<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.
4
Annonces / Obtenez une adresse mail Khaganat
« Dernier message par Zatalyz le 05 février 2018 à 11:23:16 »
Il est possible d'avoir une adresse mail en @khaganat.net. C'est une redirection donc le courrier est renvoyé vers une de vos boites mail de base. C'est donc surtout pour le fun, pour communiquer de façon officielle.

Le stock est limité, même si la limite est haute. Il y a quelques conditions pour bénéficier d'une adresse mail de ce genre :
-  Contribuer régulièrement à Khaganat. Ça ne veut pas forcément dire "beaucoup" : chacun fait comme il peut. Comme il est peu probable que nous détruisions des adresses même si vous partez, je préfère réserver les adresses pour les personnes qui sont là au long cours.
- Choisir un alias, deux max... Laissez-en pour les suivantes ;)
- Vous devez vous engager à ne pas ternir l'image de Khaganat via l'utilisation de ce mail. Ça va de soi, mais je tiens à le préciser. Ça reste une adresse qui fait officiel et même si ça ne vous donne pas forcément un rôle d'officiel, vous portez l'image de Khaganat via ce mail.

Vous répondez aux critères ? Contactez-moi (zatalyz@khaganat.net ; yeah !) en m'indiquant quel pseudo vous voulez pour votre adresse pseudo@khaganat.net, et vers quelle adresse mail il doit rediriger.

Une fois que je vous ai donné confirmation de la création de l'adresse, pour pouvoir répondre avec ce mail, il vous faudra déclarer l'adresse auprès de votre gestionnaire de courrier.

Dans thunderbird, c'est facile :
- Ouvrez les paramètres du compte sur lequel les mails sont redirigés.
- Il y a un bouton "gérer les identités" : cliquez dessus.
- Faites "ajouter" puis dans le champ "Adresse électronique", donnez votrepseudo@khaganat.net
- Vous pouvez aussi remplir les autres champs, c'est facultatif.

Lorsque vous écrivez un mail ou en renvoyez un, vous pouvez choisir d'utiliser l'adresse en @khaganat.net plutôt que l'autre :)
5
Général / Re : Transformer les wikis en fichiers type "pdf"
« Dernier message par Zatalyz le 02 février 2018 à 09:53:46 »
Je note ce que je vois à ce stade, qu'il s'agisse de considérations techniques ou d'organisation.

Il faut pouvoir choisir d'inclure ou d'exclure des espaces de nom (c'est à dire des dossiers et ce qu'ils contiennent), de façon récursive ou non. Exemple sur le wikhan : la liste des primitives (plusieurs centaines d'articles, dans un dossier) est intéressante seule et pour une impression, pas forcément inclut avec tout le reste et dans un document à lire page à page à l'écran.

Il faut prendre en compte la syntaxe dokuwiki et les plugins ajoutés. Là-dessus, deux trucs :
- la syntaxe par défaut est bien documentée, donc ça ne devrait pas poser souci,
- les plugins ont leur syntaxe de code toujours incluse soit dans < >, soit dans {{ }}. Et je crois que c'est tout.
Dans ce second cas, il faudrait donc dans un premier temps faire tourner un script sur les pages des wikis, chargé de collecter toutes ces balises. Il n'y en a quand même pas tant que ça. Il y a un risque de récupérer des codes non wiki (les exemples de code), il faut donc détecter de ne pas intérepréter ce qui est entre <code><code>.
Une fois tous les codes syntaxes récupérés, il faudra voir comment les traduire en un autre langage (probablement html).

Il faut aussi décider de quel format en sortie nous voulons.
- L'epub me semble le plus intéressant car c'est assez riche au niveau mise en page et il y a des logiciels pour lire les epub sur ordi, smartphone, bref, ça le fait. Sachant aussi qu'un epub, en fait, c'est du css et des pages html, il est donc possible aussi de proposer ça en mode "site hors ligne" pour celles qui n'aiment pas les epubs.
- Envisager le pdf peut être intéressant si certaines souhaitent imprimer, car ça permet une mise en page bien calibrée. Mais c'est un peu plus hasardeux donc uniquement si y'a vraiment une demande...
- Je ne suis pas très motivée par le .doc, .txt et autres formats de document texte, ça ne me semble pas adapté... mais suivant vos retours, c'est à voir.

Sur la façon donc le script de génération peut tourner, pour moi ce sera un truc que je mettrais sur le serveur, et que je lancerais via une commande. Après, les wikis sont aussi archivés sur git, donc n'importe qui peut les récupérer ainsi que le script et se faire sa propre édition si des admin ne sont pas dispo. On peut aussi envisager une interface web qui permettrais de lancer le script python, accessible uniquement à un groupe donné (genre collège+gens de confiance). Lancer des scripts en boucle est toujours un peu risqué pour un serveur, je préfère limiter ce genre d'accès.

Autre option à envisager (potentiellement dans un second temps) : pouvoir préciser l'ordre de certaines pages, certains dossiers ? genre mettre "géographie" avant "histoire" ? Je ne suis pas sûre que ce soit très utile.

J'ai ajouté aussi le plugin "mardown", qui permet aux gens habitués à écrire en mardown de passer par cette syntaxe. Cela veut dire que le script doit analyser que ce qui est compris entre les balises <mardown></mardown> comme étant du mardown et plus du dokuwiki... Y'en a pas trop pour le moment.
6
Général / Transformer les wikis en fichiers type "pdf"
« Dernier message par Zatalyz le 02 février 2018 à 09:02:25 »
Bonjour à toutes !

La demande traine depuis de longues années, récemment remise à jour par deux de nos membres (voir aussi l'issue git).

Nos wikis sont volumineux et pas forcément très pratiques à consulter en mode transport en commun, c'est à dire sur un écran minuscule et une connexion internet fluctuante. Ou tout autre circonstance où on s'ennuie facilement et où on a le temps de lire Khaganat.

L'idée serait donc de créer des fichiers pages à pages. Je parle de pdf mais ce n'est pas forcément le plus pertinent (pas d'adaptation à l'écran) ; epub me semblerais plus raisonnable, j'ai aussi entendu parler de document texte (ce qui posera souci sur les quelques images, mais on n'est pas obligé de les garder).

La vraie bonne chose à faire serait évidement d'avancer sur le guide du Khanat et de réaliser un bel epub des histoires sur la mediateki, mais c'est un gros travail et vu comme tout le monde est occupé, ça risque de prendre du temps. Or c'est maintenant que certaines souhaitent lire, sans forcément demander le top qualité.

J'aimerais donc mettre en place une solution d'automatisation, qui génèrera divers formats à partir des wikis ; suffira de relancer la génération des documents quand quelqu'un demande et ça répondra au besoin. Je n'attends pas que ce soit parfait, juste qu'on aie quelque chose. À noter que ce sera une bonne base de travail pour un recueil sur la mediateki, mais ce n'est pas ce wiki qui m'inquiète le plus.

Il existe des plugins pour dokuwiki qui font ça, mais ils souffrent de défauts :
- soit il faut sélectionner et organiser les pages une par une... ça peut marcher pour la mediateki (possibilité de faire des recueils thématiques et y'a pas tant d'articles) mais pas sur les autres wikis.
- soit c'est "automatique" en prenant tout un espace de nom sauf que, comme nous avons énormément de pages, ça prend beaucoup de temps... et comme cela se fait via php, on atteint une limite de temps qui fait planter le processus avant la fin. Un hack moche serait que je modifie la durée maximale d'exécution, mais cette durée existe pour une bonne raison et de toute façon, cette façon de faire est une aberration.

Il faut donc que nous fassions un truc dédié à ça, vu que je n'ai rien trouvé de tout fait.

Pourquoi je poste ici plutôt que dans Programmation ?

Avant de se lancer dans du code, il faut savoir exactement les contraintes et ce qu'on souhaite obtenir. Elen est passé l'autre soir et a proposé son aide pour écrire le script de traduction mais je me rends bien compte qu'il me manque des éléments pour donner des directives pertinentes.  C'est pourquoi je lance un appel ici. Que voyez-vous de nécessaire dans un outil de ce genre ? que faut-il prendre en compte ? quel est le résultat à espérer ?
7
Concept de gameplay ou gamedesign / Dialogues pnjs
« Dernier message par Lod le 29 janvier 2018 à 21:28:36 »
Je trouverais intéressant de pouvoir ajouter des sons aux pnjs.
Des phrases standards
"bonjour" quand les pnjs se croisent ou un salut du style avatar "je te vois"
"Achetez mon poisson, il est bon" dans le quartier commercant
Ou des pnjs qui seraient dans un recoin sombre pour fomenter quelque chose
Des cris d'enfants qui se courent après
Des bruits d'oublieux malades dans le dispensaire
Brefs, plus vivant, plus immersif, plus plus plus toujours plus.

reste plus qu'à savoir comment on fait ça ;)
8
Général / Re : la fin du voyage...
« Dernier message par Zatalyz le 29 janvier 2018 à 21:22:37 »
J'ai oublié de répondre ici...

J'espère de toute mes forces qu'une solution va arriver, qu'un de tes rendez-vous va déboucher sur quelque chose qui te feras aller mieux, autant que possible. Quoiqu'il arrive, je pense fort à toi ; je te souhaite le meilleur mais je peux aussi comprendre l'abattement et la lassitude que tu as à vivre tout ça. Pas forcément les bons mots, mais enfin, bon... juste te dire câlins, bisous, tout ça.  :-*

J'ai beaucoup entendu parler d'Unrest, il parait que c'est un bon film à faire voir pour donner un aperçu de ce que les malades vivent. Personnellement je n'ai pas eu la motivation de le voir, je vis ça bien assez au quotidien pour pas me déprimer davantage  ^^ mais vu les échos positifs, n'hésitez pas si vous voulez en savoir plus.

Et une image cute pour une note plus douce :

Trouvé sur http://attackofthecute.com/ , un site parfait quand on est en mode nobrain et qu'on veut pas déprimer  ;)
9
Programmation / Re : Xen et archlinux
« Dernier message par shepeng le 28 janvier 2018 à 17:00:59 »
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.
10
Programmation / Xen et archlinux
« Dernier message par Zatalyz le 27 janvier 2018 à 10:19:50 »
J'aborde un sujet de spécialiste en espérant que vous pourrez m'aider à trouver des éléments de réponses. En gros, je cherche le Fichu Manuel, et surtout les pages du fichu manuel qui parlent de mon fichu problème.

Nos serveurs (Murbaz et Nuxru) tournent avec Xen, un hyperviseur, qui permet de créer des sortes de VM sur lesquels tournent nos services. Actuellement tout est calibré pour Debian : Xen tourne sur une version de debian, et on peut créer facilement des vm debian.

J'aimerais pouvoir démarrer des vm d'autres systèmes d'exploitations, dont Archlinux pour commencer.

Archlinux, parce que je sais gérer ce système au quotidien, parce que ses paquets sont à jour, parce que c'est une rolling release et que j'aime les rolling release... Ce n'est pas forcément la solution la plus évidente pour un serveur, mais ça marche.

Pour créer une vm avec le système qui va bien, Xen utilise des scripts basés dans /etc/xen-tools/ (et après une petite commande et hop ça se fait tout seul). J'ai identifié les fichiers suivants :

distributions.conf
# xen-tools configuration file for distribution meta data
#
# Syntax:
#
# codename = distribution and further keywords
#
# Known distributions: debian, ubuntu
# Known keywords: eol, pygrub, default-keyring, dont-test
#
sarge        = debian eol
etch         = debian eol
lenny        = debian eol
squeeze      = debian eol default-keyring
wheezy       = debian
jessie       = debian
stretch      = debian
buster       = debian dont-test
bullseye     = debian dont-test
sid          = debian

testing      = debian
oldoldstable = debian dont-test
oldstable    = debian
stable       = debian
unstable     = debian

# dapper and edgy currently need manual adjustments in debootstrap's
# configuration, see #659360
dapper       = ubuntu eol dont-test
edgy         = ubuntu eol dont-test
feisty       = ubuntu eol
gutsy        = ubuntu eol
hardy        = ubuntu eol
intrepid     = ubuntu eol
jaunty       = ubuntu eol
karmic       = ubuntu eol
lucid        = ubuntu eol pygrub
maverick     = ubuntu eol pygrub
natty        = ubuntu eol pygrub
oneiric      = ubuntu eol pygrub
precise      = ubuntu     pygrub
quantal      = ubuntu eol pygrub
raring       = ubuntu eol pygrub
saucy        = ubuntu eol pygrub
trusty       = ubuntu     pygrub
utopic       = ubuntu eol pygrub
vivid        = ubuntu eol pygrub
wily         = ubuntu eol pygrub
xenial       = ubuntu     pygrub
yakkety      = ubuntu     pygrub
zesty        = ubuntu     pygrub

devel        = ubuntu     pygrub


mirrors.conf
# xen-tools default mirror configuration file

debian =         http://httpredir.debian.org/debian
debian_archive = http://httpredir.debian.org/debian-archive/debian

ubuntu =         http://archive.ubuntu.com/ubuntu
ubuntu_archive = http://old-releases.ubuntu.com/ubuntu

#
# If you like, you can also declare per-release mirrors:
#
# sarge  = http://debian.ethz.ch/debian-archive/debian
# trusty = http://ubuntu.ethz,ch/ubuntu

Il est aussi possible que certaines options dans xen-tools.conf soient à surveiller afin de lancer la commande de création de vm en indiquant bien tout ce qu'il faut changer pour passer à du archlinux.

Enfin il y a probablement des trucs dans /etc/xen-tools/role.d/, par exemple le contenu de builder :
#!/bin/sh
#
#  Configure the new image to be suitable for compiling Debian packages within
#
# Steve
# --
# https://steve.fi/
#


prefix=$1



#
#  Source our common functions - this will let us install a Debian package.
#
if [ -e /usr/share/xen-tools/common.sh ]; then
    . /usr/share/xen-tools/common.sh
else
    echo "Installation problem"
fi
#
#  Update APT lists.
#
chroot ${prefix} /usr/bin/apt-get update
#
#  Install the packages
#
installDebianPackage ${prefix} dpkg-dev
installDebianPackage ${prefix} devscripts
installDebianPackage ${prefix} fakeroot
installDebianPackage ${prefix} debhelper
installDebianPackage ${prefix} build-essential
installDebianPackage ${prefix} lintian
installDebianPackage ${prefix} linda

Comme on le voit, il n'y a rien d'autre que debian et peut-etre ubuntu... Donc la question est : comment on ajoute la possibilité d'installer d'autres systèmes linux ?

Edit : suffit que je pose mon souci publiquement pour commencer à trouver mes mots-clés... possible qu'une part de ma réponse soit donc ici :
https://wiki.archlinux.org/index.php/Xen#Configuring_a_paravirtualized_.28PV.29_Arch_domU

Me reste à tout comprendre et mettre en application.
Pages: [1] 2 3 ... 10