Manuel:Architecture de MediaWiki

Ce document résulte du projet MediaWiki architecture document dont le contenu a été développé pour être inclus dans le livre Architecture des applications à source ouvert. Le chapitre du livre comprend une section donnant un aperçu historique correspondant à l'historique de MediaWiki, et cette page wiki a été modifiée plusieurs fois depuis que le chapitre a été publié en 2012.

Depuis le début, MediaWiki a été développé spécifiquement pour être le logiciel de Wikipedia. Les développeurs ont travaillé pour faciliter la réutilisation par des utilisateurs tiers, mais l'influence de Wikipedia et les biais ont formaté l'architecture de MediaWiki tout au long de son histoire.

Wikipedia figure parmi les dix sites web les plus populaires du monde, obtenant actuellement environ 400 millions de visiteurs uniques par mois. Avec plus de 100 000 vues par seconde. Wikipedia ne prend pas en charge la publicité commerciale; il est entièrement géré par une organisation non commerciale, la Fondation Wikimedia qui reçoit des donations en tant que source principale du modèle de fonds. Cela signifie que MediaWiki ne doit pas simplement fournir un super site web mais aussi le faire avec un budget restreint. Pour rester compatible avec ces demandes, MediaWiki doit rester compétitif avec les performance, la mise en cache et l'optimisation. Les fonctionnalités coûteuses qui ne peuvent être activées sur Wikipedia sont soit annulées ou désactivées à l'aide des variables de configuration; il y a toujours un compromis entre la performance et le nombre de fonctionnalités.

L'influence de Wikipedia sur l'architecture de MediaWiki ne se limite pas à la performance. A l'opposé des CMS génériques, MediaWiki a été écrit à l'origine dans un but bien précis : prendre en charge une communauté qui crée et maintient la connaissance libre et réutilisable sur une platforme libre. Cela signifie par exemple que MediaWiki ne comprend pas les fonctionnalités régulières que l'on trouve dans les CMS d'entreprise (comme la publication facile des flux de travail ou les ACLs), mais offre une variété d'outils pour gérer les pourriels et le vandalisme.

Ainsi, depuis le début les besoins et les actions de la communauté en constante évolution des contributeurs de Wikipedia a influencé le développement de MediaWiki, et réciproquement. L'architecture de MediaWiki a été dirigée plusieurs fois par les initiatives démarrées ou demandées par la communauté, telles que la création de Wikimedia Commons, ou la fonctionnalité des versions balisées (Flagged Revisions). Les développeurs ont fait des modifications majeures, comme le préprocesseur MediaWiki 1.12, car la façon dont MediaWiki a été utilisé par les wikipediens l'a rendu nécessaire.

MediaWiki a également gagné une solide base d'utilisateurs externes en devenant un logiciel libre depuis ses débuts. Les utilisateurs tiers savent bien que tant qu'un site web qui possède un profil majeur tel que Wikipedia, utilise MediaWiki, le logiciel sera maintenu et amélioré. MediaWiki était à l'origine orienté site Wikimedia, mais des efforts ont été faits pour le rendre plus générique et mieux accomoder les besoins de ces utilisateurs tiers. Par exemple, MediaWiki est fourni avec un installateur basé sur le web, rendant ainsi le processus d'installation beaucoup moins pénible que si tout devait être fait en mode ligne de commande et que le logiciel contenait les chemins codés en dur pour Wikipedia.

MediaWiki est, et reste encore, le logiciel de Wikipedia; cela se voit au long de son histoire et dans son architecture.

Base de code et pratiques MediaWiki

Architecture générale

couche utilisateur	navigateur web
couche réseau	Varnish
	Serveur web Apache
couche logique	Scripts PHP de MediaWiki
	PHP
couche de données	Système de fichiers	Base de données MySQL (programme et contenu)	Système de mise en cache

PHP

PHP a été choisi comme environnement pour la Phase II du logiciel de Wikipedia en 2001; MediaWiki n'a cessé de croître depuis organiquement et reste toujours en évolution. La plupart des développeurs MediaWiki sont bénévoles et contribuent sur leur temps libre; ils furent très peu nombreux au début. Certaines décisions ou omissions dans l'architecture du logiciel peuvent apparaître mauvaises à postériori, mais il est difficile de reprocher aux concepteurs de ne pas avoir implémenté certaines abstractions qui apparaîssent aujourd'hui comme critiques, lorsque la base de code initiale était si petite et que le temps nécessaire à la développer était si court.

Par exemple, MediaWiki utilise des noms de classes non préfixés, ce qui peut poser problème lorsque le noyau PHP et les développeurs PECL ajoutent de nouvelles classes. Comme conséquence, la classe Namespace de MediaWiki doit être renommée en MWNamespace pour être compatible avec PHP 5.3. L'utilisation d'une manière cohérente d'un préfixe pour toutes les classes (comme "MW") aurait facilité l'inclusion de MediaWiki dans une autre application ou une bibliothèque.

Le fait de se baser sur PHP n'a pas été probablement le meilleur choix au niveau performance, car ce langage n'a pas bénéficié des améliorations que certains autres langages dynamiques auraient pu recevoir. L'utilisation de Java aurait certes été plus favorable pour les performances et pour l'exécution simplifiée du déploiement pour les tâches de maintenance du serveur. D'un autre côte PHP est très populaire ce qui facilite le recrutement de nouveaux développeurs.

Même si MediaWiki contient encore du code ancien un peu sale, la plus grande partie des améliorations a été faite au fil des années, et les nouveaux éléments d'architecture ont été introduits dans MediaWiki tout au long de son histoire. Cela comprend les classes Parser, SpecialPage, et Database, la classe Image et la hiérarchie de la classe FileRepo, ResourceLoader, et la hiérarchie de Action. MediaWiki a débuté sans aucun de ces éléments, mais chacun d'eux tous prend en charge les fonctionnalités qui ont existé depuis le commencement. Beaucoup de développeurs sont intéressés principalement par le développement des fonctionnalités et l'architecture est souvent laissée de côté, puis reprise ultérieurement quand le coût du travail dans une architecture qui n'est plus adaptée se fait sentir.

Sécurité

Parce que MediaWiki est la plateforme pour les sites ayant un profil de grande valeur tels que Wikipedia, les développeurs du noyau et les relecteurs de code on renforcé les règles strictes de sécurité. Pour qu'il soit plus facile d'écrire du code sécurisé, MediaWiki fournit au développeurs des sur-couches (wrappers) autour de la sortie HTML et des requêtes à la base de données, pour gérer l'échappement. Pour nettoyer l'entrée utilisateur, on utilise la classe WebRequest, qui analyse les données passées dans l'URL ou un formulaire via POST. Il supprime les barres obliques des guillemets magiques, enlève les caractères d'entrée non autorisés et normalise les séquences Unicode. Nous évitons le Cross-site request forgery (CSRF) en utilisant les jetons, et le cross-site scripting (XSS) en validant les entrées et en échappant les sorties, habituellement avec la fonction PHP htmlspecialchars(). MediaWiki fournit également (et utilise) un nettoyeur HTML avec la classe Sanitizer, et des fonctions de la base de données qui empêchent l'injection de SQL.

