Manuel:Architecture de MediaWiki

This page is a translated version of the page Manual:MediaWiki architecture and the translation is 61% complete.
Outdated translations are marked like this.
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 chapître 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 chapître 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.[1]. 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. 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.

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

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

Page principale : Manual:Language

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. L'interface et le contenu peuvent être dans des langues différentes et mixer des directionnalités différentes.

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 Edittools, an interface message that appears below the edit window; its JavaScript version automatically inserts the character clicked into the edit window. The WikiEditor extension for MediaWiki, developed as part of a usability effort, merges special characters with the edit toolbar. Another extension, called UniversalLanguageSelector , 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 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. Keys are determined by developers, who are encouraged to use prefixes for extensions; for example, message keys for the UploadWizard extension will start with mwe-upwiz-, where mwe stands for MediaWiki extension.

Les messages MediaWiki peuvent contenir des paramètres fournis par le logiciel ce qui influencera souvent la grammaire du 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 {{GENDER:}} switch can be used in interface messages to appropriately address them (more info). Other switches include {{PLURAL:}}, for "simple" plurals and languages like Arabic with dual, trial or paucal numbers, and {{GRAMMAR:}}, providing grammatical transformation functions for languages like Finnish whose grammatical cases cause alterations or inflections.

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. Standard MediaWiki namespaces' gender variants are defined via $namespaceGenderAliases in each language's MessagesXx.php, while $wgExtraGenderNamespaces can be used for wiki-specific namespaces. 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 : Help:System message

Localised interface messages for MediaWiki reside in MessagesXx.php files, where Xx is the ISO-639 code of the language (e.g. MessagesFr.php for French); default messages are in English and stored in MessagesEn.php. MediaWiki extensions use a similar system, or host all localised messages in an [Extension-name].i18n.php 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 MessagesXx.php 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 MediaWiki:[Message-key] is the message's text, and overrides its value in the PHP file. Localised versions of the message are at MediaWiki:[Message-key]/[language-code], e.g. MediaWiki:Rollbacklink/de.

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 translatewiki.net) where translators can easily localise interface messages in all languages, simply by editing a wiki page. The MessagesXx.php files are then updated in the MediaWiki code repository, where they can be automatically fetched by any wiki. 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 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. Another helpful tool is the qqx language code: when used with the &uselang parameter to display a wiki page (e.g. en.wikipedia.org/wiki/Special:RecentChanges?uselang=qqx), 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.

 
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 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 User 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 rollback permission, included by default in MediaWiki's sysop 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 Rollbackers group). Customisation of user rights is done by editing the $wgGroupPermissions array in LocalSettings.php; for instance, $wgGroupPermissions['user']['movefile'] = true; 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 "[article name]/Talk". 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. Talk: or File: and Template:); 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. User:, 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. Les tildes ont été choisi pour ressembler à la signature manuscrite de son père.[2][3]

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 #switch 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 offre les Mots magiques qui modifient le comportement général de la page ou qui incluent du contenu dynamique à l'intérieur. They consist of: behaviour switches like __NOTOC__ (to hide the automatic table of content) or __NOINDEX__ (to tell search engines not to index the page); variables like {{CURRENTTIME}} or {{SITENAME}}; and parser functions, i.e. magic words that can take parameters, like {{lc:[string]}} (to output [string] in lowercase). 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. 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 #if and #switch, and other functions like #expr (to evaluate mathematical expressions) and #time (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. Extension:Scribunto a été ajouté en février 2013.

Fichiers multimédia

Users upload files through the Special:Upload 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 thumb 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 File: 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 ForeignAPIRepo system. Since version 1.16, any MediaWiki website can easily use files from Wikimedia Commons through the InstantCommons 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.

Personnalisation et extension de MediaWiki

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).
  • 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.
  • 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 MediaWiki: namespace, and thus can only be edited by sysops; for example, JavaScript modifications from MediaWiki:Common.js apply to all skins, CSS from MediaWiki:Common.css applies to all skins, but MediaWiki:Vector.css 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. User:[Username]/common.js for JavaScript on all skins, User:[Username]/common.css for CSS on all skins, or User:[Username]/vector.css 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. Les extensions MediaWiki utilisent les accroches pour s'insérer dans le 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. 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.

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 Skin 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 index.php, is api.php, 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 query.php), 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.

Les programmes client peuvent utiliser l'API pour se connecter, obtenir des données et publier des modifications. 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

Page principale : Architecture:MediaWiki

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. En tant que tel, l'architecture de MediaWiki reste très vivante, tout comme l'immense communauté des utilisateurs qu'elle supporte.

Notes et références

  1. Les demandes de vues sont habituellement enjolivées en réécrivant l'URL, dans cet exemple, en w:Apple.
  2. $url
  3. https://twitter.com/MagnusManske/status/1083507467802365952

Lectures complémentaires

Voir aussi