Je suis conscient que ici tout le monde est bénévole et travaille pour Dolibarr sur son temps libre.
Mais bon il est vrai que certains trucs datent un peu quand même
La prochaine réunion de l’assoc. a lieu mardi qui vient.
Pour le Joomla + Forum, il faut être patient car lors du devcamp a été abordé le fait de refaire la page Dolibarr avec le générateur website de Dolibarr et de le lier à un forum à jour.
Par contre, pour le wiki, je vais re-proposer de le mettre à jour, ça pourrait être fait rapidement je pense mais je confirmerai ça. Le MOOC prévu ne remplacera pas le wiki donc vous pouvez poster dessus sans problème.
Aprés une conversation avec Eldy lors d’une réunion du bureau de l’association, il y a quelque temps déja, le problème avec le wiki c’est le module de traduction qui a été utilisé depuis le début n’est pas compatible avec les nouvelle version de Mediawiki. Cela bloque toute monté de version du wiki.
Coté site dolibarr.fr et dolibarr.org et dolistore on envisage (juste on en discute, hein, rien de définitif) de tous migrer sur le CMS intégré à Dolibarr dans la version 10. Mais il y aura forcement encore un temps avant que cela soit mis en place.
Pour le moment l’association investie du temps dans le projet Mooc Dolibarr. Les taches citées ci dessus seront abritées après ce projet.
S’il y a du boulot manuel de copier/coller à faire pour migrer le Wiki en conservant les traductions, je suis prêt à passer du temps et à aider à cela. Franchement, si on arrive à mobiliser assez de monde, c’est carrément faisable non ? On est une communauté oui ou non
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) .