Configuration

MediaWiki offre des centaines de paramètres de configuration stockés dans des variables PHP globales. Leur valeur par défaut est définie dans DefaultSettings.php, mais l'administrateur système peut réécraser ces valeurs en mettant à jour LocalSettings.php.

MediaWiki se basait à l'origine sur les variables globales, à la fois pour la configuration et pour le traitement des contextes. Les variables globales causent de sérieux problèmes de sécurité avec la fonction PHP register_globals (dont MediaWiki n'a pas besoin depuis la version 1.2). Ce système limite également les abstractions potentielles pour la configuration et rend le processus de démarrage plus difficile à optimiser. De plus, l'espace de noms de configuration est partagé avec les variables utilisées pour l'enregistrement et le contexte des objets, ce qui peut présenter des conflits potentiels. D'un point de vue utilisateur, les variables de configuration globales faisaient que MediaWiki semblait difficile à configurer et à maintenir. Le développement de MediaWiki a reposé sur le déplacement progressif des contextes à partir des variables globales vers les objets. En enregistrant le contexte des traitements dans les variables des membres des objets, nous permettons à ces objets d'être réutilisés d'une manière beaucoup plus souple.

Stockage de la base de données et du texte

Schéma de la base de données du noyau MediaWiki

MediaWiki utilise un serveur de base de données relationnelle depuis le logiciel de la Phase II. Le système de base de données (DBMS) par défaut (et le mieux pris en charge) de MediaWiki est MySQL, utilisé sur tous les sites Wikimedia, mais d'autres types de DBMS (comme PostgreSQL, Oracle, ou SQLite) ont leurs implémentations prises en charge par la communauté. Un administrateur système peut choisir son DBMS lors de l'installation de MediaWiki, et MediaWiki fournit à la fois un niveau d'abstraction de la base de données et un niveau d'abstraction pour les requêtes qui simplifient l'accès à la base de données pour les développeurs.

L'organisation actuelle contient des dizaines de tables. La plupart concernent le contenu du wiki (comme les tables page, revision, category, et recentchanges). Les autres tables contiennent les données relatives aux utilisateurs (user, user_groups), aux fichiers de médias (image, filearchive), à gestion du cache (objectcache, l10n_cache, querycache) et aux outils internes (job pour la file d'attente des tâches), entre autre. Les tables d'index et de résumé sont très souvent utilisées dans MediaWiki, depuis que les requêtes SQL qui balaient un très grand nombre de lignes peuvent être très coûteuses, particulièrement sur les sites Wikimedia. Il n'est pas recommandé habituellement de faire des requêtes qui ne sont pas indexées.

La base de données a subit des dizaines de modifications du schéma au fil des années, la plus importante ayant été le découplage du stockage du texte et la gestion du suivi des versions dans MediaWiki 1.5.

Principales tables de contenu de MediaWiki 1.4 et 1.5.

Dans le modèle 1.4, le contenu était stocké dans deux tables importantes, cur (contenant le texte et les métadonnées de la version actuelle de la page) et old (contenant les versions antérieures); les pages supprimées était gardées dans archive. Lorsqu'une modification était faite, la version antépénultième était recopiée dans la table old, et la nouvelle modification était sauvegardée dans cur. Lorsqu'une page était renommée,le titre de la page devait être mis à jour dans les métadonnées de toutes les versions de old, ce qui pouvait prendre un certain temps. Lorsqu'une page était supprimée, ses entrées dans les deux tables cur et old devaient être copiées dans la table archive avant d'être supprimées; ce qui impliquait de recopier le texte de toutes les versions, qui pouvait être conséquent et prendre du temps.

Dans le modèle 1.5, les métadonnées des versions et le texte des versions furent séparés : les tables cur et old ont été remplacées par page (métadonnées des pages), revision (métadonnées de toutes les versions, anciennes ou actuelles) et text (texte de toutes les versions, anciennes, actuelles ou supprimées). Maintenant, quand une modification est réalisée, les métadonnées des versions n'ont plus besoin d'être recopiées dans les tables : l'ajout d'une nouvelle entrée et la mise à jour du pointeur page_latest suffisent. De même, les métadonnées de la version n'incluent plus le titre de la page mais seulement son ID : cela supprime le besoin de renommer toutes les versions lorsqu'une page change de nom.

La table revision stocke les métadonnées de chaque version, et non pas le texte de leur contenu; à la place, elles contiennent l'ID du texte qui pointe vers la table text, qui contient le texte actuel. Lorsqu'une page est supprimée, le texte de chacune des versions de la page reste en place et n'a pas besoin d'être déplacé vers une autre table. La table text est composée de correspondances entre les IDs et les blobs de texte; un champ d'indicateurs renseigne si le blob du texte est compressé (gzip) afin d'économiser de l'espace, ou si le blob du texte est seulement un pointeur vers un espace de stockage textuel externe. Les sites Wikimedia utilisent une grappe de stockage MySQL externe pour la sauvegarde, avec des blobs de quelques dizaines de versions. La première version du blob est stockée entièrement, et les versions suivantes de la même page sont stockées comme sous forme de différences (diffs) relatives à la version précédente; les blobs sont ensuite compressés avec gzip. Les versions sont groupées par page; elles ont tendance à se ressembler, donc les diffs restent relativement petits et gzip fonctionne très bien. Le taux de compression des sites Wikimedia approche les 98 %.

MediaWiki inclus également la gestion du partage de charge (load balancing), ajoutée dès 2004 dans MediaWiki 1.2 (lorsque Wikipedia a reçu un second serveur — ce fut alors un très gros défi). Le partage de charge (décision du code PHP de MediaWiki pour déterminer à quel serveur il faut se connecter) est dorénavant une partie critique de l'infrastructure de Wikimedia, ce qui explique son influence sur certaines décisions de l'algorithme dans le code. L'administrateur système peut spécifier dans la configuration de MediaWiki qu'il y a un serveur de base de données maître, et n'importe quel nombre de serveurs de base de données esclave; vous pouvez utiliser un système de pondération de chaque serveur pour profiler la répartition de la charge. Toutes les écritures sont envoyées au maître mais les lectures sont réparties sur les serveurs en fonction de leur pondération par le système de gestion de la charge. Il garde trace également du délai de réplication de chaque esclave. Si le temps de latence pour la réplication sur un esclave dépasse les 30 secondes, celui-ci ne recevra plus de demandes de lecture pour les traiter; si tous les esclaves se retrouvent dans cette situation alors MediaWiki passe automatiquement en mode lecture seule.

