Utilisateur:Schiste/wikipeople

wikipeople est un outil qui affiche, sous le titre d’un article de Wikipédia, une phrase nommant les principales personnes ayant rédigé le texte actuellement visible :

Article rédigé par Alice, Bob, Charlie et 44 autres personnes.

Les trois noms pointent vers les pages utilisateur. Le décompte restant pointe vers l’historique complet de l’article.

L’objectif est éditorial avant d’être technique : un lectorat qui voit des noms de personnes comprend que Wikipédia est écrite et relue par des gens. C’est aussi, en 2026, ce qui permet de la distinguer d’un contenu intégralement généré par une IA.

L’outil se compose de deux moitiés :

un gadget (script personnel MediaWiki, wikipeople.js / wikipeople.css) qui affiche la phrase sous les articles et enrichit la page d’historique ;
un service Toolforge (API + travailleurs asynchrones) qui calcule et conserve l’attribution.

Un seul fichier, non modifié, fonctionne sur toutes les Wikipédias couvertes par WikiWho. Le gadget reconnaît le wiki sur lequel il s’exécute et interroge le service en conséquence ; la phrase s’affiche dans la langue d’interface du lectorat, et la formulation comme les liens d’aide se règlent depuis une page de configuration facultative, sur le wiki.

Comment les trois noms sont sélectionnés

Cette section rassemble tout ce qui détermine les noms affichés : la mesure, le classement, les exclusions, les seuils, et ce que la phrase ne dit pas.

La métrique

Elle s’appelle wikiwho-surviving-alphanumeric-tokens et mesure qui a introduit le texte wikicode encore présent aujourd’hui dans l’article.

Un jeton est une unité de texte du wikicode source. WikiWho reconstitue, pour chaque jeton de la version affichée, la personne qui l’a introduit — même si d’autres l’ont depuis déplacé, reformaté ou entouré d’autre texte. Ce qui compte est donc la survie du texte, pas le nombre de modifications ni leur récence.

Le classement, étape par étape

Ne compter que le texte utile. Seuls sont décomptés les jetons contenant au moins une lettre ou un chiffre Unicode. La ponctuation, les espaces et la syntaxe pure sont ignorés : ajouter dix mille accolades ne fait donc monter personne dans le classement.
Classer les personnes à l’origine du texte par nombre de jetons survivants dans la version courante.
Résoudre les identités. Les 50 premiers candidats, identifiés par WikiWho sous forme d’identifiants numériques, sont convertis en noms d’utilisateur actuels et en groupes via l’API Action de Wikipédia. Un compte renommé apparaît donc sous son nom d’aujourd’hui.
Appliquer les exclusions décrites ci-dessous.
Appliquer les seuils : au moins 20 jetons et au moins 1 % des jetons décomptés de l’article. Les deux conditions sont cumulatives.
Retenir au plus trois noms.

Qui ne peut jamais être mis en avant

Sont exclus des noms affichés, quelle que soit leur part du texte :

les robots — les comptes détenant actuellement le droit bot ;
les comptes temporaires (nom commençant par ~) ;
les adresses IP et les acteurs anonymes ;
les comptes supprimés ou introuvables.

Ce choix est délibéré et documenté dans ADR-0001. Mettre en avant une adresse IP ou un compte temporaire reviendrait à exposer publiquement une personne qui n’a pas choisi de nom public.

Le décompte « et N autres personnes »

Le nombre qui suit les trois noms ne relève pas de la même mesure, et c’est volontaire.

	Les trois noms	Le décompte
Mesure	jetons encore présents dans la version courante	toute modification jamais enregistrée dans l’historique
Source	WikiWho	API REST d’historique de MediaWiki
IP et comptes temporaires	exclus	inclus
Robots	exclus	déduits du total

Autrement dit : les noms répondent à « qui a écrit le texte que je lis ? », le décompte à « combien de personnes sont passées par cet article ? ». Les IP et comptes temporaires restent dans le décompte faute de sous-total fiable côté MediaWiki, mais ne sont jamais nommés. Le lien mène à l’historique complet, et la phrase ne prétend jamais compter des personnes physiques vérifiées.

