Wikipédia : bouter les interwikis hors du code des articles

Sur Wikipédia¹, les liens inter-langues (souvent appelés « interwikis ») sont des petits bouts de syntaxe inséré dans un article pour indiquer qu’il existe un équivalent de l’article dans une autre langue. Ces liens apparaissent généralement² en bas du menu de gauche de l’interface.

Pour soulager l’énorme travail que cela représenterais pour des humains, des comptes utilisant des scripts automatisés (appelés robots, ou bots) sont utilisé pour en faire la majeur partie. Vous trouverez plus de détails sur le sujet dans cet autre billet.

Seulement voila, les modifications d’articles par bots interwikis sont nombreuses. Très nombreuses. Je trouve qu’éditer l’ensemble d’un article pour les ajout est un beau gâchis de ressources et que MediaWiki devrait être modifié pour traiter cela plus efficacement (les raisons seront détaillées plus bas) ; mais commençons par voir l’étendue de la chose.

Mesures et calculs

Je me base sur deux échantillons de contributions dans l’espace de nom réservé aux articles, pris sur « spécial:modifications_récentes », avec comme paramètres « 5000 dernières éditions »³ et « Espace de nom (principal) ».

— Échantillon n°1

• Remonte jusqu’à (du) : vendredi 18 juillet 2009 à 22h40
• Pris le (au) : samedi 19 juillet 2009 à 2h20
• Nombre d’éditions par bots interwiki : 374 / 5000
• Durée de l’échantillon : 4h40
• Ratio des éditions interwikis / total éditions dans (article) : 7,48%

— Échantillon n°2

• Remonte jusqu’à (du) : samedi 19 juillet 2009 à 2h37
• Pris le (au) : samedi 19 juillet 2009 à 11h28
• Nombre d’éditions par bots interwiki : 528 / 5000
• Durée de l’échantillon :  8h50
• Ratio des éditions interwikis / total éditions dans (article) : 10,56%

— Généralisation

En estimant (un peu abusivement) que la moyenne de ces 2 échantillons est représentatif de la réalité, cela nous donne :

• (374+528=) 902 éditions interwikis pour (4h40+8h50=) 13h30
• 902/10000 = ~9% du total d’édition des articles sont faites par les bots interwiki
• par extrapolation, ~1600 éditions par bots interwiki par jour dans l’espace (article).

Mais en fait, pourquoi c’est mal ?

A chaque fois qu’un article est modifié, une nouvelle version est générée, ce qui comprend notamment (non exhaustif) :

• Mise à jour de la table des liens internes (pour spécial:whatlinkshere et pas mal d’autres)
• Mise à jour de la table des liens externes (pour special:linksearch)
• Mise à jour des tables liées aux catégories
• Mise à jour de la table des liens inter-langues
• Enregistrement d’une nouvelle version de l’article dans la base et enregistrement de la précédente dans la table archive.
• Re-génération du cache de la page
• etc.

Et lorsqu’ils les lisent ils sont obligés de récupérer toute la page (souvent plusieurs dizaines de kilo-octets) car il doivent ensuite pouvoir les insérer dans le code de l’article (sinon, il suffirais de demander à l’API)

Alors que la modification d’interwikis ne nécessite, en théorie, que le point 4, c’est à dire la mise à jour de la table des liens inter-langues.

Comment améliorer ?

La solution que je vois, et qui est partagée par pas mal de personnes depuis plusieurs années, consiste à mettre les interwikis dans un champ d’édition à part (et pour les scripts, une requête API dédiée en écriture).

La modification d’interwikis ne nécessiteraient donc plus que :

• Lecture des interwikis par le robot sur l’API (1.12 ko pour l’article manga, au lieu d’un code source de 63ko)
• Le robot enregistre les modifications là encore par l’API, ce qui se détaille coté serveur en :
  • enregistrer l’ancien état des interwikis dans un système d’historique (1 ou 2ko max)
  • enregistrer le nouvel état (là encore, 1 ou 2ko)

Les utilisateurs humains restant bien sur libres de les éditer via un petit formulaire prévu à cet effet, distinct du formulaire d’édition de l’article.

Avantages

• Puissance/temps de traitement réduit :
  • il faut juste traiter les interwikis et plus l’ensemble du code de l’article lorsque l’on souhaite en modifier.
  • A l’inverse, le parseur n’aura plus à traiter la partie interwiki lors de la sauvegarde normale d’un article.
• volume de stockage réduit : on sauvegarde juste l’ancien état des interwikis au lieu de sauvegarder toute la page
• Inconvénience réduite pour les contributeurs :
  • plus de pourrissement des listes de suivi et des RC
  • une modification par bot interwikis ne risque plus de masquer un vandalisme survenu peu avant.
  • Simplification de la syntaxe pour les nouveaux (merci kimdime :) qui ne risquent du coup plus de supprimer les codes interwikis par erreur

Inconvénients

• Cette modification nécessite une altération du parseur, le cœur du traitement de syntaxe de MediaWiki. C’est une opération lourde qui risque d’introduire des bugs.
• Les scripts automatisant la gestion des interwikis devront être entièrement revus.

Conclusion

Au final, le problème majeur est de passer d’un système « passable mais éprouvé et dont on est certain qu’il marche » à un système « bien mieux, mais qui nécessite des changements lourds avec risques de bugs ».

De mon point de vue, même si je comprend la frilosité des développeurs, le changement en vaut vraiment le coup.

NB : reprenez le même texte mais pour le système de catégories, ça marche aussi :)

---

1. en réalité, sur tous les wikis à base du logiciel MediaWiki, pour peu qu’ils aient été configuré pour.
2. le skin monobook, celui par défaut du logiciel, les fait apparaitre à cet emplacement. Mais ça n’est pas le cas de certains autres.
3. Les utilisateurs normaux ne peuvent voir que jusqu’a 500 lignes maximum. Les bots et administrateurs ont une limite plus large qui leur permet de voir jusqu’au 5000 lignes sur l’ensemble des pages spéciales.