Le garant de la chronologie dans MediaWiki s'assure que le temps de réplication ne fait jamais qu'un utilisateur puisse voir une page sur laquelle il a demandé une action et où cette dernière n'aurait pas encore été réalisée. Ceci est fait en stockant la position du master dans la session utilisateur si la requête qu'il a faite comprenait une demande d'écriture. La prochaîne fois que l'utilisateur fait une demande de lecture, le partage de charge relit cette position à partir des données session, et essaie de sélectionner un esclave qui a atteint cette position de réplication pour lui distribuer la demande. Si aucun n'est trouvé, on attend jusqu'à ce que l'un d'entre-eux se libère. Il peut sembler aux autres utilisateurs que l'action n'est pas encore exécutée mais la chronologie reste cohérente pour chaque utilisateur.

Demandes, mise en cache et livraison

Flux du travail de l’exécution d’une requête web

index.phpest le point d'accès principal de MediaWiki, et gère la plupart des requêtes traitées par les serveurs de l'application (c'est à dire les requêtes non satisfaites par l'infrastructure de la gestion du cache; voir ci-dessous). Le code exécuté à partir de index.php réalise les contrôles de sécurité, charge les paramètres de configuration par défaut de includes/DefaultSettings.php, devine la configuration avec includes/Setup.php, et applique les paramètres du site contenus dans LocalSettings.php. Ensuite il instancie un objet MediaWiki object ($mediawiki), et crée un objet Title ($wgTitle) qui dépend du titre et des paramètres de l'action contenue dans les paramètres de la requête.

index.php peut prendre une variété de paramètres d'action dans l'URL de la requête; l'action par défaut est view, qui affiche la vue habituelle du contenu d'un article. Par exemple la requête https://en.wikipedia.org/w/index.php?title=Apple&action=view affiche le contenu de l'article « Apple » de la Wikipedia anglophone.. Les autres actions fréquentes incluent edit (ouvrir un article pour le modifier), submit (afficher ou enregistrer un article), history (afficher l'historique d'un article) et watch (ajouter un article à la liste de suivi de l'utilisateur). Les actions administratives comprennent delete (pour supprimer un article) et protect (pour empêcher de modifier un article).

MediaWiki::performRequest() est ensuite appelé pour gérer la majeure partie de la requête de l'URL. Il vérifie les mauvais titres, lit les restrictions, les redirections locales entre wikis, les boucles de redirection, et détermine si la requête concerne une page normale ou une page spéciale.

Les demandes de pages usuelles sont gérées pour MediaWiki::initializeArticle(), pour créer des objets Article pour la page ($wgArticle), puis pour MediaWiki::performAction() qui gère les actions standard. Un fois l'action terminée, MediaWiki::doPostOutputShutdown() finalise la requête en validant les transactions dans la base de données, en générant le HTML, et en activant les mises à jour différées via la file d'attente des travaux. MediaWiki::restInPeace() valide (commit) les mises à jour différées et ferme la tâche simplement.

Si la page demandée est une page de type Special: (c'est à dire qui n'est pas une page de contenu wiki normale, mais une page liée à un logiciel particulier tel que Statistics), SpecialPageFactory::executePath est appelé à la place de initializeArticle(); puis le script PHP correspondant est appelé. Les pages spéciales peuvent faire toutes sortes de manipulations magiques, et chacune d'elles a un rôle particulier, habituellement indépendant de tout article et de son contenu. Les pages spéciales fournissent différentes sortes de rapports (les modifications récentes, les journaux, les pages sans catégorie) ainsi que les outils d'administration du wiki (le blocage des utilisateurs, la modification des droits utilisateur), entre autres. Le flux de travail de leur exécution dépend de la fonction réalisée.

Plusieurs fonctions contiennent du code de profilage, ce qui permet de suivre le flux de travail de leur exécution à des fins de débogage, dans le cas où le profilage est activé. Le profilage est réalisé en appelant les fonctions wfProfileIn et wfProfileOut pour respectivement démarrer et arrêter le profilage d'une fonction à tracer; ces deux fonctions utilisent le nom de cette dernière, comme paramètre. Sur les sites Wikimedia, le profilage est réalisé sur un pourcentage de l'ensemble des requêtes afin de préserver les performances. MediaWiki envoie les paquets UDP à un serveur central qui les collecte et produit les données de profilage.

Assemblage d’une page non mise en cache

Lors de l'affichage d'une page, le code HTML peut être puisé directement du cache (voir ci-dessous); s'il ne s'y trouve pas on expanse d'abord les modèles, puis les fonctions d'analyse syntaxique et les variables. Ceci crée le wikicode expansé, qui est un résultat intermédiaire pouvant être vu avec Special:ExpandTemplates, et qui dépend de :

• le wikicode;
• les modèles auxquels il est fait référence directement ou indirectement;
• les fonctions d'analyse syntaxique auxquelles il est fait référence directement ou indirectement;
• les valeurs des variables auxquelles il est fait référence directement ou indirectement.

Puis ce wikicode expansé est converti en code HTML ; il est envoyé vers l'utilisateur, et contient des références au CSS, au JavaScript, et aux fichiers d'images. L'utilisateur peut voir ce résultat intermédiaire en appliquant l'option Code source de la page du navigateur. Le code HTML d'une page donnée est fonction des éléments suivants :

• le wikicode expansé;
• le mode : la lecture ou bien la modification (voir ci-dessous);
• l'existence de pages liées en interne (affichées ou par un lien de modification)
• l'habillage et les autres préférences utilisateur;
• le nom d'utilisateur;
• l'état de l'utilisateur (davantage de liens s'il s'agit d'un administrateur système, etc.);
• l'espace de noms (définit le lien vers la page de discussion, ou dans le cas d'une page de discussion, la page qui lui est associée);
• l'indication si la page est suivie par l'utilisateur (donne le lien de suivi ou de non-suivi);
• indication si la page de discussion de l'utilisateur a été modifiée récemment (fournit un message).

Enfin le navigateur réalise le rendu du HTML en utilisant les fichiers référencés. Le résultat vu par l'utilisateur sur l'écran dépend :

• du code HTML
• des fichiers référencés par le code HTML, tels que les images incluses, les fichiers CSS du côté serveur et les fichiers JavaScript
• du navigateur et de ses paramètres, y compris éventuellement un fichier CSS local, et la résolution de l'écran.

Si JavaScript répond à un événement tel qu'un clic de souris, la page affichée dépend également de ces événements. Ceci s'applique par exemple aux tables que vous pouvez trier.

Lorsque l'utilisateur sélectionne l'onglet de Modifier, le wikicode lui-même lui est envoyé, soit pour toute la page, soit pour une section donnée uniquement. Lorsque l'utilisateur appuie sur Show preview, sa nouvelle version du wikicode est envoyée au serveur, qui renvoie la nouvelle version du code Html, qui est rendu à nouveau et affiché au-dessus ou en-dessous de la nouvelle version du wikicode (renvoyée également par le serveur). Après avoir éventuellement fait plusieurs changements et aperçus, l'utilisateur appuie sur « Sauvegarder la page » et envoie sa version finale sur le serveur qui à son tour enregistre les modifications et retourne à nouveau le Html de la nouvelle version. Dans certains cas une conversion automatique du wikicode est appliquée également à cette étape.