Lorsque l’API d’historique plafonne son propre décompte sur un article très ancien, le gadget écrit « au moins N personnes » plutôt qu’un chiffre faussement exact.

Ce que la mesure ne dit pas

Elle reconnaît les personnes à l’origine du texte actuellement visible. Elle ne mesure pas :

la recherche documentaire, le sourçage ou la vérification ;
la relecture, la maintenance, la lutte anti-vandalisme, l’arbitrage ;
le travail sur les médias, les modèles, les catégories ou Wikidata ;
les contributions ultérieurement révoquées ou réécrites ;
la qualité d’une modification.

Elle porte sur le wikicode source survivant : ni le rendu HTML, ni les médias, ni les modèles développés, ni les éléments Wikidata liés.

C’est une mesure de provenance du texte survivant, pas un classement de mérite. La page de méthodologie est liée depuis chaque réponse de l’API (methodology_url).

Quand aucun nom n’apparaît

Situation	Comportement
Article court, ou dont aucun compte n’atteint 20 jetons et 1 %	aucun nom mis en avant ; la phrase se replie sur le seul décompte lié à l’historique
Article écrit majoritairement par des robots, des IP ou des comptes temporaires	ces comptes sont exclus des noms ; ils restent dans le décompte agrégé
Article dont un seul compte dépasse les seuils	un seul nom est affiché ; il n’y a pas de remplissage jusqu’à trois

Crédits

L’idée originale vient d’Amir Aharoni, de son épouse et de leur fille. wikipeople n’est qu’une mise en œuvre de cette idée familiale.

Le code est publié sous AGPL-3.0-only. Les données de WikiWho sont publiées séparément sous CC BY-SA 4.0, et les contenus Wikimédia restent soumis à leurs propres licences.

Comment les données sont récupérées et stockées

Cette section est la plus importante pour les personnes qui s’inquiètent de la charge imposée aux services Wikimédia et à WikiWho.

Règle fondatrice : wikipeople est un cache

Le processus web n’appelle jamais WikiWho, l’API MediaWiki ou l’API Analytics. Il ne fait que lire et écrire dans sa propre base de données (ToolsDB). Toute la récupération de données a lieu dans des travailleurs et des tâches planifiées, hors du chemin de requête : le rôle de wikipeople sur Toolforge est de faire tampon devant les autres services.

Conséquence directe : un pic de lecture sur Wikipédia ne peut pas se transformer en pic de requêtes vers WikiWho. Au pire, il crée des lignes de file d’attente et fait tomber wikipeople — pas WikiWho.

Le chemin de lecture (gadget → API)

Le gadget lit wgDBname, wgArticleId et wgCurRevisionId depuis mw.config, et récupère sa page de configuration sur le wiki local (page absente = valeurs par défaut).
Il appelle GET /v2/{wiki}/pages/{page_id}?revision_id={revision_id}, où {wiki} est le nom de base de données local. Un wiki que le service ne couvre pas répond 404 et le gadget n’affiche rien — c’est ce qui permet d’installer le même fichier partout.
L’API sélectionne le résultat le plus récent pour ce couple page + version d’algorithme.
- résultat de moins de 90 jours → 200 ready, is_fresh: true ;
- résultat plus ancien → 200 ready, is_fresh: false, et un rafraîchissement prioritaire est mis en file d’attente. L’ancienne phrase reste affichée : le gadget ne se vide jamais pendant un recalcul ;
- aucun résultat → 202 pending et création d’une seule ligne de file d’attente durable.
Le gadget réessaie brièvement (3 s, puis 10 s) pendant la visite en cours, puis abandonne silencieusement. Il n’interroge jamais l’API en boucle.

Le gadget garde aussi la réponse en sessionStorage pendant 24 heures, avec un délai d’expiration réseau de 8 secondes. En cas d’échec, il n’affiche rien du tout — jamais de message d’erreur au lectorat.

Le chemin de calcul (travailleur → sources externes)

Lorsqu’un travailleur réserve une tâche, il exécute la séquence suivante :

