wiki.dolibarr.org

Slt aspangaro

Faut un peu plus de quelques minutes pour choisir :wink:
Bon perso je propose phpbb pour le forum…
Testé en local avec quelques extensions …

Kunena n est pas un bon choix a mon avis car c est une extension de joomla…
On est donc limité par joomla …

Pour le wiki…je garderais mediawiki…a defaut de mieux…
Par curiosité c est quel module de traduction qui pose pb ?

C marrant de voir une equipe de devellopeurs bloques par un module pas a jour :laugh:

@ksar …tu peux essayer en local en te mettant ds la meme config …

Pour le MOOC si on peut avoir des infos sur l avancée …

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.

Bonjour,

Pour moi ce que je ferais c’est :
1- le site grace au module web de doli
2 - le forum en phpBB
3- les doc sous sphink comme proposé par delcroip

@aspangaro : Penser qu’un CMS puisse faire tout ça bien c’est impossible.
Et je ne vois pas le probléme pour le référencement.

Bonjour/bonsoir à tous,

@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 :wink:

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) :

  • AddHTMLMetaAndTitle 0.7 (remplace MetaKeywordsTag 0.1)
  • MultiLanguageManager 1.29
  • ParserFunctions 1.6
  • SyntaxHighlight 2.0

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

'lang': this.translationLang.getMenu().getSelectedItem().getData(),

en

'lang': this.translationLang.getMenu().findSelectedItem().getData(),

Donc remplacer l’appel à la méthode getSelectedItem() en findSelectedItem() comme indiqué dans la doc de l’API ici : https://doc.wikimedia.org/oojs-ui/master/js/#!/api/OO.ui.MenuSelectWidget

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 :wink:

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 :happy:

N’hésitez pas à me dire ce que vous en pensez :sunglasses: Et si vous avez des questions qui vous viennent par rapport à ce post, n’hésitez pas je répondrais avec plaisir :tongue:

8 « J'aime »

Hébé jtraulle,

quand tu te lances dans quelquechose tu fais pas semblant :laugh:
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.

1 « J'aime »

@Arre : Super, merci pour ton retour ! Je vois pour le hoster pour vous permettre de tester et reviens ici pour poster l’adresse :wink:

@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

En partant pour Discourse, il faut savoir qu’il y a un script et une procédure de migration depuis Kunena fourni directement avec le logiciel.

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) :tongue:

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 :wink: )

Slt

En passant si quelq un pouvait heberger une version de test de phpBB…

Tu as une demo ici pm17 : yourdomain.com - Index page
Nom d’utilisateur et mot de passe : administrator

Cool merci
mais on ne peut pas installer d extensions/remise a zero toutes les heures
pas super pour faire une demo a la core team :wink:

@Arre (et aux autres curieux) : Re-bonjour,

Vous pouvez tester ici : https://test-dolibarr-mediawiki-1-32.traulle.net

Dans les choses à noter :

  • [li]Les versions exactes des extensions utilisées sont dispo ici.
  • 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 :wink:
  • Quand vous aurez fini de tester, dites le moi afin que je supprime l’instance de mon serveur :happy:

Si vous avez des questions, hésitez pas :tongue:

2 « J'aime »

Slt jtraulle

Possible de rajouter une extension pour les export en pdf des pages ?
https://www.mediawiki.org/wiki/PDF_export

Possible de rajouter une extension pour faire une galerie avec les images ?

Possible de rajouter une extension pour les videos/youtube ?

Merci a toi …

  • Concernant les galeries, c’est déjà possible de façon native sans extension (en mode VisualEditor ou directement en éditant le WikiCode).
  • Pour les vidéos, j’ai mis Extension:EmbedVideo - MediaWiki

À voir en action ici https://test-dolibarr-mediawiki-1-32.traulle.net/index.php/User:Jtraulle

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) :happy:

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) :sunglasses: .

Salut,

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 ?

1 « J'aime »

Bonsoir,

Merci à @jtraulle pour le taf’ concernant le wiki, je transmets ça lors de la réunion de mardi.

Bonne soirée :wink:

2 « J'aime »

Bonjour :happy:
@jtraulle +1 merci bcp pour ton travail
merci aux autres aussi :wink:

1 « J'aime »

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.

1 « J'aime »

Merci :tongue:

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.

Voir par exemple :

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 :wink:

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 :happy:

Merci pour tes observations @yves57 !

D’ailleurs, est-ce que ça serait possible d’avoir un dump de la BDD du mediawiki actuel afin de continuer les tests et de voir en testant le processus de mise à jour réel de MediaWiki (sans export/import) ?

Cela permettrait de continuer à avancer en parallèle sur ce sujet vu que j’ai cru comprendre que le projet Mooc Dolibarr était prioritaire pour l’association actuellement. Il serait ainsi possible de lever les derniers points d’interrogation (par exemple sur la récupération des liens des pages de traduction et la requête de mise à jour pour les keywords) et je documenterai l’ensemble de la mise en place pour que ça soit facilement reproductible par l’équipe en charge de l’infrastructure du Wiki Dolibarr :wink:

Salut,

Merci Aspangaro d’avoir bien retransmit l’info !

On verra ce que va faire Eldy !

Source : Report board meeting 20190611 teleconf - Dolibarr ERP CRM Wiki

2 « J'aime »