Pour le forum vous avez déjà abordé le possible futur candidat au remplacement ?
Discourse est vraiment pas mal et très abouti mais en Ruby
Flarum est le petit nouveau en PHP, il reprend pas mal des idées de Discourse tout en étant codé en PHP. Actuellement le logiciel est toujours en beta (depuis plusieurs années) mais plutôt stable et en développement actif
Pour l’instant, on est tout simplement sur une évolution vers du kunema 5 lié à un joomla mais le joomla ne serait là que pour gérer le forum et le site serait remplacé par un Web site à base de module Dolibarr mais ce ne sont que des discussions car il faut penser au référencement et le fait de copiez coller un wiki ne sera pas forcément une bonne idée pour la suite non plus.
Il faudrait se renseigner sur les solutions des autres logiciels pour le mix vitrine / forum / wiki. Si quelqu’un a quelques minutes pour regarder.
Je vais essayer un MediaWiki à jour en local en utilisant les fonctions d’import/export de MediaWiki pour voir ce qu’il est possible de garder ou pas et le % de perte. Je vous tiens au courant.
@ksar : Comment gères-tu la reprise des données dans le cas d’une migration vers Sphinx, et le multilinguisme ? Personnellement, je ne suis pas contre mais ce sont des choses à prévoir
Comme indiqué, j’ai passé mon après midi à tester la faisabilité d’une migration de version MediaWiki (le logiciel actuel utilisé par la documentation Dolibarr). Je vous fait donc un petit retour par rapport à cela.
J’ai commencé par récupérer un export de l’ensemble des pages et des images du wiki actuel pour pouvoir tester un import dans la dernière version de MediaWiki. Pour cela, j’ai utilisé le script dumpgenerator.py de l’équipe wikiteam disponible sur Github. Ce script permet de générer un fichier d’export XML d’un Wiki MediaWiki contenant l’ensemble des pages, catégories, métadonnées de fichiers, etc. et de télécharger les images.
J’ai ensuite installé en local avec Docker la dernière version de MediaWiki (1.32.2).
J’ai réimporté l’ensemble des 3400 pages et des 775 images en local à l’aide des scripts de maintenance MediaWiki importDump.php et importImages.php sans soucis.
J’ai installé les extensions actuellement utilisées sur le Wiki (ou leur version mise à jour) :
Pour MultiLanguageManager (l’extension que nous utilisons actuellement pour lier les différentes traductions de pages), j’ai rencontré un petit problème sur la version mise à jour (1.29). Il était en effet impossible d’ajouter un lien de page traduite à une page principale car la fenêtre Javascript permettant de faire cela plantait (lors d’un clic sur « Ajouter la traduction »).
Nouvelle fenêtre permettant de gérer les traductions sur le plugin mis à jour.
En creuseant, j’ai découvert qu’il y avait une erreur dans l’un des fichiers Javascript de l’extension. Il faut remplacer la ligne 317 du fichier resources/ext.mlm.js de
Une fois cela remplacé, j’ai pu re-créer les liens vers les différentes pages traduites sans problème. Vous remarquerez sur la capture précédente que les drapeaux de langues s’affichent désormais en plus gros en haut de la sidebar quand des traductions sont disponibles pour une page (un clic sur un drapeau permet d’accéder à la version traduite de la page).
J’ai également installé d’autres extensions particulièrement utiles comme :
CodeEditor (prérequis à WikiEditor)
WikiEditor : une interface de modification de texte wiki avancée
VisualEditor : l’Éditeur visuel pour MediaWiki
L’ensemble de ces extensions sont développées par la core team de MediaWiki.
L’installation s’est passée sans problème et je n’ai pas rencontré de soucis non plus avec le contenu existant du Wiki. L’installation de l’extension VisualEditor nécessite cependant l’installation du service Parsoid qui nécessite NodeJS (Parsoid permet la conversion entre la syntaxe MediaWiki et le HTML affiché par l’éditeur visuel). Plus d’informations sont dispo ici : https://www.mediawiki.org/wiki/Extension:VisualEditor#Set_up_a_Parsoid_service . Là encore, l’installation s’est faite sans problème particulier et on gagne vraiment en confort d’édition et en efficacité avec l’éditeur visuel (pas de doute là dessus).
Aperçu de l’éditeur visuel « VisualEditor » de MediaWiki
J’ai ensuite regardé un peu ce qui se faisait « officiellement » au niveau de MediaWiki pour la gestion de la traduction des pages.
Il faut savoir en effet qu’actuellement, ce qui a été fait au niveau du Wiki actuel de Dolibarr est différentes pages pour chaque langue et chaque page « traduite » est ensuite rattachée à la page principale (anglaise) à l’aide de l’extension MultiLanguageManager.
En utilisant cette méthode chaque page reste indépendante l’une des autres et les modifications réalisées sur la page source ne sont pas signalées sur les pages traduites. Par exemple, si vous ajoutez un paragraphe sur la page anglaise, vous n’avez aucun moyen de savoir que ce paragraphe n’a pas été répercuté sur la page française traduite.
MediaWiki propose un ensemble d’extensions qui facilitent la traduction des pages et permet de réaliser un suivi de l’avancement des traduction tout en surveillant les éventuels ajout réalisés sur la page source pour les répercuter sur les pages traduites.
L’extension principale permettant de gérer cela : Translate, permet tout d’abord de marquer une page comme traduisible en entourant son code Wiki des tags <translate> </translate> . Automatiquement, dès l’ajout de ces tags, MediaWiki extrait les chaînes traduisibles de la page et permet la traduction dans l’ensemble des langues possibles simplement à l’aide d’un éditeur simplifié, paragraphe par paragraphe.
Sur cette image, vous pouvez voir l’édition d’une page à l’aide de WikiEditor ainsi que les balises <translate> et <!–T:1–>, <!–T:2–>, etc. automatiquement ajoutées par MediaWiki et qui correspondent aux différents blocs de texte traduisibles.
Une fois les balises ajoutées, les utilisateurs ont la possibilité de traduire directement en cliquant sur le lien « Traduire cette page » affiché en haut de page (la mention est affichée dans la langue de l’utilisateur).
Il est possible d’insérer un menu contenant les langues de la page à l’aide du tag <languages /> n’importe où où on le souhaite dans la page.
Le lien permettant de traduire en haut et le menu des langues de la page en dessous.
Une fois qu’on a cliqué sur Traduire cette page
Voilà pour cette petite découverte de la façon préconisée par MediaWiki de faire du Wiki multilingue.
Faire comme cela apporte de nombreux avantages et nouvelles fonctionnalités utiles mais nécessiterait un gros travail de réaménagement du wiki (mais jouable si beaucoup de monde s’y met).
Cette approche semble être la plus pérenne au niveau de l’évolution dans le temps car préconisée par les auteurs de MediaWiki.
Après, il reste toujours possible de continuer avec l’extension que l’on utilise actuellement MultiLanguageManager qui fait le job également même si elle ne va pas aussi loin
Dans tous les cas, la bonne nouvelle c’est qu’il n’y à rien de bloquant qui empêche la migration du Wiki actuel vers la dernière version.
Si on partait bien sur une montée de version MediaWiki (ce qui semble tout de même le mieux niveau préservation de l’existant), je suis dispo pour mettre la main à la pâte et aider si besoin
N’hésitez pas à me dire ce que vous en pensez Et si vous avez des questions qui vous viennent par rapport à ce post, n’hésitez pas je répondrais avec plaisir
quand tu te lances dans quelquechose tu fais pas semblant
Bravo pour le job !
Ça aurait le mérite d’être inscrit à l’ordre du jour de la prochaine réunion de l’asso.
Tu peux ouvrir un port vers ton install de test qu’on voit ce que ça donne ? ou le mettre sur un hébergement ?
Si tu n’as pas possibilité : contacte moi, je le mettrait quelque part.
@Arre : Super, merci pour ton retour ! Je vois pour le hoster pour vous permettre de tester et reviens ici pour poster l’adresse
@ksar : Concernant le forum, j’ai également regardé un peu (mais là, c’est plus compliqué étant donné que sans les données existantes pour tester, c’est plus par rapport à ce que l’on lit sur Internet).
Une migration vers PHPBB semble possible en prenant le chemin Kunena -> Simple Machine Forums (SMF) -> PHPBB
Concernant Flarum, je n’ai rien trouvé de probant et tant qu’il est en beta, ce n’est peut-être pas une si bonne idée (même si j’aime bien la philosophie de ce petit dernier qui au final ressemble tout de même grandement à un Discourse recodé en PHP)
Il reste aussi la possibilité de rester sur Kunena qui finalement réponds à tous les besoins qu’on peut avoir d’un forum (même si c’est vrai que garder un Joomla! juste pour ça est peut-être un peu bête, mais bon, si ça fait le job, pourquoi pas) ?
Concernant la proposition de Sphinx, je voulais ajouter à mes arguments précédents :
tout d’abord étant développeur, je tiens à dire que j’ai déjà utilisé Sphinx et que j’apprécie ce générateur de documentation mais …
je pense que Sphinx sera moins accessible qu’un wiki pour les personnes débutantes ou qui n’ont pas du tout de connaissances techniques
le format d’édition de Sphinx (en restructuredtext) est pratique pour rédiger des choses pas trop compliquées mais devient très « chiant » dès qu’on commence à avoir besoin de tableaux (ce genre de choses …) et on perd l’avantage d’un accès au VisualEditor de MediaWiki qui est pour le coup vraiment super simple à utiliser pour les gens qui n’y connaissent rien. Une nouvelle syntaxe (restructuredtext) à apprendre, c’est toujours un frein à la contribution alors que pratiquement tout le monde sait se servir d’un logiciel WYSIWYG genre LibreOffice/OpenOffice.org ou Word (ce qu’apportera VisualEditor de MediaWiki)
le mode de contribution nécessite de passer par Github pour modifier/ajouter des fichiers .rst (on rapproche donc la contribution à la documentation à de l’édition de code et cela suppose que les personnes souhaitant participer savent (ou prennent le temps de comprendre) comment fonctionne Github.
pas de prévisualisation sans regénération de la documentation : le rendu final n’est visible qu’en ayant regénéré la documentation contrairement à un Wiki où il est très simple de voir immédiatement un aperçu des changements apportés sans avoir besoin de cette étape de regénération.
Voilà pour ces quelques éléments qui permettront je l’espère d’y voir un peu plus clair.
J’essaye d’être constructif autant que possible et je pense qu’on gagnerait vraiment à ce que chacun participant à la communauté Dolibarr exprime son point de vu (quelque soit ses connaissances techniques )
MediaWiki a été configuré pour indiquer aux robots de ne pas indexer ni suivre les liens des pages de cette instance de test de façon à ne pas polluer le SEO du Wiki actuel.
Je n’ai pas mis de restrictions à l’édition, le wiki est configuré en mode « ouvert » pour permettre à tous de tester l’édition et les traductions.
Si vous avez besoin d’un compte admin, vous pouvez me demander (même si normalement tous les droits sont ouverts sans avoir besoin de s’inscrire).
Vu que les données viennent d’un export depuis les données publiques du Wiki actuel, les comptes utilisateurs n’ont par exemple pas été réimportés.
Les liens de langues des pages étant stockés exclusivement en base de donnée, je n’ai pas eu la possibilité de les récupérer lors de l’import (il m’aurait fallu un dump de la base actuelle pour cela mais je n’en avais pas). Pour exemple, j’ai donc manuellement re-renseigné les liens de langue de la page d’accueil uniquement en utilisant le plugin de traduction actuellement utilisé sur l’ancien Wiki (mais mis à jour).
La traduction « façon MediaWiki » a été mise en oeuvre uniquement sur la page d’accueil « Main Page » mais vous pouvez tester avec d’autres pages pour essayer.
L’éditeur visuel VisualEditor ne peut être utilisé pour l’édition des pages que tant que celles-ci n’ont pas été marquées pour la traduction en utilisant le système MediaWiki (c’est une limitation actuelle ; dans ce cas, il faut éditer le Wikicode manuellement).
L’éditeur visuel conserve tout son intérêt pour les pages simples et multilingues sur une même page telles que les pages contenant le dictionnaire des données des tables. Essayez par exemple d’éditer la page Table llx_societe et voyez comme il est simple et agréable de modifier les tableaux sur cette page avec le VisualEditor. Il est également à noter qu’il reste possible de l’utiliser pendant la période de création d’une page avant de la marquer pour traduction sans problème.
La nouvelle extension permettant de gérer les balises meta keywords emploi une nouvelle syntaxe (<seo metak=« documentation, help, information, development, user, guide, tutorial » /> au lieu de <keywords content=« documentation, help, information, development, user, guide, tutorial » />). Il faudra jouer une requête SQL pour remplacer les utilisations actuelles
Quand vous aurez fini de tester, dites le moi afin que je supprime l’instance de mon serveur
Pour l’export PDF, ça demande plus de temps alors j’essaye d’y regarder dès que possible. C’est un sujet en apparence simple mais en réalité pas tant que ça. Wikipédia a finalement abandonné ElectronPdfService et est en train de le remplacer par Proton (un générateur de PDF basé sur Chromium). Tout n’est pas encore tout à fait sec à ce niveau
J’ai installé un service Electron dans un nouveau conteneur Docker et configuré l’extension ElectronPdfService.
L’export PDF est maintenant possible (voir le lien Télécharger en PDF dans la rubrique Imprimer / exporter de la barre latérale)
J’ai essayé d’autres options/extensions pour l’export PDF sur la page indiquée par pm17 mais ElectronPdfService est la seule viable à l’heure actuelle (en attendant la future extension basée sur Proton) .
Merci pour tes essais jtraulle !
Pour moi l’urgnece c’est le wiki, le forum ça peut encore marcher comme cela quelque temps.
Le temps que le module site web de doli soit mûr !
C’est clair que c’est le jour et la nuit entre l’ancien et le nouveau MediaWiki…
Du coup reste plus qu’à convaincre Eldy de nous faire un wiki de test pour que l’on fasse toutes les migrations. @Aspangaro tu peux nous aider sur ce point ?
Bonjour jtraulle,
C’est formidable ce boulot.
Concernant les traductions, j’avoue que j’aurais une préférence rester sur le manager, de crainte qu’il y ait trop de perte lors de la transformation. Mais ça peut se discuter.
Je prendrai plus de temps pour regarder en détail dans quelques jours.
Petites remarques :
- Les keywords apparaissent textuellement en haut des pages.
- les liens entre différentes langues ne réapparaissent pas. J’espère que c’est quelque chose qui pourrait passer avec un export direct de la base.
En effet, je pense que rester sur le manager au début permettra une reprise sans perte. A voir ensuite pour migrer progressivement certaines pages qui bougent beaucoup sur le système de traduction intégré de WikiMedia. Ce qui permettra de bénéficier du suivi des traductions.
Un truc que j’ai constaté et qui me dérange avec le système de traduction intégré de WikiMedia, c’est que le nom des pages, même s’il est traduisible garde quand même le nom de la page d’origine. Par exemple, pour Main Page, on aura Main_Page, Main_Page/fr, Main_Page/es etc. Lors de l’affichage de la page traduite en français, le titre sera bien Accueil, par contre, dans la recherche, si l’on tape Accueil cela ne retournera pas la page traduite. Au contraire, taper Main Page ressortira bien la page et ses versions traduites.
Pour les keywords, la syntaxe n’est plus la même avec la mise à jour du module (malheureusement). Maintenant il faut écrire
<seo metak="motclé1, motclé2" /> au lieu de
<keywords content="motclé1, motclé2" />
J’ai remplacé pour l’exemple mais uniquement sur la page Main_Page (accueil anglais). Je pense que le remplacement pourra se faire en masse sans peine en jouant une requête SQL en base
Pour les liens de langue, comme tu dis, je pense qu’il n’y aura pas de problème avec la base d’origine car il s’agit du même plugin qu’actuellement