Mise en cache

MediaWiki lui-même a été amélioré au niveau performance car il a un rôle central dans les sites Wikimedia, mais il fait également partie d'un écosystème plus vaste qui a influencé son architecture. L'infrastructure du système de cache de Wikimedia a imposé les limites de MediaWiki; les développeurs ont travaillé sur les problèmes, non pas en essayant de formater l'infrastructure du cache optimisée extensivement, mais en essayant plutôt de rendre MediaWiki plus flexible, de sorte qu'il puisse s'exécuter dans cette infrastructure sans en compromettre la performance ni les besoins du cache.

Sur les sites Wikimedia, la plupart des requêtes sont traitées par des proxy de cache inverse (Squids), et ne sont même jamais des serveurs d'application MediaWiki. Les squids contiennent les versions statiques des pages entières générées et servies pour des accès en lecture simple aux utilisateurs qui ne sont pas connectés au site. MediaWiki prend en charge nativement Squid et Varnish, et s'intègre à cette couche de mise en cache par exemple en leur demandant de supprimer une page du cache quand elle a été modifiée. Pour les utilisateurs connectés et les autres requêtes qui ne peuvent pas être traitées par Squids, celui-ci les redirige sur le serveur web (Apache).

Le second niveau de l'utilisation du cache apparaît quand MediaWiki génère le rendu et assemble la page à partir d'objets divers dont chacun peut déjà se trouver dans le cache afin de réduire le nombre d'appels à venir. De tels objets incluent l'interface de la page (barre latérale, menus, texte de l'interface utilisateur) et le propre contenu, analysé à partir du wikicode. L'objet cache en mémoire est présent dans MediaWiki depuis la première version 1.1 (2003), et il est particulièrement important pour éviter d'avoir à réanalyser syntaxiquement de grandes pages complexes.

Les données de la session de connexion peuvent également être stockées en mémoire cache, ce qui permet aux sessions de fonctionner de manière transparente sur plusieurs serveurs web de l'interface utilisateur dans une configuration avec partage de charge (Wikimedia dépend fortement de l'équilibrage de la charge et utilise LVS avec PyBal).

Depuis la version 1.16, MediaWiki utilise un cache d'objets dédié pour le texte traduit de l'interface utilisateur; celui-ci a été ajouté après avoir remarqué qu'une grande partie des objets mis en cache dans memcached était constituée des messages traduits de l'interface utilisateur dans la langue de celui-ci. Le système est basé sur la récupération rapide des messages individuels à partir de bases de données constantes (CDB), c'est à dire de fichiers à l'aide de paires clé-valeur. Les CDB minimisent la surcharge de mémoire et le temps de démarrage dans le cas typique; ils servent aussi pour le cache interwiki.

Le dernier niveau de cache est constitué du cache d' opcode PHP généralement activé pour accélérer les applications PHP. La compilation peut être un processus qui prend du temps; pour éviter de compiler les scripts en opcode à chaque fois qu'ils sont appelés, un accélérateur PHP peut être utilisé pour stocker le opcode compilé et l'exécuter directement sans compilation. MediaWiki va fonctionner simplement avec beaucoup d'accélérateurs tels que APC, l'accélérateur PHP...

En raison de son biais pour Wikimedia, MediaWiki est optimisé pour cette infrastructure de mise en cache complète, multi-couches et distribuée. Néanmoins, il prend également en charge de manière native des configurations alternatives pour les sites plus petits. Par exemple, il offre un système de mise en cache de fichiers simplifié optionnel qui stocke la sortie des pages entièrement rendues, comme le fait Squid. En outre, la couche de mise en cache abstraite d'objets MediaWiki lui permet de stocker les objets du cache dans plusieurs endroits, y compris le système de fichiers, la base de données ou le cache opcode.

ResourceLoader

Tout comme d'autres applications web, l'interface de MediaWiki est devenue plus interactive et plus dynamique au fil des années, grâce particulièrement à l'utilisation de JavaScript. Les efforts d'utilisabilité initiés en 2008, ainsi que la gestion avancée des médias (par exemple, l'édition en ligne de fichiers vidéo), appelé pour des améliorations spécifiques des performances de l'interface utilisateur.

Pour optimiser la distribution des ressources JavaScript et CSS, le module ResourceLoader a été développé. Démarré en 2009, il a été finalisé en 2011 et est devenu une fonctionnalité du noyau MediaWiki depuis la version 1.17. Le ResourceLoader charge les parties JavaScript et CSS à la demande, ce qui réduit la charge et le temps de l'analyse syntaxiques des fonctionnalités non utilisées, par exemple dans les anciens navigateurs. Il minimise également le code, regroupe les ressources pour économiser les requêtes et peut inclure des images et des URIs de données.

Langues

Page principale : Manual:Language

Contexte et justification

Une partie centrale de la contribution effective et de la diffusion de la connaissance libre à tous est de la fournir dans le plus grand nombre possible de langues. Wikipedia est disponible dans plus de 280 langues et les articles encyclopédiques en anglais représentent moins de 20 % de l'ensemble des articles. Parce que Wikipedia et sa fratrie existent dans de nombreuses langues, il est important non seulement de fournir le contenu dans la langue maternelle du lecteur, mais aussi de fournir une interface localisée et des outils de saisie et de conversion efficaces, pour que les utilisateurs puissent contribuer au contenu.

Pour cette raison, la localisation et l'internationalisation (l10n et i18n) sont un composant central de MediaWiki. Le système i18n est omniprésent et affecte de nombreuses parties du logiciel; c'est aussi l'un des plus flexibles et les plus riches en fonctionnalités. La facilité du traducteur est habituellement préférée à celle du développeur, mais on s'accorde que le coût soit acceptable.

MediaWiki est actuellement traduit dans plus de 350 langues, y compris les non-latines et celles qui s'écrivent de la droite vers la gauche (right-to-left - RTL), avec différents niveaux de complétion. L'interface et le contenu peuvent être dans des langues différentes et mixer des directionnalités différentes.

Langue du contenu

MediaWiki utilisait initialement un encodage fonction de la langue, ce qui a produit un grand nombre de problèmes; par exemple, les écritures étrangères ne pouvaient pas être utilisées dans le titre des pages. UTF-8 a été choisi à la place. La prise en charge des ensembles de caractères différents de UTF-8 a été abandonnée en 2005, en même temps que la modification générale du schéma de la base de données dans MediaWiki 1.5 ; le contenu doit dorénavant être encodé en UTF-8.

Les caractères non disponibles sur le clavier de l'éditeur peuvent être personnalisés et insérés via le Edittools MediaWiki, qui est un message d'interface apparaîssant sous la fenêtre de modification; sa version JavaScript insère automatiquement le caractère cliqué dans la fenêtre d'édition. L'extension WikiEditor pour MediaWiki, développée dans le cadre d'un effort d'utilisabilité, fusionne les caractères spéciaux avec la barre d'outils de modification. Une autre extension, appelée UniversalLanguageSelector , fournit des méthodes d'entrée supplémentaires et des fonctionnalités de correspondance des clés pour les caractères non ASCII.

Les améliorations récentes et à venir incluent une meilleure prise en charge du texte RTL s'écrivant de droite à gauche, du texte bidirectionnel (LTR et RTL c'est à dire dans les deux sens, sur la même page) et UniversalLanguageSelector .