API Action de Wikipédia (action=query&pageids=…&prop=revisions) : vérifie que la page existe, qu’elle est dans l’espace principal et que la version demandée est toujours la version courante. Si la page a été modifiée entre-temps, la tâche est marquée superseded et une nouvelle tâche est créée pour la version courante.
API WikiWho (/{langue}/api/v1.0.0-beta/rev_content/rev_id/{revision_id}/) : renvoie les jetons (tokens) de la version, chacun accompagné de son éditeur d’origine. La requête demande explicitement le minimum utile (editor=true, mais o_rev_id, token_id, in et out désactivés), avec un délai de 90 secondes et un plafond de réponse de 32 Mio.
Agrégation locale : classement des éditeurs d’origine par nombre de jetons survivants.
API Action, résolution des comptes (list=users&ususerids=…&usprop=groups, par lots de 50) : convertit les identifiants numériques WikiWho des 50 meilleurs candidats en noms d’utilisateur actuels et en groupes.
Filtrage éditorial : exclusions et seuils, détaillés dans Comment les trois noms sont sélectionnés.
API REST d’historique (/w/rest.php/v1/page/{titre}/history/counts/editors) : donne le nombre total de personnes distinctes ayant modifié l’article.
API Action, comptage des robots (prop=contributors&pcrights=bot) : donne le nombre de comptes détenant actuellement le droit bot parmi les contributeurs, qui est soustrait du total.
Écriture du résultat compact en base, puis suppression de la ligne de file d’attente.
Enregistrement du wiki, s’il s’agit de son premier résultat stocké. Dès lors, les articles populaires de ce wiki sont rafraîchis chaque jour comme ceux des autres. L’inscription est déclenchée par un calcul abouti et non par une requête entrante : personne ne peut donc inscrire soixante-dix wikis au travail planifié en chargeant simplement soixante-dix pages.

Ce qui est effectivement stocké

Une ligne de résultat contient uniquement un agrégat compact — environ un kilooctet :

Champ	Contenu
`wiki`, `page_id`, `revision_id`, `algorithm_version`	identité immuable de la ligne
`title`	titre au moment du calcul, à titre indicatif seulement
`metric`	nom de la métrique appliquée
`contributors`	JSON : au plus trois entrées (`user_id`, `username`, `token_count`, `share`)
`distinct_contributors`	nombre de personnes distinctes, robots actuels déduits
`count_limited`	vrai si l’API d’historique a plafonné son décompte
`countable_tokens`	nombre total de jetons décomptés dans la version
`wikiwho_revision_id`, `computed_at`	provenance exacte et date du calcul

Ce qui n’est jamais stocké : les réponses brutes de WikiWho, le contenu des jetons, le wikicode de l’article, la moindre donnée de lectorat. Les réponses de l’API ne contiennent aucun identifiant de lecteur et sont donc sûres à mettre en cache publiquement.

Identité, fraîcheur et mises à jour

L’identité de stockage est immuable :

wiki + page_id + revision_id + algorithm_version

Le titre n’est jamais une identité : une page peut être renommée, alors que les identifiants de page et de version sont stables. C’est aussi pourquoi l’API refuse délibérément d’accepter un titre en entrée.

Trois horloges distinctes cohabitent :

Horloge	Durée par défaut	Variable	Rôle
Fraîcheur du calcul en base	90 jours	`PAGE_FRESHNESS_SECONDS`	durée pendant laquelle un calcul reste réutilisable malgré les modifications ordinaires
Cache navigateur	1 jour	`PAGE_CACHE_SECONDS`	`max-age` de la réponse `/v2`
Réutilisation dégradée	7 jours	`PAGE_STALE_WHILE_REVALIDATE_SECONDS`	tolérance navigateur en cas de panne passagère

Une modification ordinaire n’invalide pas un résultat frais : le produit accepte une attribution calculée dans les trois derniers mois. Une page populaire ou très modifiée ne demande donc, en régime normal, qu’environ quatre calculs WikiWho par an.

Toute évolution des règles susceptible de changer le résultat impose une nouvelle ALGORITHM_VERSION et une décision documentée. Les anciens résultats ne peuvent ainsi jamais être confondus avec une nouvelle interprétation de la notion de contribution.

File d’attente, priorités et robustesse

