Je propose d'appeler le plugin “tabpage”, ça existe pas chez Dokuwiki.

Historique : sur l'encyclopédie de Khaganat (l'UM1), nous avons identifié le besoin de séparer les niveaux d'informations : ce qui est de l'encyclopédie connue des habitants de l'univers, les informations destinées au gameplay, celles concernant des “secrets” (spoil), etc. Pour permettre à ces divers niveaux de cohabiter sans gâcher le plaisir, nous avons décidé d'utiliser des onglets pour chacune de ces thématiques. Malheureusement, le choix technique à l'époque a été un bidouillage crasseux. Il serait nécessaire de reprendre tout ça pour faire quelque chose de propre et de plus versatile.

Actuellement, le système d'onglet est inclus dans le thème. C'est une erreur de conception. Le système d'onglet doit être un plugin, paramétrable suivant les wikis.

Le but est de faire un plugin.

Le css lié doit être minimal ; reprendre autant que possible la classe dokuwiki de pageId, voir aussi pour inspiration ce qu'il y a sur le thème actuel de l'um1. Mais le css, je peux gérer, donc pas se prendre la tête avec ça.

Côté administration, il faut pouvoir déclarer quel type d'onglet on veut. Quelque chose de très simple, du type : “Indiquez le nom des onglets dans l'ordre d'apparition, séparés par une virgule”. Sur l'UM1, la déclaration serait donc animation,gameplay,dev,talk.

Chaque onglet doit amener à une page dont l'adresse répond à un schéma similaire. C'est là que ça va très vite se complexifier, car il faut prendre en compte les divers cas d'usage de Dokuwiki afin que ce plugin puisse servir dans divers cas… Car quitte à coder, autant que ça ne soit pas que pour l'UM1 (d'autant qu'on a besoin de ça, en version simplifiée, sur les autres wiki, avec juste l'onglet “talk”).

Un lien dans l'UM1 ressemble ensuite en gros à ceci (ce qu'on a après la partie 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

Ça, c'est pour éviter de tout casser s'il n'y a pas ce plugin activé (le but étant de faire un plugin utilisable dans divers wiki). Le plugin translate a besoin que le premier namespace soit celui de la langue pour bien fonctionner.

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 retrouve les langues configurées pour le wiki :

$tab_lang = explode(" ", $conf["plugin"]["translation"]["translations"]) ;

Ces deux trucs doivent pouvoir s'exploiter pour décider si oui ou non, les espaces de langues sont à repérer dans la détection des liens.

Dans la logique de Dokuwiki, il est toujours plus intuitif de créer une page de base sans namespace. Donc, la page “de base” n'est pas dans un espace de nom d'onglet.

Autrement dit, la page “de base” sera du type :$id, associé automatiquement aux pages du type $tab:$id. En exemple avec une page sur le pendo, avec le plugin translate activé, les liens seront de la forme suivante :

• fr:pendo
• fr:animation:pendo
• fr:gameplay:pendo
• fr:dev:pendo
• fr:talk:pendo

Et évidement on aura pas la page fr:gameplay:talk:pendo (pas de génération à l'infini des liens, si le terme d'un des onglets est détecté après fr (ou sans fr dans le cas d'un dokuwiki sans translate), alors ça suffit en terme d'onglet).

Côté organisation des dossiers, cela donne :

├──fr
|   ├── pendo (et autres pages "de base")
|   ├── animation 
|   |    └─ pendo
|   ├── gameplay
|   |    └─ pendo
|   ├── dev
|   |    └─ pendo
|   └── talk
|        └─ pendo
├──en
|   ├── pendo (et autres pages "de base" in english)
|   ├── animation 
|   |    └─ pendo
|   ├── gameplay
|   |    └─ pendo
|   ├── dev
|   |    └─ pendo
|   └── talk
|        └─ pendo

Le cas ne se pose pas trop sur l'UM1, un peu plus sur les autres wikis, donc il me semble important de le prendre en compte. Sur les autres wikis, le seul onglet activé est celui de discussion (“talk”). Mais il est intéressant de l'avoir même sur une page comme https://khaganat.net/wikhan/fr:gamedesign:khanat:ecosystem. Si on schématise, cette page est donc du type $lang:<ns>:<ns>:$id tandis que sa page discussion devrait être $lang:$tab:<ns>:<ns>:$id. Il faut donc arriver à garder la structure des namespace lors de la création du lien vers page-onglet “discussion”.

Les demandes qui suivent sont optionnelles, ça serait “bien”, mais même sans, ça sera déjà bien.

• Traduction des onglets : pouvoir indiquer la traduction à associer à ces termes suivant le paramétrage de langue mais cette partie est secondaire (ergonomie à interroger, probablement ajouter une config d'extension sur la partie ?do=admin).
• N'afficher les onglets que dans des espaces de noms précis. Par exemple dans l'UM1, activer les onglets pour toutes les pages du type $lang:$id mais pas pour $lang:<ns>:$id ; cela évite d'avoir des onglets sur la partie “user” (qui sert aux pages persos) ou “wiki” (où on trouve la doc concernant l'utilisation du wiki). Cela demande aussi des options configurables dans la partie administration. D'autant qu'on pourrait vouloir certains types d'onglets dans certains namespaces, et pas sur d'autres, par exemple du “talk” partout, mais pas du “animation”…

• Plugins ayant un fonctionnement proche (mais pas complètement) : https://www.dokuwiki.org/plugin:talkpage (nécessite l'ajout d'une syntaxe dans la sidebar, et pas plusieurs onglets possibles)
• Débroussaillage conceptuel de Daeldir (code php à affiner) : https://git.khaganat.net/khaganat/website_jukni/uploads/128d1117af51d0512ffe6708676484b4/tabs.php
• Bidouilles de zat pas complètement fonctionnelles : https://git.khaganat.net/zatalyz/khum1-doku/-/blob/master/tabs.php

• Zatalyz sait à quoi il faut arriver (pas toujours simple à décrire) et peut gérer la partie css.
• vv222 a dit qu'il connaissait le php… le fou ! :P

• Connaître le fonctionnement de Dokuwiki
• Savoir lire la doc de Dokuwiki sur comment faire un plugin propre
• Savoir coder en php

Potentiellement quelques jours de travail, plus ou moins suivant la possibilité de réutiliser le code précédent et les compétences de qui fera le job. Cela devrait être “facile” pour quelqu'un connaissant php.

Des difficultés peuvent surgir pour prendre en compte des comportements émergeants (quand on va se rendre compte qu'il faudrait que ça fasse “ça” plutôt que “ceci”…).

• Réaliser le plugin débloquera la tâche Reprendre le CSS des wikis