Langue de l’interface

Les messages d'interface ont été stockés dans des tableaux PHP de paires clé valeur depuis que le logiciel Phase III est créé. Chaque message est identifié par une clé unique, et reçoit des valeurs différentes en fonction de la langue. Les clés sont définies par les développeurs encouragés à utiliser des préfixes pour les extensions; par exemple les clés des messages pour l'extension UploadWizard commenceront avec mwe-upwiz-, où mwe représente MediaWiki extension.

Les messages MediaWiki peuvent contenir des paramètres fournis par le logiciel ce qui influencera souvent la grammaire du message. Afin de prendre en charge pratiquement n'importe quelle langue possible, le système de traduction de MediaWiki a été amélioré et complexifié au fil du temps pour s'adapter à leurs caractéristiques spécifiques et à leurs exceptions, souvent considérées comme des étranges par les anglophones.

Par exemple, les adjectifs sont des mots invariables en anglais, mais des langues telles que le français il faut que l'adjective s'accorde avec le nom, en genre et en nombre. Si le profil de l'utilisateur comporte des déclarations sur le genre, le sélecteur {{GENDER:}} peut être utilisé dans les messages d'interface pour les récupérer si nécessaire (plus d'informations...). D'autres sélecteurs incluent {{PLURAL:}} pour les pluriels simples et les langues comme l'arabe avec des nombres doubles, triples ou à peu de valeur, et {{GRAMMAR:}} pour fournir des fonctions de transformation grammaticale pour des langues comme le finnois dont la grammaire provoque des modifications ou des inflexions selon les cas.

La distinction du genre peut aussi être utilisée pour le nom des espaces de noms utilisateur qui dépendent du genre, de sorte que le titre et l'URL de la page se rapportent correctement à l'utilisateur. Les variantes de genre des espaces de noms MediaWiki standard sont définies par $namespaceGenderAliases dans les MessagesXx.php de chaque langue, tandis que $wgExtraGenderNamespaces peut être utilisé pour les espaces de nom spécifiques au wiki. Depuis r107559, 13 langues utilisent cette fonctionnalité par défaut :

• Arabic
• Czech
• German
• Lower Sorbian
• Spanish
• Galician
• Hebrew
• Upper Sorbian
• Polish
• Brazilian Portuguese
• Portuguese
• Russian
• Saterland Frisian

Internationaliser les messages

Voir aussi : [[:Messages système ]]

Les messages traduits d'interface pour MediaWiki se trouvent dans les fichiers de MessagesXx.php, où Xx est le code ISO-639 de la langue (par exemple MessagesFr.php pour le français); les messages par défaut sont en anglais et sont stockés dans MessagesEn.php. Les extensions MediaWiki utilisent un système similaire ou rangent tous les messages traduits dans un fichier [nomDeLextension].i18n.php. En même temps que les traductions, les fichiers de messages comprennent également des informations qui dépendent de la langue telles que le format des dates.

Les traductions contributrices se faisaient en soumettant des patches PHP pour les fichiers MessagesXx.php. En décembre 2003, MediaWiki 1.1 a introduit les messages de base de données, un sous-ensemble de pages wiki dans l'espace de noms MediaWiki contenant les messages d'interface. Le contenu de la MediaWiki:[clé de message] de la page du wiki est le texte du message, et il remplace sa valeur dans le fichier PHP. Les versions traduites du message sont au MediaWiki:[clé de message]/[code de langue], e.g. MediaWiki:Rollbacklink/de.

Cette fonctionnalité a permis aux utilisateurs de traduire (et de personnaliser) les messages d'interface localement sur leur wiki, mais le processus ne met pas à jour les fichiers i18n livrés avec MediaWiki. En 2006, Niklas Laxström a créé un site web spécial et fortement personnalisé de MediaWiki (hébergé maintenant sur translatewiki.net) où les traducteurs peuvent facilement traduire les messages d'interface dans toutes les langues, simplement en éditant une page wiki. Les fichiers MessagesXx.php sont ensuite mis à jour dans le répertoire du code MediaWiki, d'où ils seront automatiquement récupérés par tout wiki. Sur les sites Wikimedia, les messages de base de données sont maintenant utilisés uniquement pour la personnalisation, et non plus pour la traduction. Les extensions MediaWiki et certains programmes associés tels que les robots, sont aussi traduits sur translatewiki.net.

Pour aider les traducteurs à comprendre le contexte et la signification d'un message d'interface, une bonne pratique dans MediaWiki est de fournir la documentation de chaque message. Cette documentation est stockée dans un fichier de message spécial, avec le code de langue qqq qui ne correspond pas à une langue réelle. La documentation de chaque message est ensuite affichée dans l'interface de traduction sur translatewiki.net. Un autre outil utile est le code de langue qqx  : lorsqu'il est utilisé avec le paramètre &uselang pour afficher une page wiki (par exemple en.wikipedia.org/wiki/Special:RecentChanges?uselang=qqx), MediaWiki affichera les touches du message au lieu de leurs valeurs dans l'interface utilisateur; cela est très utile pour identifier quel message est à traduire ou à modifier.

Graphe du repli des langues

Les utilisateurs enregistrés peuvent définir dans leurs préférences la langue de leur interface; cela se substitue à la langue par défaut de l'interface du site. MediaWiki prend également en charge les langues de repli : si un message n'est pas disponible dans la langue choisie, il sera affiché dans la langue la plus proche possible, et pas nécessairement en anglais. Par exemple la langue de repli pour le breton est le français.

Utilisateurs

Les utilisateurs sont représentés dans le code en utilisant des instances de la classe User qui encapsule tous les paramètres spécifiques à l'utilisateur (identifiant utilisateur, nom, droits, mot de passe, adresse courriel, etc.). Les classes de clients utilisent des accesseurs pour accéder à ces champs; elles effectuent tout le travail pour déterminer si l'utilisateur est connecté et si l'option demandée peut être satisfaite à partir des cookies ou si une requête à la base de données est nécessaire. La plupart des paramètres nécessaires pour générer les pages habituelles sont définis dans le cookie pour minimiser l'utilisation de la base de données.

MediaWiki fournit un système de droits très granulaire, avec essentiellement un privilège utilisateur pour chaque action possible. Par exemple, pour effectuer l'action de rollback (c'est-à-dire rappeler rapidement les modifications du dernier utilisateur qui a modifié une page particulière), un utilisateur a besoin de la permission rollback, incluse par défaut dans le groupe utilisateur MediaWiki sysop. Mais il peut également être ajouté à d'autres groupes utilisateur, ou avoir un groupe utilisateur dédié qui fournit uniquement cette permission (c'est le cas sur la Wikipédia anglaise, avec le groupe Rollbackers). La personnalisation des droits des utilisateurs se fait en éditant le tableau $wgGroupPermissions dans LocalSettings.php; par exemple, $wgGroupPermissions['user']['movefile'] = true; permet à tous les utilisateurs enregistrés de renommer des fichiers. Un utilisateur peut appartenir à plusieurs groupes et bénéficier des droits supérieurs de chacun d'eux.