Priorité	Origine	Objectif
100	Défaut de cache d’un lecteur réel	servir d’abord la demande démontrée
50	Union des sept derniers classements quotidiens top 1000, pour chaque wiki actif	garder au chaud les pages probables
10	Remplissage alphabétique reprenable, sur les seuls wikis explicitement inscrits	couvrir la longue traîne sans affamer la demande

Une contrainte d’unicité en base fait s’effondrer un afflux simultané sur la même page et la même version en une seule tâche.
Chaque tâche est réservée par un bail de 300 secondes : si un travailleur tombe, la tâche redevient disponible.
Les échecs transitoires sont réessayés avec un recul exponentiel (30 s, 60 s, 120 s…) plafonné à six heures, sur huit tentatives au maximum.
Une tâche épuisée devient dead et peut ressusciter après 24 heures ; une erreur de données permanente reste définitive pour cette version d’algorithme.
Une tâche portant sur une version dépassée est marquée superseded.
Une tâche hebdomadaire de nettoyage supprime les vieilles lignes mortes ou dépassées et les anciennes versions de résultats, en conservant toujours le résultat le plus récent de chaque page.
Deux répliques de travailleur constituent le point de départ prudent. Toute augmentation de la concurrence doit être négociée avec les personnes qui exploitent WikiWho.

Les données Analytics pouvant être publiées avec plusieurs jours de retard, la tâche de préchauffage remonte le temps, ignore les jours renvoyant 404 et s’arrête après avoir trouvé sept classements disponibles. Elle répète ce balayage pour chaque wiki actif, et un wiki indisponible est ignoré plutôt que d’interrompre toute la série. Préchauffage et remplissage ignorent systématiquement toute page dont le résultat a moins de 90 jours.

Servir un wiki et le parcourir intégralement restent délibérément deux choses distinctes. Servir peut être universel parce que c’est auto-limité : rien n’est calculé tant que personne ne lit l’article. Le remplissage article par article, lui, ne l’est pas — la seule Wikipédia en anglais compte des millions d’articles — et n’est donc jamais activé automatiquement pour un wiki nouvellement découvert.

Vie privée

Aucun identifiant de lecteur n’est stocké ni renvoyé.
Le service reçoit néanmoins une adresse IP et un identifiant d’article lors d’un défaut de cache : les journaux d’accès doivent avoir une rétention courte et ne jamais servir à reconstituer des historiques de lecture.
CORS limite l’usage navigateur aux domaines de Wikipédia ; CORS n’est pas une authentification et n’empêche pas un client scripté d’appeler l’API publique.
Les comptes temporaires ne sont jamais nommés publiquement, conformément à ADR-0001.

Sur quels wikis, quels articles et quelles données cela fonctionne

Wikis

Toute Wikipédia couverte par WikiWho — environ 69 éditions linguistiques, de l’afrikaans au chinois, y compris le simple English. Aucun code spécifique à un wiki n’existe, et aucun n’est nécessaire : le service déduit la langue du nom de base de données du wiki (dewiki → de → de.wikipedia.org) et la confronte à la liste de couverture de WikiWho.

Installer l’outil sur un nouveau wiki ne demande donc aucun développement : il suffit de copier le script dans son espace utilisateur sur ce wiki. C’est l’annoncer à toute une communauté qui demande une discussion.

La contrainte technique qui subsiste porte sur le débit de requêtes et non sur la disponibilité des données : elle doit être convenue avec les opérateurs de WikiWho avant qu’un wiki ne soit largement annoncé.

La page de configuration

wikipeople reste un script personnel : ses réglages vivent donc dans votre propre espace utilisateur, à côté du script — Utilisateur:VOTRE_NOM/wikipeople-config.json. Aucun droit particulier n’est nécessaire, et chaque wiki a sa propre copie. Des valeurs par défaut prêtes à copier sont publiées dans le dépôt pour plusieurs wikis.

{
  "enabled": true,
  "showHistoryIntro": true,
  "editHelpPage": "Aide:Comment modifier une page",
  "sandboxPage": "Wikipédia:Bac à sable",
  "historyIntroPage": null,
  "messages": {}
}

