Manual:MediaWiki architecture/fr

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.



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  de MediaWiki doit être renommée en   pour être compatible avec PHP 5.3. L'utilisation d'une manière cohérente d'un préfixe pour toutes les classes (comme " ") 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,  , et  , la classe   et la hiérarchie de la classe  ,  , et la hiérarchie de. 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, 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. MediaWiki fournit également (et utilise) un nettoyeur HTML avec la classe, 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, mais l'administrateur système peut réécraser ces valeurs en mettant à jour.

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  (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


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,  ,  , et  ). Les autres tables contiennent les données relatives aux utilisateurs, aux fichiers de médias , à gestion du cache et aux outils internes (  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.



Dans le modèle 1.4, le contenu était stocké dans deux tables importantes,  (contenant le texte et les métadonnées de la version actuelle de la page) et   (contenant les versions antérieures); les pages supprimées était gardées dans. Lorsqu'une modification était faite, la version antépénultième était recopiée dans la table, et la nouvelle modification était sauvegardée dans. 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, ce qui pouvait prendre un certain temps. Lorsqu'une page était supprimée, ses entrées dans les deux tables  et   devaient être copiées dans la table   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  et   ont été remplacées par   (métadonnées des pages),   (métadonnées de toutes les versions, anciennes ou actuelles) et   (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  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  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 , 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  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
est 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  réalise les contrôles de sécurité, charge les paramètres de configuration par défaut de , devine la configuration avec  , et applique les paramètres du site contenus dans. Ensuite il instancie un objet  object, et crée un objet    qui dépend du titre et des paramètres de l'action contenue dans les paramètres de la requête.

peut prendre une variété de paramètres d'action dans l'URL de la requête; l'action par défaut est, qui affiche la vue habituelle du contenu d'un article. Par exemple la requête  affiche le contenu de l'article « Apple » de la Wikipedia anglophone. . Les autres actions fréquentes incluent  (ouvrir un article pour le  modifier),   (afficher ou enregistrer un article),   (afficher l'historique d'un article) et   (ajouter un article à la liste de suivi de l'utilisateur). Les actions administratives comprennent  (pour supprimer un article) et   (pour empêcher de modifier un article).

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, pour créer des objets   pour la page , puis pour   qui gère les actions standard. Un fois l'action terminée,  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. 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 ),   est appelé à la place de  ; 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  et   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. Wikimedia's caching infrastructure has imposed limitations in MediaWiki; developers worked around the issues, not by trying to shape Wikimedia's extensively optimised caching infrastructure around MediaWiki, but rather by making MediaWiki more flexible, so it could work within that infrastructure, without compromising on performance and caching needs.

On Wikimedia sites, most requests are handled by reverse caching proxies (Squids), and never even make it to the MediaWiki application servers. Squids contain static versions of entire rendered pages, served for simple reads to users who aren't logged in to the site. MediaWiki natively supports Squid and Varnish, and integrates with this caching layer by, for example, notifying them to purge a page from the cache when it has been changed. For logged-in users, and other requests that can't be served by Squids, Squid forwards the requests to the web server (Apache).

The second level of caching happens when MediaWiki renders and assembles the page from multiple objects, many of which can be cached to minimise future calls. 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. The in-memory object cache has been available in MediaWiki since the early 1.1 version (2003), and is particularly important to avoid re-parsing long and complex pages.

Login session data can also be stored in memcached, which lets sessions work transparently on multiple front-end web servers in a load-balancing setup (Wikimedia heavily relies on load balancing, using LVS with PyBal).

Since version 1.16, MediaWiki uses a dedicated object cache for localised UI text; this was added after noticing that a large part of the objects cached in memcached consisted of UI messages localised into the user's language. 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. CDBs minimise memory overhead and start-up time in the typical case; they're also used for the interwiki cache.

The last caching layer consists of the PHP opcode cache, commonly enabled to speed up PHP applications. Compilation can be a lengthy process; to avoid compiling PHP scripts into opcode every time they're invoked, a PHP accelerator can be used to store the compiled opcode and execute it directly without compilation. MediaWiki va fonctionner simplement avec beaucoup d'accélérateurs tels que APC, l'accélérateur PHP...

Because of its Wikimedia bias, MediaWiki is optimised for this complete, multi-layer, distributed caching infrastructure. Nonetheless, it also natively supports alternate setups for smaller sites. For example, it offers an optional simplistic file caching system that stores the output of fully rendered pages, like Squid does. Also, MediaWiki's abstract object caching layer lets it store the cached objects in several places, including the file system, the database, or the opcode cache.

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. Usability efforts initiated in 2008, as well as advanced media handling (e.g. online editing of video files), called for dedicated front-end performance improvements.

To optimise the delivery of JavaScript and CSS assets, the ResourceLoader module was developed. 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


Contexte et justification
A central part of effectively contributing and disseminating free knowledge to all is to provide it in as many languages as possible. 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. Because Wikipedia and its sister sites exist in so many languages, it is important not only to provide the content in the readers' native language, but also to provide a localised interface, and effective input and conversion tools, so that participants can contribute content.

Pour cette raison, la localisation et l'internationalisation (l10n et i18n) sont un composant central de MediaWiki. The i18n system is pervasive, and impacts many parts of the software; it's also one of the most flexible and feature-rich. 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. The interface and content can be in different languages, and can have mixed directionality.



Langue du contenu
MediaWiki originally used per-language encoding, which led to a lot of issues; for example, foreign scripts could not be used in page titles. UTF-8 a été choisi à la place. Support for character sets other than UTF-8 was dropped in 2005, along with the major database schema change in MediaWiki 1.5; content must now be encoded in UTF-8.

Characters not available on the editor's keyboard can be customised and inserted via MediaWiki's, an interface message that appears below the edit window; its JavaScript version automatically inserts the character clicked into the edit window. The extension for MediaWiki, developed as part of a usability effort, merges special characters with the edit toolbar. Another extension, called, provides additional input methods and key mapping features for non-ASCII characters.

Recent and future improvements include better support for right-to-left text, bidirectional text (LTR and RTL text on the same page) and.



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. Keys are determined by developers, who are encouraged to use prefixes for extensions; for example, message keys for the UploadWizard extension will start with, where   stands for MediaWiki extension.

MediaWiki messages can embed parameters provided by the software, which will often influence the grammar of the message. In order to support virtually any possible language, MediaWiki's localisation system has been improved and complexified over time to accommodate their specific traits and exceptions, often considered oddities by English speakers.

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. If the user profile has gender preferences set, the  switch can be used in interface messages to appropriately address them (more info). Other switches include, for "simple" plurals and languages like Arabic with dual, trial or paucal numbers, and  , providing grammatical transformation functions for languages like Finnish whose grammatical cases cause alterations or inflections.

The gender distinction can also be used in gender-dependent user namespace names, so that the title and URL of the page refers to the user correctly. Standard MediaWiki namespaces' gender variants are defined via  in each language's MessagesXx.php, while  can be used for wiki-specific namespaces. As of, 13 languages use this feature by default:





Internationaliser les messages
Localised interface messages for MediaWiki reside in  files, where   is the ISO-639 code of the language (e.g.   for French); default messages are in English and stored in. MediaWiki extensions use a similar system, or host all localised messages in an file. Along with translations, Message files also include language-dependent information such as date formats.

Contributing translations used to be done by submitting PHP patches for the  files. In December 2003, MediaWiki 1.1 introduced "database messages", a subset of wiki pages in the MediaWiki namespace containing interface messages. The content of the wiki page is the message's text, and overrides its value in the PHP file. Localised versions of the message are at, e.g..

This feature has allowed power users to translate (and customise) interface messages locally on their wiki, but the process doesn't update i18n files shipping with MediaWiki. In 2006, Niklas Laxström created a special, heavily hacked MediaWiki website (now hosted at ) where translators can easily localise interface messages in all languages, simply by editing a wiki page. The  files are then updated in the MediaWiki code repository, where they can be automatically fetched by any wiki, and updated using the LocalisationUpdate extension. On Wikimedia sites, database messages are now only used for customisation, and not for localisation any more. Les extensions MediaWiki et certains programmes associés tels que les robots, sont aussi traduits sur translatewiki.net.

To help translators understand the context and meaning of an interface message, it is considered a good practice in MediaWiki to provide documentation for every message. Cette documentation est stockée dans un fichier de message spécial, avec le code de langue  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. Another helpful tool is the  language code: when used with the   parameter to display a wiki page (e.g.  ), MediaWiki will display the message keys instead of their values in the user interface; this is very useful to identify which message to translate or change.

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 also supports fallback languages: if a message isn't available in the chosen language, it will be displayed in the closest possible language, and not necessarily in English. Par exemple la langue de repli pour le breton est le français.

Utilisateurs
Users are represented in the code using instances from the  class, which encapsulates all of the user-specific settings (user id, name, rights, password, email address, etc.). Client classes use accessors to access these fields; they do all the work of determining whether the user is logged in, and whether the requested option can be satisfied from cookies or whether a database query is needed. Most of the settings needed for rendering normal pages are set in the cookie to minimise use of the database.

MediaWiki provides a very granular permissions system, with basically a user permission for every possible action. For example, to perform the "Rollback" action (i.e. to "quickly rollback the edits of the last user who edited a particular page"), a user needs the  permission, included by default in MediaWiki's   user group. But it can also be added to other user groups, or have a dedicated user group only providing this permission (this is the case on the English Wikipedia, with the  group). Customisation of user rights is done by editing the  array in  ; for instance,   allows all registered users to rename files. A user can belong to several groups, and inherits the highest rights associated with each of them.

However, MediaWiki's user permissions system was really designed with Wikipedia in mind, i.e. a site whose content is accessible to all, and only certain actions are restricted to some users. MediaWiki lacks a unified, pervasive permissions concept; it doesn't provide traditional CMS features like restricting read or write access by namespace, category, etc. Seules quelques extensions MediaWiki fournissent de telles fonctionnalités jusqu'à un certain point.

Contenu


Structure du contenu
The concept of namespaces was used in the UseModWiki era of Wikipedia, where talk pages were at the title "". Namespaces were formally introduced in Magnus Manske's first "PHP script". They were reimplemented a few times over the years, but have kept the same function: to separate different kinds of content. They consist of a prefix, separated from the page title by a colon (e.g.  or   and  ); the main content namespace has no prefix. Wikipedia users quickly adopted them, and they provided the community with different spaces to evolve. Namespaces have proven to be an important feature of MediaWiki, as they create the necessary preconditions for a wiki's community and set up meta-level discussions, community processes, portals, user profiles, etc.

The default configuration for MediaWiki's main content namespace is to be flat (no subpages), because it's how Wikipedia works, but it is trivial to enable them. They are enabled in other namespaces (e.g., where people can for instance work on draft articles) and display breadcrumbs.

Namespaces separate content by type; within a same namespace, pages can be organised by topic using categories, a pseudo-hierarchical organisation scheme introduced in MediaWiki 1.3.



Traitement du contenu : langage de balisage MediaWiki et analyseur syntaxique
The user-generated content stored by MediaWiki isn't in HTML, but in a markup language specific to MediaWiki, sometimes called "wikitext". It allows users to make formatting changes (e.g. bold, italic using quotes), add links (using square brackets), include templates, insert context-dependent content (like a date or signature), and make an incredible number of other magical things happen.

To display a page, this content needs to be parsed, assembled from all the external or dynamic pieces it calls, and converted to proper HTML. The parser is one of the most essential parts of MediaWiki, which also makes it difficult to change or improve. Because hundreds of millions of wiki pages worldwide depend on the parser to continue outputting HTML the way it always has, it has to remain extremely 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é en fonction des besoins. For example, the usage of a ThreadMode format for discussions made Magnus Manske implement the 3 or 4 tildes ( ~ ) as a shortcut to sign one's posts in unstructured text. Tildes were chosen as it resembled his father's hand-written signature.

In the absence of a formal specification, the MediaWiki markup language has become a complex and idiosyncratic language, basically only compatible with MediaWiki's parser; it can't be represented as a formal grammar using BNF, EBNF or ANTLR syntaxes. The current parser's specification is jokingly referred to as "whatever the parser spits out from wikitext, plus a few hundred test cases".

Plusieurs tentatives sont été faites avec des analyseurs parallèles mis aucune n'est allée aussi loin. In 2004, an experimental tokeniser was written by Jens Frank to parse wikitext, and enabled on Wikipedia; it had to be disabled three days later, because of the poor performance of PHP array memory allocations. Since then, most of the parsing has been done with a huge pile of regular expressions, and a ton of helper functions. The wiki markup, and all the special cases the parser needs to support, have also become considerably more complex, making future attempts even more difficult.

A notable improvement was Tim Starling's preprocessor rewrite in MediaWiki 1.12, whose main motivation was to improve the parsing performance on pages with complex templates. The preprocessor converts wikitext to an XML DOM tree representing parts of the document (template invocations, parser functions, tag hooks, section headings, and a few other structures), but can skip "dead branches" in template expansion, such as unfollowed  cases and unused defaults for template arguments. L'analyseur itère ensuite en parcourant la structure DOM et convertit son contenu en HTML.

Recent work on a visual editor for MediaWiki has made it necessary to improve the parsing process (and make it faster), so work has resumed on the parser and intermediate layers between MediaWiki markup and final HTML (see Future, below).



Mots magiques et modèles
MediaWiki offers "Magic words" that modify the general behaviour of the page or include dynamic content into it. They consist of: behaviour switches like  (to hide the automatic table of content) or   (to tell search engines not to index the page); variables like   or  ; and parser functions, i.e. magic words that can take parameters, like   (to output   in lowercase). Constructs like,   and  , used to localise the UI, are parser functions.

The most common way to include content from other pages in a MediaWiki page is to use templates. Templates were really intended to be used to include the same content on different pages, e.g. navigation panels or maintenance banners on Wikipedia articles; having the ability to create partial page layouts and reuse them in thousands of articles with central maintenance made a huge impact on sites like Wikipedia.

However, templates have also been used (and abused) by users for a completely different purpose. MediaWiki 1.3 made it possible for templates to take parameters that change their output; the ability to add a default parameter (introduced in MediaWiki 1.6) enabled the construction of a functional programming language implemented on top of PHP, which was ultimately one of the most costly features in terms of performance.

Tim Starling then developed additional parser functions (the ParserFunctions extension), as a stopgap measure against insane constructs created by Wikipedia users with templates. This set of functions included logical structures like  and , and other functions like   (to evaluate mathematical expressions) and   (for time formatting).

Soon enough, Wikipedia users started to create even more complex templates using the new functions, which considerably degraded the parsing performance on template-heavy pages. The new preprocessor introduced in MediaWiki 1.12 (a major architectural change) was implemented to partly remedy this issue. Later, MediaWiki developers discussed the possibility of using an actual scripting language to improve performance. was added in February of 2013.



Fichiers multimédia
Users upload files through the  page; administrators can configure the allowed file types through an extension whitelist. Once uploaded, files are stored in a folder on the file system, and thumbnails in a dedicated  directory.

Because of Wikimedia's educational mission, MediaWiki supports file types that may be uncommon in other web applications or CMSes, like SVG vector images, and multipage PDFs & DjVus. They are rendered as PNG files, and can be thumbnailed and displayed inline, as are more common image files like GIFs, JPGs and PNGs.

When a file is uploaded, it is assigned a  page containing information entered by the uploader; this is free text, which usually includes copyright information (author, license) and items describing or classifying the content of the file (description, location, date, categories, etc.). While private wikis may not care much about this information, on media libraries like Wikimedia Commons they are critical to organise the collection and ensure the legality of sharing these files. It has been argued that most of these metadata should, in fact, be stored in a queryable structure like a database table. This would considerably facilitate search, but also attribution and reuse by third parties — for example, through the API.

Most Wikimedia sites also allow "local" uploads to each wiki, but the community tries to store freely-licensed media files in Wikimedia's free media library, Wikimedia Commons. Any Wikimedia site can display a file hosted on Commons as if it were hosted locally. This custom avoids having to upload a file to every wiki to use it there.

As a consequence, MediaWiki natively supports foreign media repositories, i.e., the ability to access media files hosted on another wiki through its API and the  system. Since version 1.16, any MediaWiki website can easily use files from Wikimedia Commons through the  feature. When using a foreign repository, thumbnails are stored locally to save bandwidth. However, it is not (yet) possible to upload to a foreign media repository from another wiki.



Niveaux
MediaWiki's architecture provides different ways to customise and extend the software. This can be done at different levels of access:


 * System administrators can install extensions and skins, and configure the wiki's separate helper programs (e.g. for image thumbnailing and TeX rendering) and global settings (see Configuration above).
 * Wiki sysops (sometimes called "administrators" too) can edit site-wide gadgets, JavaScript and CSS settings.
 * Any registered user can customise their own experience and interface using their preferences (for existing settings, skins and gadgets) or make their own modifications (using their personal JS and CSS pages). External programs can also communicate with MediaWiki through its machine API, if it's enabled, basically making any feature and data accessible to the user.



JavaScript et CSS
MediaWiki can read and apply site-wide or skin-wide JavaScript and CSS using custom wiki pages; these pages are in the  namespace, and thus can only be edited by sysops; for example, JavaScript modifications from   apply to all skins, CSS from   applies to all skins, but   only applies to users with the Vector skin.

Users can do the same types of changes, which will only apply to their own interface, by editing subpages of their user page (e.g.  for JavaScript on all skins,   for CSS on all skins, or   for CSS modifications that only apply to the Vector skin).

If the Gadgets extension is installed, sysops can also edit gadgets, i.e. snippets of JavaScript code providing features that can be turned on and off by users in their preferences. Upcoming developments on gadgets will make it possible to share gadgets across wikis, thus avoiding duplication.

This set of tools has had a huge impact and greatly increased the democratisation of MediaWiki's software development. Individual users are empowered to add features for themselves; power users can share them with others, both informally and through globally-configurable sysop-controlled systems. This framework is ideal for small, self-contained modifications, and presents a lower barrier of entry than heavier code modifications done through hooks and extensions.



Extensions et habillages
When JavaScript and CSS modifications are not enough, MediaWiki provides a system of hooks that let third-party developers run custom PHP code before, after, or instead of MediaWiki code for particular events. MediaWiki extensions use hooks to plug into the code.

Before hooks existed in MediaWiki, adding custom PHP code meant modifying the core code, which was neither easy nor recommended. The first hooks were proposed and added in 2004 by Evan Prodromou; many more have been added over the years when needed. Using hooks, it is even possible to extend MediaWiki's wiki markup with additional capabilities, using tag extensions.

The extension system isn't perfect: extension registration is based on code execution at startup, rather than cacheable data, which limits abstraction and optimisation and hurts MediaWiki's performance. But overall, the extension architecture is now a fairly flexible infrastructure that has helped make specialised code more modular, keeping the core software from expanding (too) much, and making it easier for third-party users to build custom functionality on top of MediaWiki.

Conversely, it's very difficult to write a new skin for MediaWiki without reinventing the wheel. In MediaWiki, skins are PHP classes each extending the parent  class; they contain functions that gather the information needed to generate the HTML. The long-lived "MonoBook" skin was difficult to customise because it contained a lot of browser-specific CSS to support old browsers; editing the template or CSS required many subsequent changes to reflect the change for all browsers and platforms.

API
The other main access point for MediaWiki, besides, is  , used to access its machine-readable query API (Application Programming Interface).

Wikipedia users originally created "bots" that worked by screen scraping the HTML content served by MediaWiki; this method was very unreliable and broke many times. To improve this situation, developers introduced a read-only interface (located at ), which then evolved into a full-fledged read and write machine API providing direct, high-level access to the data contained in the MediaWiki database.

Client programs can use the API to login, get data, and post changes. The API supports thin web-based JavaScript clients and end-user applications. Almost anything that can be done via the web interface can basically be done through the API. Client libraries implementing the MediaWiki API are available in many languages, including Python and .NET.

Layers, domains, and patterns
MediaWiki can be divided into around 12 technical layers, with each layer calling classes and code in the layer beneath it but not above it. Examples include the installer layer, entry point layer, wiring layer, and API layer. Code spanning all the layers can be grouped into around 21 domain modules, with examples including the navigation domain (skins), user management domain (create, rename, login), and internationalisation domain. Many software design patterns are used in MediaWiki, including the factory pattern, handler pattern, and command pattern.

Futur
What started as a summer project done by a single volunteer PHP developer has grown into MediaWiki, a mature, stable wiki engine powering a top-ten website with a ridiculously small operational infrastructure. This has been made possible by constant optimisation for performance, iterative architectural changes and a team of awesome developers.

The evolution of web technologies, and the growth of Wikipedia, call for ongoing improvements and new features, some of which require major changes to MediaWiki's architecture. This is, for example, the case for the ongoing visual editor project, which has prompted renewed work on the parser and on the wiki markup language, the DOM and final HTML conversion.

MediaWiki is a tool that is used for varied purposes. Within Wikimedia projects, for instance, it's used to create and curate an encyclopedia (Wikipedia), to power a huge media library (Wikimedia Commons) or to transcribe scanned reference texts (Wikisource); and so on. In other contexts, MediaWiki is used as a corporate CMS, or as a data repository, sometimes combined with a semantic framework. These specialised uses that weren't planned for will probably continue to drive constant adjustments to the software's internal structure. As such, MediaWiki's architecture is very much alive, just like the immense community of users it supports.

<span id="Notes_and_references">

Notes et références
<span id="Further_reading">

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: site internals, configuration, code examples and management issues, MySQL Users conference, 2007. Full text available at http://dom.as/talks/
 * Faidon Liambotis, L'infrastructure de Wikimedia, dotScale 2014. (vidéo YouTube)

<span id="See_also">

Voir aussi

 * How to become a MediaWiki hacker
 * Manual:Architectural modules