Cependant, le système des droits utilisateur de MediaWiki a été vraiment conçu en tenant compte de Wikipedia, c'est-à-dire un site dont le contenu est accessible à tous, avec seulement certaines actions limitées à certains utilisateurs. MediaWiki manque d'un concept unifié et perpétuel de permissions; il ne fournit pas les fonctionnalités traditionnelles du CMS comme la restriction de l'accès à la lecture ou à l'écriture par espace de noms, de catégorie, etc. Seules quelques extensions MediaWiki fournissent de telles fonctionnalités jusqu'à un certain point.

Contenu

Structure du contenu

Le concept d'espaces de noms a été utilisé à l'époque UseModWiki de Wikipedia, où les pages de discussion étaient sous le titre [nom d'article]/Talk. Les espaces de noms ont été officiellement introduits dans le premier script PHP de Magnus Manske. Ils ont été réimplémentés à plusieurs reprises au fil des ans, mais ont conservé la même fonction : séparer différents types de contenu. Ils sont constitués d'un préfixe, séparé du titre de la page par un caractère deux-points (par exemple Talk: ou File: et Template:) ; l'espace de noms de contenu principal n'a pas de préfixe. Les utilisateurs Wikipédia les ont rapidement adoptés, et ils ont fourni à la communauté différents espaces d'évolution. Les espaces de noms se sont avérés être une caractéristique importante de MediaWiki, car ils créent les conditions préalables nécessaires pour la communauté d'un wiki et mettent en place des discussions de méta-niveau, des processus communautaires, des portails, des profils utilisateurs, etc.

La configuration par défaut de l'espace de noms principal de contenu de MediaWiki est d'être plat (sans sous-page), car c'est ainsi que fonctionne Wikipedia, mais il est trivial de les activer. Elles sont activées dans d'autres espaces de noms (par exemple, User:, où vous pouvez par exemple travailler sur des projets d'articles) et en afficher des parties.

Les espaces de noms séparent le contenu par type; dans le même espace de noms, les pages peuvent être organisées par sujet en utilisant des catégories, un schéma d'organisation pseudo-hiérarchique introduit dans MediaWiki 1.3.

Traitement du contenu : langage de balisage MediaWiki et analyseur syntaxique

Le contenu généré par l'utilisateur stocké par MediaWiki n'est pas du HTML, mais il est exprimé dans un langage de balisage spécifique à MediaWiki, appelé quelques fois wikicode. Il permet aux utilisateurs de modifier le formatage (par exemple mettre en gras, en italique en utilisant des guillemets), d'ajouter des liens (en utilisant des crochets), d'inclure des modèles, d'insérer du contenu dépendant du contexte (comme une date ou une signature) et de faire se produire un incroyable nombre d'autres choses magiques.

Pour afficher une page, ce contenu doit être analysé, assemblé à partir de toutes les pièces externes ou dynamiques qu'il appelle, et converti en HTML approprié. L'analyseur syntaxique est l'une des parties les plus essentielles de MediaWiki, qui le rend également difficile à modifier ou à améliorer. Parce que des centaines de millions de pages wiki dans le monde dépendent de l'analyseur syntaxique, pour continuer à produire le HTML de la même manière, il doit rester extrêmement stable.

Le langage de balisage n'avait pas été formellement spécifié depuis ses débuts; il a commencé en partant du balisage UseModWiki, puis s'est transformé et a évolué au fil des besoins. Par exemple l'utilisation du format ThreadMode pour les discussions a fait que Magnus Manske a implémenté les 3 ou 4 tildes (~~~~) comme raccourci pour signer les billets dans un texte non structuré. Les tildes ont été choisis parce qu'ils ressemblaient à la signature manuscrite de son père.

En l'absence de spécification formelle, le langage de marquage MediaWiki est devenu un langage complexe et idiosyncratique, pratiquement uniquement compatible avec l'analyseur MediaWiki; il ne peut pas être représenté sous forme de grammaire formelle en utilisant les syntaxes BNF, EBNF ou ANTLR. La spécification de l'analyseur actuel est appelée en plaisantant « tout ce que l'analyseur fournit du wikicode, plus quelques centaines de cas de test ».

Plusieurs tentatives sont été faites avec des analyseurs parallèles mis aucune n'est allée aussi loin. En 2004, un analyseur expérimental a été écrit par Jens Frank pour le wikicode et a été activé sur Wikipedia; malheureusement il a dû être désactivé trois jours plus tard à cause des performances médiocres de l'allocation mémoire pour les tableaux PHP. Depuis lors, la majeure partie de l'analyse utilise une énorme pile d'expressions régulières ainsi qu'une tonne de fonctions d'aide. Le marquage du wiki, et tous les cas spéciaux que le parseur doit prendre en charge, sont également devenus considérablement plus complexes, rendant les futures tentatives encore plus difficiles.

Une amélioration notable a été la réécriture du préprocesseur de Tim Starling dans MediaWiki 1.12, dont la principale motivation était d'améliorer les performances de l'analyseur sur les pages comportant des modèles complexes. Le préprocesseur convertit le wikicoxde en un arbre XML DOM représentant des parties du document (appels de modèles, de fonctions d'analyseur, balises d'accroches, titres de section et quelques autres structures), mais peut sauter les branches mortes dans l'expansion des modèles, comme les cas non suivis #switch et les valeurs par défaut inutilisées pour les arguments des modèles. L'analyseur itère ensuite en parcourant la structure DOM et convertit son contenu en HTML.

Les récents travaux faits sur un éditeur visuel pour MediaWiki on rendu nécessaire l'amélioration du processus d'analyse syntaxique (et le rendre plus rapide); le travail s'est donc résumé à l'analyseur syntaxique et les couches intermédiaires entre le balisage MediaWiki et le HTML final (voir Futur, ci-dessous).

Mots magiques et modèles

MediaWiki offre les Mots magiques qui modifient le comportement général de la page ou qui incluent du contenu dynamique à l'intérieur. Ils sont constitués : de commutateurs de comportement comme __NOTOC__ (pour cacher le sommaire automatique) ou __NOINDEX__ (pour dire aux moteurs de recherche de ne pas indexer la page); de variables comme {{CURRENTTIME}} ou {{SITENAME}}; et de fonctions d'analyse syntaxique, par exemple les mots magiques acceptant des paramètres, comme {{lc:[string]}} (pour produire [string] en minuscules). Les constructions comme {{GENDER:}}, {{PLURAL:}} et {{GRAMMAR:}}, utilisées pour traduire l'interface utilisateur, sont des fonctions de l'analyseur.

La manière la plus habituelle d'inclure du contenu venant d'autres pages, dans une page MediaWiki, est d'utiliser des modèles. Les modèles étaient vraiment destinés à être utilisés pour inclure le même contenu sur différentes pages, par exemple les panneaux de navigation ou les bannières de maintenance sur les articles Wikipedia; avoir la capacité de créer des affichages de pages partiels et les réutiliser dans des milliers d'articles avec une maintenance centrale a eu un impact énorme sur des sites comme Wikipedia.

Cependant, les modèles ont également été utilisés (quelques fois trop) par les utilisateurs à des fins complètement différentes. MediaWiki 1.3 a permis aux modèles d'accepter des paramètres qui modifient leur sortie; la possibilité d'ajouter un paramètre par défaut (introduit dans MediaWiki 1.6) a permis la construction d'un langage de programmation fonctionnel implémenté au-dessus de PHP, et cela a finalement été une des fonctionnalités les plus coûteuses en termes de performances.

Tim Starling a ensuite développé des fonctions d'analyse supplémentaires (l'extension ParserFunctions), pour éviter le décalage par rapport aux constructions folles créées par les utilisateurs de Wikipedia avec les modèles. Cet ensemble de fonctions comprenait les structures logiques telles que #if et #switch, et d'autres fonctions comme #expr (pour évaluer des expressions mathématiques) et #time (pour formater le temps).

Très tôt déjà, les utilisateurs de Wikipedia ont commencé à créer des modèles encore plus complexes qui utilisaient les nouvelles fonctions, ce qui a considérablement dégradé les performances d'analyse des pages qui importaient de nombreux modèles. Le nouveau pré-processeur introduit dans MediaWiki 1.12 (modification majeure de l'architecture) a été implémenté pour remédier partiellement à ce problème. Ultérieurement les développeurs MediaWiki ont discuté de la possibilité d'utiliser un langage de script actuel pour améliorer les performances. Extension:Scribunto a été ajouté en février 2013.