enabled : la valeur false désactive le script. La décision vous appartient, pas à qui exploite le service.
showHistoryIntro : la valeur false supprime l’encadré des pages d’historique, sans toucher à la phrase affichée sous les articles.
editHelpPage et sandboxPage : titres locaux utilisés par l’encadré « vous aussi pouvez modifier cette page ». Sans eux, cette phrase est simplement omise. Ce sont les deux seules valeurs que le script ne peut vraiment pas deviner, et la principale raison de créer la page.
historyIntroPage : titre d’une page en wikicode dont le rendu remplace entièrement l’encadré d’historique. Voir la section suivante.
messages : remplace des chaînes d’interface une à une, par clé. Mieux vaut le laisser vide : un remplacement s’applique quelle que soit la langue dans laquelle vous lisez, alors que les textes intégrés suivent automatiquement votre langue d’interface.

Rien de ce que contient cette page n’est jamais exécuté ni inséré comme balisage. C’est une contrainte de conception délibérée : la page doit rester vérifiable par simple lecture. Le script n’utilise ni eval, ni innerHTML.

La page est entièrement facultative. Sans elle, le script utilise ses textes intégrés dans votre langue d’interface, avec les formes plurielles correctes et une énumération de noms correctement ponctuée.

Si wikipeople est un jour adopté comme gadget global sur un wiki, le même fichier déménage vers MediaWiki:wikipeople-config.json : une copie partagée, entretenue par les administrateurs et administratrices d’interface du wiki, plutôt qu’une par personne.

Personnaliser l’encadré d’historique

Sur une page d’historique, wikipeople affiche un court encadré pédagogique plutôt qu’une attribution. Ce texte intégré est volontairement neutre. La clé historyIntroPage permet de le remplacer par une page en wikicode que vous écrivez vous-même :

{
  "historyIntroPage": "Utilisateur:VOTRE_NOM/wikipeople-intro"
}

Le gadget demande cette page à l’API action=parse de MediaWiki et insère le HTML rendu. Vous disposez donc de tout le wikicode ordinaire : mise en forme, images de Commons, galeries, vidéos, modèles, tableaux, liens. C’est l’analyseur syntaxique de MediaWiki qui fait le rendu et le nettoyage, pas le gadget — lequel se contente d’ajouter le chargement différé aux images et d’empêcher toute vidéo de démarrer d’elle-même.

Traductions. Le gadget essaie plusieurs titres, du plus précis au plus général, selon la langue d’interface du lectorat :

Utilisateur:VOTRE_NOM/wikipeople-intro/fr-ca
Utilisateur:VOTRE_NOM/wikipeople-intro/fr
Utilisateur:VOTRE_NOM/wikipeople-intro

Une page par langue, relisible séparément — contrairement à l’objet messages, qui s’applique en aveugle quelle que soit la langue.

Afficher le nombre réel d’autrices et d’auteurs. Cette page est analysée une seule fois puis réutilisée pour tous les articles : elle ne peut donc pas contenir de valeur propre à un article. Elle déclare à la place un emplacement, et le gadget en remplace le texte :

Classe CSS	Reçoit	Exemple de rendu
`wikipeople-count`	la phrase complète, avec accord du pluriel	`1 718 personnes`, ou `au moins 1 718 personnes`
`wikipeople-number`	le nombre seul, formaté selon la langue	`1 718`

Cet article a été écrit par <span class="wikipeople-count">des dizaines de personnes</span>.

Le texte que vous écrivez à l’intérieur de la balise est le repli : il reste affiché tel quel si le nombre n’est pas disponible. Trois propriétés sont volontaires :

aucun emplacement, aucune requête : une page qui n’en déclare pas ne coûte rien de plus sur une vue d’historique ;
aucun réessai : si le résultat est encore en calcul, votre formulation reste en place. L’encadré n’est jamais réécrit sous les yeux du lectorat dix secondes après le début de la lecture ;
un seul appel : le décompte réutilise le cache de session de la vue article, il n’ajoute pas une seconde requête.

Aller plus loin en JavaScript. Une page de configuration reste déclarative ; du code arbitraire n’y a pas sa place. Deux crochets sont déclenchés avec l’élément déjà rendu, à placer dans votre propre common.js :

