Ça c’est différent. Ce qui s’appelle « tags » dans MediaWiki, c’est ce qui permet d’étendre ses fonctionnalités. Par exemple c’est ce système qui est utilisé par l’extension qui permet d’ajouter les mots clés meta keywords. (anciennement le tag <keywords content=« mot, clé » /> et désormais sur la nouvelle version le tag <seo metak=« mot, clé » />
Après quelques recherches, j’ai trouvé pourquoi la page que tu as ajouté était absente de la liste.
MediaWiki utilise une file de travaux depuis la version 1.6 et il faut donc exécuter le script maintenance/runJobs.php avec cron pour qu’un certain nombre de tâches soient effectuées à intervalle régulier en arrière plan (comme indiqué ici : https://www.mediawiki.org/wiki/Manual:Job_queue/fr).
Je l’ai configuré et maintenant ta nouvelle page s’affiche bien (par défaut, il est exécuté toutes les 5 minutes donc il y a un delta de 5 minutes entre les modifs et l’actualisation des listes ).
Pour continuer à tester, j’ai ajouté/activé les extensions Echo et Thanks.
Il s’agit toutes les deux d’extensions officielles et stables (déployées actuellement sur Wikipédia et MediaWiki Meta) qui permettent aux utilisateurs de mieux suivre les modifications sur les pages sur lesquelles ils ont effectué des contributions en ajoutant deux petites icônes (cloche et boîte de réception) à la barre utilisateur (en haut à droite).
L’extension Thanks, permet (de la même manière que sur ce forum) de remercier publiquement un utilisateur pour une modification réalisée sur une page
Aperçu du panneau des notifications.
Nouveau lien remercier permettant de remercier publiquement un utilisateur pour une contribution.
NEW: Add option DONATION_USE_THIRDPARTIES in admin of membership module
NEW: Add option STOCK_SHOW_VIRTUAL_STOCK_IN_PRODUCTS_COMBO
NEW: constant KEEP_DISCOUNT_LINES_FROM_ORIGIN
NEW: Hidden option MAIN_CAN_EDIT_SUPPLIER_ON_SUPPLIER_ORDER to edit supplier on draft supplier order
NEW: Add hidden option ADD_UNSPLASH_LOGIN_BACKGROUND for random background
NEW: Add hidden option to be ready for BREXIT
NEW: hidden option to change concat order of description/product label.
NEW: Add hidden option to set a search entry to the top
NEW: add hidden option DISPLAY_DISCOUNTED_SUPPLIER_PRICE
NEW: add hidden option MAIN_DEFAULT_LANGUAGE_FILTER
NEW: add hidden option NO_CONCAT_DESCRIPTION
NEW: Add hidden option ACCOUNTANCY_COMBO_FOR_AUX
NEW: Add Hidden option OVERRIDE_VAT_FOR_EXPENSE_REPORT
NEW: add hidden option MAIN_DOC_UPLOAD_NOT_RENAME_BY_DEFAULT
NEW: Hidden conf to improve pdf desc item visibitity
* Hidden option CHANGE_ORDER_CONCAT_DESCRIPTION were renamed into MAIN_CHANGE_ORDER_CONCAT_DESCRIPTION.
C’est un peu le gros probléme général de ce projet, tout est centralisé cher Eldy…
Il faut qu’il délegue sinon c’est infernal pour lui et on reste bloqués …
Les PR sur Git, les mises à jour sur sourceforge, les infras, l’asso , etc. c’est tout Eldy qui fait
J’ai vu qu’il a quand même délégué les PR sur TakePOS mais c’est tout ^^
J’ai pas mal parlé de la forme du wiki avec mes tests liés à la mise à jour du MediaWiki mais comme @Arre le faisait remarquer, le contenu est aussi très important (il n’y a pas que le contenant qui compte ; même s’il est vrai que ça peut donner envie de s’intéresser davantage au contenu).
J’ai donc une proposition très concrète à faire :
A chaque nouvelle version, je me désole que le fichier ChangeLog soit aussi indigeste.
Un message de commit de grosso-modo 70 caractères pour chaque nouvelle fonction ou correction, c’est très court (d’un côté ça oblige la personne à synthétiser les modifications ou nouveautés apportées mais ça ne permet pas du tout d’être exhaustif).
Par exemple, j’ai effectué des modifications pendant le cycle de dév de la v9.0 qui ont été fusionnées dans le coeur lors de la release de la v9.0 et j’aurais bien aimé pouvoir détailler comme je l’ai fait dans la description de la Pull Request l’ensemble des changements réalisés.
Je trouve que cela serait donc une bonne idée de faire une page de changelog sur le Wiki pour chaque nouvelle version (qu’elle soit mineure ou majeure) qui soit rédigée de façon plus détaillée et que chaque PR Github ne soit fusionnée dans le coeur que si le développeur a rédigé une description plus détaillée de la modification dans cette page Wiki.
La possibilité d’inclure des captures d’écran dans le Wiki est une bonne chose car pour certaines modifications, rien ne vaut une bonne capture d’écran !
Cela permettrait également de mieux valoriser les contributions externes.
Les corrections ou nouvelles fonctionnalités seraient aussi classées par module ce qui permettrait d’un seul coup d’œil de trouver ce qui nous intéresse.
Bonjour,
Oui, ce serait un gros plus.
Le changelog fourni actuellement est clairement indigeste. Il ne permet pas de mettre l’accent sur les nouveautés. On a la même chose pour le changement d’une virgule dans un message ou pour l’ajout d’un nouveau module.
Cependant, conditionner l’acceptation des PR à la rédaction d’une entrée dans le wiki me semble rajouter une contrainte forte là où le goulet est déjà serré.
Reste à inventer la méthode pour y arriver. Les codeurs sont bien placés pour savoir ce qui a été modifié, mais pas forcément pour l’expliquer. Mais ceux qui pourraient rédiger n’ont pas l’info.
hébé, ça tchat sur ce post !
+1 pour la réponse de jtraulle sur l’aspect « fondamental » … mais quel besoin en ressource humaine !
et tout synchroniser en inter-dépendance avec les PR
L’asso dolibarr a décidé de ne pas créer de LVT LTS, donc, de fait, c’est pareil pour le wiki ^^
oups LTS, j’ai rippé du cerveau
(pour ceux qui liraient ça et qui ne savent pas : LTS = Long Time Support … un programme qui est maintenu sans bug longtemps dans le temps, dans une même version … LVT … ben j’en sais rien … surement l’amusement de lire les sujets du bac ^^)
Ah, merci pour la clarification, j’étais parti sur Wikipedia, Urban Dictionnary et tout le toutim et même Google me donnait des trucs sans aucun rapport avec le secteur du logiciel ; mon cerveau était en train de fondre à essayer de faire du sens là dessus
Il y a bien une page wiki créée pour chaque version majeure de Dolibarr qui sort.
Exemple avec la v9: Roadmap and Release 9.0.0 - Dolibarr ERP CRM Wiki
Index de toute les pages/versions ici: En bas de la page Category:RoadMap - Dolibarr ERP CRM Wiki
Ces pages sont ouvertes en rédaction à la communauté.
Mais n’ayant personne pour les alimenter, elles sont pour l’instant renseignées avec une copie du changelog généré. Mais sa vocation est justement d’avoir un contenu plus digeste avec copie écran et tout, exactement comme tu le suggère. Il n’y a pour l’instant personne qui ait encore fait l’effort de renseigner ces pages hélas. Ton aide de rédacteur est donc la bienvenu… Par exemple pour la v10, puisque la page n’a pas encore été créée…
).
What is that ?