Fichiers multimédia

Les utilisateurs téléversent les fichiers via la page Special:Upload; les administrateurs peuvent configurer les types de fichiers autorisés au téléversement via une liste blanche d'extension. Une fois téléversés, les fichiers sont rangés dans un répertoire du système de fichiers et les vignettes sont mises dans un répertoire dédié thumb.

En raison de la mission éducative de Wikimedia, MediaWiki prend en charge les types de fichiers qui peuvent être rares dans d'autres applications web ou CMS, comme les images vectorielles SVG, et les PDF et DjVus à plusieurs pages. Ils sont rendus en tant que fichiers PNG, et peuvent être présentés en ligne sous forme de vignette comme la plupart des fichiers d'images GIF, JPG et PNG.

Lorsqu'un fichier est téléversé, il lui est attribué une page File: contenant les informations entrées par le téléchargeur; il s'agit d'un texte libre, qui comprend généralement des informations sur les droits d'auteur (auteur, licence) et des éléments décrivant ou classant le contenu du fichier (description, emplacement, date, catégories, etc.). Bien que les wikis privés ne se soucient peut-être pas beaucoup de ces informations, sur les bibliothèques multimédias comme Wikimedia Commons, elles sont essentielles pour organiser la collection et assurer la légalité du partage de ces fichiers. On a reproché à la plupart de ces métadonnées de ne pas avoir été mises dans une structure interrogeable comme une table de base de données. Cela faciliterait considérablement la recherche, mais aussi l'attribution et la réutilisation par des tiers — par exemple, via l'API.

La plupart des sites Wikimedia permettent également de téléverser localement sur chaque wiki mais la communauté essaie de ranger les fichiers média sous licence libre dans la bibliothèque libre des médias de Wikimedia nommée Wikimedia Commons. Tout site Wikimedia peut afficher un fichier hébergé sur Commons comme si il était hébergé localement. Cette personnalisation évite d'avoir à téléverser un fichier sur chaque wiki afin de pouvoir l'utiliser.

En conséquence, MediaWiki prend en charge nativement les dépôts des médias étrangers, c'est-à-dire la possibilité d'accéder aux fichiers multimédias hébergés sur un autre wiki via son API et le système ForeignAPIRepo. Depuis la version 1.16, tout site web MediaWiki peut facilement utiliser les fichiers de Wikimedia Commons via la fonctionnalité InstantCommons. Lorsque l'on utilise un dépôt externe, les vignettes sont stockées localement pour économiser sur la largeur de bande. Cependant, il n'est pas encore possible de téléverser sur un référentiel de médias externe à partir d'un autre wiki.

Personnalisation et extension de MediaWiki

Niveaux

L'architecture de MediaWiki offre différentes façons de personnaliser et d'étendre le logiciel. Cela peut être fait à différents niveaux d'accès :

• Les administrateurs système peuvent installer les extensions et les habillages et configurer séparément les différents programmes d'aide (par exemple pour la création de vignettes d'images et la génération de formules TeX) et des paramètres globaux (voir Configuration ci-dessus).
• Les opérateurs système (sysops, appelés aussi quelques fois administrateurs) des wikis peuvent mettre à jour les gadgets du site, et les paramètres JavaScript et CSS.
• Tout utilisateur enregistré peut personnaliser sa propre expérience et son interface en utilisant ses préférences (pour les paramètres existants, les habillages et les gadgets) ou faire ses propres modifications (en utilisant ses propres pages JS et CSS). Les programmmes externes peuvent aussi communiquer avec MediaWiki au travers de ses API machine si elles sont activées, principalement en rendant toutes les fonctionnalités et les données accessibles aux utilisateurs.

JavaScript et CSS

MediaWiki peut lire et appliquer du JavaScript et du CSS sur l'ensemble du site ou des habillages en utilisant des pages wiki personnalisées; ces pages se trouvent dans l'espace de noms MediaWiki:, et ne peuvent donc être éditées que par les administrateurs système ; par exemple, les modifications JavaScript de MediaWiki:Common.js s'appliquent à toutes les habillages, le CSS de MediaWiki:Common.css s'applique à toutes les habillages, mais MediaWiki:Vector.css ne s'applique qu'aux utilisateurs ayant l'habillage Vector.

Les utilisateurs peuvent effectuer les mêmes types de modifications, qui ne s'appliqueront qu'à leur propre interface, en éditant les sous-pages de leur page utilisateur (par exemple, User:[Username]/common.js pour le JavaScript sur tous les habillages, User:[Username]/common.css pour le CSS sur tous les habillages, ou User:[Username]/vector.css pour les modifications CSS qui s'appliquent uniquement à l'habillage Vector).