mw.hook( 'wikipeople.history' ).add( function ( box, config ) { /* page d’historique */ } );
mw.hook( 'wikipeople.summary' ).add( function ( box ) { /* phrase sous l’article */ } );

Voir ADR-0004.

Ce qui reste hors périmètre

La ligne de partage utile n’est pas « quelle langue » mais « quel projet ». WikiWho n’analyse que Wikipédia. Les autres projets Wikimédia ne disposent d’aucune donnée de provenance :

Wikidata : contenu structuré, pas de wikicode en prose ; la notion de jeton survivant n’a pas de sens.
Wikimedia Commons : la contribution est le fichier lui-même, pas le texte de sa page de description.
Wiktionnaire, Wikisource, Wikivoyage, Wikiversité… : non couverts par WikiWho. Même s’ils l’étaient, l’unité éditoriale (une entrée de dictionnaire, une page d’un ouvrage numérisé) rendrait la phrase peu pertinente.
Éditions de Wikipédia hors des 69 langues couvertes : aucune donnée de provenance disponible.

Articles

Le gadget ne s’affiche que dans un cas précis, et le service ne calcule que dans ce même cas.

Affiché :

espace de noms principal (ns 0) uniquement ;
page existante possédant au moins une version ;
action view, sur la version courante ;
la phrase suppose au moins une personne dans le décompte.

Non affiché :

pages de discussion, pages utilisateur, portails, modèles, catégories, aide, etc. ;
affichage d’une ancienne version ou d’un diff — l’attribution affichée serait trompeuse ;
pages inexistantes ou sans version ;
impression (masqué par CSS).

Un cas particulier : sur la page d’historique d’un article, le gadget n’affiche pas d’attribution mais un court encadré pédagogique expliquant ce qu’est un historique et invitant à modifier l’article. Cet encadré peut être entièrement remplacé par une page en wikicode — voir Personnaliser l’encadré d’historique.

Articles qui fonctionnent mais donnent un résultat dégradé :

Situation	Comportement
Article énorme (réponse WikiWho > 32 Mio)	erreur permanente pour cette version d’algorithme ; rien n’est affiché
Article renommé depuis le calcul	le résultat reste valide : l’identité est l’identifiant de page, pas le titre
Article très récemment créé	`202 pending` à la première visite, puis affichage lors d’une visite ultérieure

Les cas où aucun nom n’est mis en avant — seuils non atteints, article écrit surtout par des robots ou des IP — sont traités dans Quand aucun nom n’apparaît.

Sur le plan de la capacité, le schéma ne stocke qu’un agrégat compact d’environ un kilooctet par page. Plusieurs millions de résultats courants tiennent théoriquement sous la limite nominale de 25 Gio de ToolsDB, mais les index, les versions historiques, la file d’attente et les sauvegardes réduisent cette marge. Une couverture soutenue de plusieurs millions de pages suppose de mesurer la taille réelle après 100 000 pages, de limiter le débit du remplissage à ce que WikiWho accepte explicitement, puis de migrer vers une base dédiée.

Données

Sources consommées :

Source	Usage	En cas de panne
API Action de Wikipédia	validation page/version, résolution des comptes, comptage des robots	la tâche est réessayée
API REST d’historique de MediaWiki	nombre de personnes distinctes	la tâche est réessayée
API WikiWho	provenance des jetons survivants	réessai avec recul exponentiel
API Analytics (Pageviews)	préchauffage des pages populaires	seule la tâche planifiée échoue
ToolsDB (MariaDB)	résultats, baux, file d’attente, curseur de remplissage	l’API signale un défaut de santé ; les travailleurs s’arrêtent

Sur ce que ces données permettent — et ne permettent pas — de dire, voir Comment les trois noms sont sélectionnés.

Capacité de service

La question « et si tout le monde l’installait ? » mérite un chiffre plutôt qu’une intuition.

Le service tourne sur un seul conteneur, limité à un demi-cœur de processeur et 512 Mio de mémoire. Le quota Toolforge de l’outil (16 cœurs, 8 Gio) est très loin d’être atteint : c’est la taille du conteneur qui plafonne, pas le quota.