Si l'extension Gadgets est installée, les administrateurs système peuvent également modifier les gadgets, c'est-à-dire des extraits de code JavaScript fournissant des fonctionnalités qui peuvent être activées et désactivées par les utilisateurs dans leurs préférences. Les prochains développements sur les gadgets permettront de partager ces derniers au travers des wikis, évitant ainsi la duplication.

Cet ensemble d'outils a eu un impact énorme et a considérablement augmenté la démocratisation du développement du logiciel MediaWiki. Les utilisateurs individuels sont habilités à ajouter des fonctionnalités pour eux-mêmes; les utilisateurs avancés peuvent les partager avec d'autres, à la fois de manière informelle ou via des systèmes configurables globalement par les administrateurs systèmes. Cet environnement est idéal pour les petites modifications autonomes et reste un frein plus faible que les modifications du code, plus lourdes, effectuées par les accroches et les extensions.

Extensions et habillages

Si les adaptations JavaScript et CSS ne suffisent pas, MediaWiki fournit un système d'accroches pour permettre aux développeurs tiers d'exécuter du code PHP personnalisé avant, après, ou à la place du code MediaWiki sur un événement particulier. Les extensions MediaWiki utilisent les accroches pour s'insérer dans le code.

Avant que les accroches n'existent dans MediaWiki, l'ajout de code PHP personnalisé signifiait modifier le code de base, ce qui n'était ni facile ni recommandé. Les premières accroches ont été proposées et ajoutées en 2004 par Evan Prodromou; beaucoup d'autres ont été ajoutées par la suite au fil des besoins. Par l'intermédiaire des accroches, il est même possible d'étendre le balisage des wikis MediaWiki avec des possibilités supplémentaires, en utilisant l'extension des balises.

Le système d'extension n'est pas parfait : l'enregistrement des extensions est basé sur l'exécution du code au démarrage, plutôt que sur des données en cache, ce qui limite l'abstraction et l'optimisation et nuit aux performances de MediaWiki. Mais globalement, l'architecture des extensions est maintenant une infrastructure assez flexible qui a contribué à rendre le code spécialisé plus modulaire, empêchant le logiciel du noyau de se développer (trop) et facilitant aux utilisateurs tiers la création de fonctionnalités personnalisées par-dessus MediaWiki.

À l'inverse, il est très difficile d'écrire un nouvel habillage pour MediaWiki sans réinventer la roue. Dans MediaWiki, les habillages sont des classes PHP qui étendent chacune la classe mère Skin; elles contiennent des fonctions qui recueillent les informations nécessaires pour générer le HTML. L'habillage MonoBook qui a longtemps persisté était difficile à personnaliser car il contenait beaucoup de CSS spécifique au navigateur pour prendre en charge les anciens navigateurs; la modification du modèle ou du CSS nécessitait de nombreuses reprises ultérieures pour refléter le changement sur tous les navigateurs et les plateformes.

API

L'autre point d'accès principal pour MediaWiki, en plus de index.php est api.php, utilisé pour accéder à son interface de programmation d'application (API — Application Programming Interface) de requête en lecture par la machine.

Les utilisateurs de Wikipedia ont initialement créé des robots qui travaillaient sur le contenu HTML des écrans générés par MediaWiki; cette méthode n'était pas très fiable et échouait régulièrement. Pour améliorer cette situation, les développeurs ont introduit une interface de lecture uniquement (située sur query.php), qui a ensuite évolué en une API de machine en lecture et écriture fournissant un accès direct et de haut niveau aux données contenues dans la base de données MediaWiki.

Les programmes client peuvent utiliser l'API pour se connecter, obtenir des données et publier des modifications. L'API prend en charge les clients JavaScript légers basés sur le web et les applications des utilisatuers finaux. Presque tout ce qui peut être fait via l'interface web peut être fait via l'API. Les bibliothèques clientes qui implémentent l'API MediaWiki sont disponibles dans de nombreux langages y compris .NET et Python.

Couches, domaines et modèles

Page principale : Architecture:MediaWiki

MediaWiki peut être divisé en 12 couches techniques environ, dont chacune appelle des classes et du code appartenant à la couche qui se trouve sous elle et non pas dans celle qui est au-dessus. Les exemples incluent la couche installation , la couche du point d'accès , la couche de cablage , et la couche de l'API . Du code qui s'étend sur toutes les couches peut être groupé dans environs 21 modules de domaines , avec des exemples qui incluent le domaine de navigation (les habillages), le domaine de gestion des utilisateurs (create, rename, login), et le domaine d'internationalisation . Beaucoup de modèles de conception logiciels sont utilisés dans MediaWiki, y compris les modèles des fabriques , les modèles des gestionnaires , et les modèles des commandes .

Futur

Ce qui a commencé comme un projet d'été réalisé par un seul développeur PHP bénévole est devenu dans MediaWiki, un moteur mature et stable du wiki qui alimente un site web classé parmi les dix premiers sites avec une infrastructure opérationnelle ridiculesement petite. Cela a été rendu possible par une optimisation constante des performances, des changements architecturaux itératifs et grâce à une équipe de développeurs merveilleux.

L'évolution des technologies web et la croissance de Wikipédia nécessitent des améliorations continues et de nouvelles fonctionnalités, dont certaines appellent à des changements majeurs dans l'architecture de MediaWiki. C'est le cas, par exemple, du projet en cours de l'éditeur visuel, qui a incité à renouveler les travaux sur l'analyseur syntaxique et sur le langage de marquage du wiki, le DOM et la conversion finale en HTML.

MediaWiki est un outil utilisé à des fins variées. Dans les projets Wikimedia, par exemple, il est utilisé pour créer et maintenir une encyclopédie (Wikipedia), pour alimenter une énorme bibliothèque multimédia (Wikimedia Commons) ou pour transcrire des textes de référence scannés (Wikisource); et autres. Dans d'autres contextes, MediaWiki est utilisé comme un CMS d'entreprise ou un dépôt de données, combiné quelques fois à un environnement sémantique. Ces utilisations particulières pour lesquelles il n'y a pas eu de planification vont probablement continuer à diriger les évolutions constantes de la structure interne du logiciel. En tant que tel, l'architecture de MediaWiki reste très vivante, tout comme l'immense communauté des utilisateurs qu'elle supporte.

Lectures complémentaires

• Documentation MediaWiki et support : https://www.mediawiki.org
• Documentation MediaWiki générée automatiquement : https://doc.wikimedia.org
• Domas Mituzas, Wikipedia: variables internes de site, paramètres, exemples de code et problèmes de gestion, conférence des utilisateurs MySQL, 2007. Texte complet disponible sur http://dom.as/talks/
• Faidon Liambotis, L'infrastructure de Wikimedia, dotScale 2014. (vidéo YouTube)

Voir aussi

• Comment devenir un hackeur de MediaWiki
• Manual:Architectural modules