Mesure	Valeur
Réponse chaude `/v2`	762 octets, environ 12 ms depuis l’intérieur de l’infrastructure Cloud VPS
Requêtes réellement simultanées	environ 15, limite du réservoir de connexions à la base
Débit soutenu estimé	de l’ordre de 60 à 80 requêtes par seconde
Volume quotidien réaliste	environ 1,5 à 2 millions de requêtes par jour

Le débit et le volume quotidien sont déduits de la latence mesurée et de la limite processeur, non relevés sous charge réelle.

Un point compte plus que ces chiffres : wikipeople.toolforge.org n’est pas derrière les serveurs de cache de Wikimédia. Le mandataire de Toolforge ne met rien en cache. Le max-age d’un jour n’évite donc une requête que pour un navigateur qui revient sur le même article, et le cache de session ne dédoublonne pas non plus la lecture de dix articles différents. En pratique, une vue d’article équivaut à une requête.

Le plafond porte donc sur environ 1,5 à 2 millions de vues d’articles par jour, tous lectorats équipés du gadget confondus. C’est confortable pour un script personnel et pour un gadget optionnel ; c’est sans commune mesure avec une activation par défaut pour tout le lectorat, ce qui reste explicitement hors périmètre.

Le point sensible n’est d’ailleurs pas la lecture en régime établi mais une vague de premières visites : une réponse 202 pending est marquée no-store, donc chaque réessai atteint le serveur, et chaque défaut de cache écrit une ligne de file d’attente. Un lancement large coûte plus cher qu’un usage courant, même à nombre de vues égal.

En cas de besoin, la marge existe et ne demande pas de changement d’architecture : augmenter le processeur alloué au conteneur et ajouter des processus de service. La vérification préalable porte sur le nombre de connexions simultanées autorisées à ToolsDB, chaque processus ouvrant son propre réservoir.

Installation en script personnel

Copiez les deux fichiers du dépôt vers :

Utilisateur:VOTRE_NOM/wikipeople.js
Utilisateur:VOTRE_NOM/wikipeople.css

Puis chargez-les depuis Utilisateur:VOTRE_NOM/common.js :

importScript( 'Utilisateur:VOTRE_NOM/wikipeople.js' );
importStylesheet( 'Utilisateur:VOTRE_NOM/wikipeople.css' );

Sur un autre wiki, utilisez le nom local de l’espace utilisateur (User: sur la Wikipédia en anglais, par exemple). Les fichiers eux-mêmes n’ont besoin d’aucune modification, quel que soit le wiki.

Facultativement, ajoutez une troisième page au même endroit — Utilisateur:VOTRE_NOM/wikipeople-config.json — pour indiquer les titres locaux de l’aide et du bac à sable. Voir la page de configuration.

Et si vous voulez rédiger votre propre encadré d’historique, une quatrième page en wikicode suffit : voir Personnaliser l’encadré d’historique.

Ne chargez pas simultanément les anciennes pages ContributeursHumains : les deux scripts demanderaient la même attribution et tenteraient d’afficher un résumé.

Limites connues

WikiWho attribue des jetons de wikicode survivants, pas de la prose rendue ni de la qualité éditoriale.
La soustraction des robots reflète les comptes détenant actuellement le droit bot, pas leur statut au moment de chaque modification historique.
Une donnée périmée peut rester visible pendant une panne prolongée de WikiWho : c’est un choix de disponibilité, rendu explicite par computed_at et source_revision_id.
Toolforge convient à un prototype optionnel, pas au volume de requêtes de l’ensemble du lectorat de Wikipédia — de l’ordre de 1,5 à 2 millions de vues par jour, voir Capacité de service. Un gadget activé par défaut exigerait un chemin de requête à l’échelle de la production Wikimédia et un examen de confidentialité.
Le contenu d’une page historyIntroPage n’est ni relu ni modéré par le service : c’est votre page, dans votre espace utilisateur, sous votre responsabilité éditoriale.
Le gadget n’embarque aucune donnée de démonstration : chaque article affiché s’appuie sur des données Toolforge traçables.
Pouvoir techniquement servir toutes les Wikipédias n’équivaut pas à y être bienvenu. Rien dans la conception ne remplace le fait de demander d’abord à la communauté concernée.

Voir aussi