Manual:Arquitectura de MediaWiki

Este documento es el resultado del proyecto MediaWiki architecture document , cuyo contenido fue desarrollado para su inclusión en el libro Arquitectura de aplicaciones de fuentes abiertas. El capítulo del libro contiene una reseña histórica que corresponde a la historia de MediaWiki, y esta página wiki ha tenido numerosas ediciones desde la publicación del capítulo en 2012.

Desde el principio, MediaWiki fue desarrollado específicamente para ser el software de Wikipedia. Los desarrolladores han trabajado para facilitar la reutilización por terceros, pero la influencia y los sesgos de Wikipedia han moldeado la arquitectura de MediaWiki a lo largo de su historia.

Wikipedia es uno de los diez sitios web más populares del mundo, recibiendo en la actualidad unos 400 millones de usuarios únicos cada mes. Obtiene más de 100 000 visitas por segundo. Wikipedia no está sostenida por la publicidad, sino en su totalidad por una organización sin ánimo de lucro, la Fundación Wikimedia, que depende de las donaciones como principal modelo de financiación. Esto significa que MediaWiki no solo debe administrar uno de los diez principales sitios web, sino que además debe hacerlo con un presupuesto restringido. Para satisfacer estas demandas, MediaWiki prioriza en gran medida el rendimiento, el almacenamiento en caché y la optimización. Aquellas funcionalidades que no se pueden habilitar en Wikipedia se revierten o se deshabilitan mediante una variable de configuración; existe un eterno compromiso etre el rendimiento y la cantidad de funcionalidades.

La influencia de Wikipedia en la arquitectura de MediaWiki no está limitada al rendimiento. Al contrario que los CMS genéricos, MediaWiki se escribió desde su origen para un propósito muy concreto: apoyar una comunidad que crea y mantiene conocimiento libremente reutilizable en una plataforma abierta. Esto significa, por ejemplo, que MediaWiki no incluye funcionalidades habituales en los CMS comerciales (como un flujo de publicación sencillo o las listas de control de accesos (ACL)), pero ofrece una variedad de herramientas para hacer frente al spam y al vandalismo.

Así que, desde el principio, las necesidades y acciones de una comunidad en constante evolución de participantes de Wikipedia han influido en el desarrollo de MediaWiki y viceversa. La arquitectura de MediaWiki ha sido impulsado muchas veces por iniciativas emprendidas o solicitadas por la comunidad, como la creación de Wikimedia Commons o la funcionalidad de revisiones marcadas (flagged revisions). Los desarrolladores han hecho cambios de peso en la arquitectura, como el preprocesador de MediaWiki 1.12, ya que la manera en que los wikipedistas utilizaban MediaWiki los hizo necesarios.

MediaWiki también ha obtenido una sólida base de usuarios externos al ser software de código abierto desde el principio. Los reutilizadores terceros saben que, siempre que un sitio web de tan alto perfil como Wikipedia utilice MediaWiki, el software será mantenido y mejorado. En el pasado, MediaWiki estaba muy centrado en los sitios de Wikimedia, pero se han hecho esfuerzos para hacerlo más genérico y adaptarse mejor a las necesidades de estos usuarios terceros. Por ejemplo, MediaWiki incluye un excelente instalador basado en la web, lo que hace que el proceso de instalación sea mucho menos doloroso que cuando todo se tenía que hacer a través de la línea de comandos, y el software contenía rutas fijas para Wikipedia.

Aun así, MediaWiki es y sigue siendo el software de Wikipedia, y esto se muestra a lo largo de su historia y de su arquitectura.

Base de código y prácticas de MediaWiki

Arquitectura general

Capa de usuario	Navegador web
Capa de red	Varnish
	Servidor web Apache
Capa lógica	Scripts PHP de MediaWiki
	PHP
Capa de datos	Sistema de archivos	Base de datos MySQL (programa y contenido)	Sistema de almacenamiento en caché

PHP

PHP fue escogido como entorno para la «Fase II» del software de Wikipedia en 2001; MediaWiki ha crecido orgánicamente desde entonces, y sigue evolucionando a día de hoy. La mayoría de desarrolladores de MediaWiki son voluntarios que colaboran en su tiempo, y eran muy pocos en los primeros años. Algunas decisiones u omisiones en el diseño del software pueden parecer un error en retrospectiva, pero es difícil criticar a los fundadores por no haber implementado cierta abstracción que hoy se considera crítica, siendo tan pequeña la base de código inicial y tan corto el tiempo que llevó su desarrollo.

Por ejemplo, MediaWiki utiliza nombres de clases sin prefijo, lo que puede causar conflictos cuando el núcleo de PHP y los desarrolladores de PECL añaden nuevas clases. Como consecuencia de ello, la clase Namespace de MediaWiki se tuvo que renombrar a MWNamespace para ser compatible con PHP 5.3. Usar un prefijo de forma consistente en todas las clases (por ejemplo, "MW") habría facilitado la integración de MediaWiki en otra aplicación o biblioteca.

Depender de PHP probablemente no fue la mejor opción de cara al rendimiento, ya que no se ha beneficiado de las mejoras que otros lenguajes dinámicos han experimentado. El uso de Java habría sido mucho mejor para el rendimiento, y habría simplificado el escalado en la ejecución de tareas de mantenimiento del servidor. Por otra parte, PHP es muy popular, lo que facilita la incorporación de nuevos desarrolladores.

Aunque MediaWiki aún contiene código heredado «feo», se han hecho mejoras importantes con los años, y se han introducido nuevos elementos a su arquitectura a lo largo de la historia. Algunos de ellos son las clases Parser, SpecialPage y Database, la clase Image y la jerarquía de la clase FileRepo, ResourceLoader y la jerarquía Action. MediaWiki empezó sin ninguno de estos elementos, pero todos ellos se ocupan de funcionalidades que han estado allí desde el principio. Muchos desarrolladores están interesados principalmente en el desarrollo de funcionalidades, y la arquitectura se suele dejar de lado sólo para retomarse más tarde, cuando el coste de trabajar en una arquitectura inadecuada se vuelve evidente.

Seguridad

Debido a que MediaWiki es la plataforma de sitios de alto perfil como Wikipedia, los desarrolladores del núcleo y revisores de código han implantado reglas estrictas de seguridad. Para que sea más fácil escribir código seguro, MediaWiki ofrece a los desarrolladores capas de envoltura destinadas a la salida HTML y las consultas a la base de datos para gestionar el escape de caracteres. Para depurar la entrada del usuario, se emplea la clase WebRequest, que analiza los datos que se pasan por la URL o a través de un formulario por POST. Retira las barras invertidas de «comillas mágicas», elimina los caracteres de entrada ilegales y normaliza las secuencias Unicode. Se evitan los ataques de falsificación de peticiones entre sitios (CSRF) mediante el uso de tokens, y los de scripting entre sitios (XSS) validando las entradas y escapando las salidas, habitualmente mediante la función htmlspecialchars() de PHP. MediaWiki también proporciona (y usa) un saneador HTML junto con la clase Sanitizer, así como funciones de bases de datos que impiden los ataques de inyección SQL.

Configuración

MediaWiki ofrece cientos de parámetros de configuración que se almacenan en variables globales de PHP. Su valor predeterminado está definido en DefaultSettings.php, y el administrador del sistema puede redefinirlos editando LocalSettings.php.

Anteriormente, MediaWiki dependía en exceso de las variables globales, incluso para la configuración y el procesamiento de contextos. Las variables globales tienen graves implicaciones de serguridad con la función register_globals de PHP (que no le hace falta a MediaWiki desde la versión 1.2). Este sistema también limita las abstracciones potenciales para la configuración y dificulta la optimización del proceso de arranque. Además, el espacio de nombres de configuración está compartido con las variables utilizadas para el registro y el contexto de los objetos, lo que puede dar lugar a conflictos. Desde el punto de vista del usuario, las variables de configuración globales también han hecho que MediaWiki parezca difícil de configurar y mantener. El desarrollo de MediaWiki ha sido la historia de un lento pero progresivo desplazamiento de contexto de las variables globales a los objetos. Almacenar el contexto del procesamiento en variables miembros de objetos permite la reutilización de estos objetos de una forma mucho más flexible.

Almacenamiento de la base de datos y del texto

Esquema de la base de datos del núcleo de MediaWiki

MediaWiki utiliza un servidor de base de datos relacional desde el software de la Fase II. El SGBD predeterminado (y con mejor soporte) para MediaWiki es MySQL, que es el que utilizan todos los sitios de Wikimedia, aunque otros SGBD (como PostgreSQL, Oracle y SQLite) disponen de implementaciones mantenidas por la comunidad. Un administrador de sistemas puede escoger un SGBD durante la instalación de MediaWiki, y MediaWiki proporciona tanto una capa de abstracción para la base de datos como una capa de abstracción para las consultas que simplifica el acceso a la base de datos por parte de los desarrolladores.

La disposición actual contiene decenas de tablas. Muchas de ellas conciernen el contenido del wiki (como page, revision, category y recentchanges). Otras tablas contienen datos de usuarios (user, user_groups), archivos multimedia (image, filearchive), gestión de la caché (objectcache, l10n_cache, querycache) y herramientas internas (job para la cola de trabajo), entre otros. En MediaWiki hay un uso extensivo de índices y de tablas de resumen, ya que las consultas SQL que recorren un gran número de filas pueden ser muy costosas, particularmente en los sitios de Wikimedia. Generalmente no se recomienda emplear consultas no indizadas.

La base de datos ha pasado por decenas de cambios de esquema a lo largo de los años, siendo el más notable el desacoplamiento del almacenamiento de texto y el seguimiento de revisiones en MediaWiki 1.5.

Las principales tablas de contenido en MediaWiki 1.4 y 1.5.

En el modelo 1.4, el contenido se almacenaba en dos tablas importantes, cur (que contenía el texto y los metadatos de la revisión actual de la página) y old (que contenía revisiones anteriores); las páginas borradas se almacenaban en archive. Cuando se editaba una página, la revisión que hasta entonces había sido la última se copiaba a la tabla old, mientras que la nueva edición se guardaba en cur. Cuando se renombraba una página, el título debía actualizarse en los metadatos de todas las revisiones de old, lo cual podía llevar mucho tiempo. Cuando se borraba una página, sus entradas tanto en la tabla cur como en la old debían copiarse a la tabla archive antes de ser borradas; esto suponía trasladar el texto de todas las revisiones, lo que podía ser un número muy grande y por tanto llevar tiempo.

En el modelo 1.5, se desacoplaron los metadatos y el texto de las revisiones: las tablas cur y old fueron reemplazadas por page (metadatos de las páginas), revision (metadatos de todas las revisiones, antiguas o actuales) y text (texto de todas las revisiones, antiguas, actuales o borradas). Ahora, cuando se edita una página, no es necesario copiar los metadatos de la revisión entre las tablas: basta con insertar una nueva entrada y actualizar el puntero page_latest. Además, los metadatos de revisión ya no incluyen el título de la página, sino solo su identificador: esto elimina la necesidad de renombrar todas las revisiones cada vez que se renombra una página.

La tabla revision almacena los metadatos de cada revisión, pero no su texto; en lugar de eso, contienen un identificador de texto que apunta a la tabla text, que sí contiene el texto. Cuando se borra una página, se queda en su sitio el texto de todas las revisiones de la misma, por lo que no hace falta trasladarlo a otra tabla. La tabla text está compuesta por un mapeo de identificadores a blobs de texto; un campo de banderas (variables binarias) indica si el blob de texto está comprimido con gzip (para ahorrar espacio) o si el blob de texto solo es un puntero a un almacenamiento de texto externo. Los sitios de Wikimedia emplean un clúster de almacenamiento externo respaldado por MySQL con blob de unas pocas decenas de revisiones. La primera revisión del blob se almacena en su totalidad, y las revisiones siguientes de la misma página se almacenan en forma de diferencias respecto de la revisión anterior; y luego se comprimen los blobs con gzip. Como se agrupan las revisiones por página, tienden a ser similares, de modo que las diferencias entre revisiones son relativamente pequeñas y gzip funciona bien. La razón de compresión en los sitios de Wikimedia se acerca al 98%.

MediaWiki también tiene soporte integrado para el equilibrio de carga, incorporado ya en 2004 en MediaWiki 1.2 (cuando Wikipedia obtuvo su segundo servidor, un hito en ese momento). El equilibrador de carga (el código PHP de MediaWiki que decide a qué servidor conectarse) es ahora una parte crítica de la infraestructura de Wikimedia, lo que explica su influencia en algunas decisiones algorítmicas en el código. El administrador de sistemas puede especificar en la configuración de MediaWiki que hay un servidor maestro y un número arbitrario de servidores esclavos de la base de datos, y a cada servidor se le puede asignar un peso. El equilibrador de carga enviará todas las escrituras al maestro y equilibrará las lecturas en función de los pesos. También hace un seguimiento del retraso de replicación de cada esclavo. Si el retraso de replicación de un esclavo excede los 30 segundos, no recibirá más consultas de lectura para permitir que se ponga al día; si todos los esclavos tienen un retraso de más de 30 segundos, MediaWiki se pondrá automáticamente en modo de solo lectura.

El «protector de la cronología» de MediaWiki asegura que el retraso de replicación nunca hace que un usuario vea una página que afirme que aún no se ha producido una acción que acaba de realizar. Esto se hace almacenando la posición del maestro en la sesión del usuario si una solicitud que hizo dio lugar a una consulta de escritura. La próxima vez que el usuario haga una solicitud de lectura, el equilibrador de carga lee esta posición de la sesión y trata de seleccionar un esclavo que haya alcanzado esa posición de replicación para servir la solicitud. Si no hay ninguno disponible, esperará hasta que haya alguno. Podrá parecerles a otros usuarios que esa acción aún no se ha producido, pero la cronología permanece consistente para cada usuario.

Solicitudes, almacenamiento en caché y entrega

Flujo de trabajo de la ejecución de una solicitud web

index.php es el punto de acceso principal de MediaWiki y gestiona la mayoría de las solicitudes procesadas por los servidores de la aplicación (es decir, las solicitudes que no son servidas por la infraestructura de caché; véase a continuación). El código ejecutado desde index.php realiza comprobaciones de seguridad, carga los parámetros de configuración predeterminados de includes/DefaultSettings.php, estima la configuración con includes/Setup.php y luego aplica los parámetros del sitio contenidos en LocalSettings.php. A continuación, instancia un objeto MediaWiki ($mediawiki) y crea un objeto Title ($wgTitle) en función del título y de los parámetros de acción de la solicitud.

index.php puede recibir una serie de parámetros de acción en la solicitud URL; la acción predeterminada es view, que muestra la vista habitual del contenido de un artículo. Por ejemplo, la solicitud https://en.wikipedia.org/w/index.php?title=Apple&action=view muestra el contenido del artículo «Apple» de Wikipedia en inglés.. Otras acciones habituales comprenden edit (para abrir un artículo), submit (para previsualizar o guardar un artículo), history (para ver el historial de un artículo) y watch (para añadir un artículo a la lista de seguimiento del usuario). Las acciones administrativas comprenden delete (para borrar un artículo) y protect (para evitar que se edite un artículo).

Entonces se llama a MediaWiki::performRequest() para gestionar la mayor parte de la solicitud de la URL. Revisa títulos erróneos, restricciones de lectura, redirecciones interwiki locales y bucles de redirecciones, y determina si la solicitud es para una página normal o una página especial.

Las solicitudes de páginas normales se derivan a MediaWiki::initializeArticle() para crear un objeto Article para la página ($wgArticle), y después a MediaWiki::performAction(), que gestiona las acciones «estándar». Una vez completada la acción, MediaWiki::doPostOutputShutdown() finaliza la solicitud confirmando las transacciones de la base de datos, generando el HTML resultante y lanzando las actualizaciones diferidas a través de la cola de trabajo. MediaWiki::restInPeace() confirma las actualizaciones diferidas y cierra la tarea con elegancia.

Si la página solicitada es una página especial (es decir, no una página de contenido regular del wiki, sino una página relacionada con el software como por ejemplo Statistics), SpecialPageFactory::executePath recibe la llamada en lugar de initializeArticle(); entonces se llama al script PHP correspondiente. Las páginas especiales pueden hacer todo tipo de cosas mágicas, y cada una tiene un propósito específico, a menudo independiente de cualquier artículo individual o de su contenido. Las páginas especiales comprenden distintos tipos de informes (cambios recientes, registros, páginas sin categorizar) y herramientas de administración del wiki (bloqueos a usuarios, cambios de derechos de usuarios), entre otros. El flujo de trabajo de su ejecución depende de su función.

Muchas funciones contienen código de perfilado, lo que permite seguir el flujo de trabajo de su ejecución para tareas de depuración si el perfilado está habilitado. El perfilado se realiza llamando a las funciones wfProfileIn y wfProfileOut para, respectivamente, iniciar y detener el perfilado de una función, ambas funciones toman el nombre de la función que se desea perfilar como parámetro. En los sitios de Wikimedia, el perfilado se realiza sobre un porcentaje de todas las solicitudes con el fin de preservar el rendimiento. MediaWiki envía paquetes UDP a un servidor central que los recolecta y produce datos de perfilado.

Ensamblaje de una página no almacenada en caché

Al ver una página, el código HTML puede haberse tomado de la caché (véase a continuación); si no, se expanden en primer lugar las plantillas, las funciones del analizador sintáctico y las variables. Esto proporciona el wikitexto expandido, un resultado intermedio que se puede ver mediante Special:ExpandTemplates, y que depende de:

• el wikitexto;
• las plantillas a las que se hace referencia directa o indirecta;
• las funciones del analizador sintáctico a las que se hace referencia directa o indirecta;
• los valores de las variables a las que se hace referencia directa o indirecta.

A continuación, se convierte este wikitexto expandido a código HTML que se envía al usuario; este código contiene referencias a CSS, JavaScript y archivos de imagen. El usuario puede ver este resultado intermedio aplicando la opción «Ver código fuente» del navegador. El código HTML de una página dada depende de:

• el wikitexto expandido;
• el modo, por ejemplo, lectura o edición (véase a continuación);
• la existencia de las páginas enlazadas internamente (proporciona un enlace de visualización o de edición);
• la apariencia y otras preferencias del usuario;
• el nombre del usuario;
• el estado del usuario (más enlaces si se trata de un administrador del sistema, etc.);
• el espacio de nombres (determina el enlace a la página de discusión o, en el caso de una página de discusión, la página asociada);
• si la página está en la lista de seguimiento del usuario (proporciona un enlace para añadir o quitar de la lista de seguimiento);
• si se ha editado recientemente la página de discusión del usuario (proporciona un mensaje).

Por último, el navegador genera el HTML utilizando los archivos referenciados. El resultado que el usuario ve en la pantalla depende de:

• el código HTML;
• los archivos referenciados por el código HTML, como las imágenes incrustadas, los archivos CSS del lado del servidor y los archivos JavaScript;
• el navegador y sus parámetros de configuración, incluyendo posiblemente un archivo CSS local, y la resolución de pantalla.

Si JavaScript está respondiendo a un evento tal como el clic del ratón, la página que se ve en la pantalla también depende de él. Esto se aplica, por ejemplo, al caso de una tabla ordenable.

Cuando el usuario selecciona la pestaña Editar, se le envía el propio wikitexto, sea de toda la página o de una sola sección. Cuando el usuario pulsa el botón Mostrar previsualización, se envía su nueva versión del wikitexto al servidor, que a su vez envía la nueva versión correspondiente del código HTML, que se genera de nuevo y se muestra encima o debajo de la nueva versión del wikitexto del usuario (que el servidor también ha devuelto). Después de posiblemente más cambios y previsualizaciones, el usuario pulsa el botón Publicar cambios, que envía la versión «final» del usuario al servidor, que ahora registra la edición y envía (de nuevo) el HTML de la nueva versión. En algunos casos, también se produce en esta fase una conversión automática del wikitexto.

Almacenamiento en caché

El propio MediaWiki está mejorado a nivel de rendimiento porque desempeña un papel central en los sitios de Wikimedia, pero también forma parte de un ecosistema operativo mayor que ha influido en su arquitectura. La infraestructura de almacenamiento en caché de Wikimedia ha impuesto limitaciones en MediaWiki; los desarrolladores han abordado estos asuntos, no tratando de modelar la extensivamente optimizada infraestructura de caché de Wikimedia en torno a MediaWiki, sino haciendo que MediaWiki fuera más flexible para que pudiera trabajar dentro de dicha infraestructura sin comprometer su rendimiento ni sus necesidades de caché.

En los sitios de Wikimedia, la mayoría de las solicitudes son gestionadas por proxies inversos de caché (Squid) y nunca llegan siquiera a los servidores de aplicación de MediaWiki. Los Squids contienen versiones estáticas de páginas enteras renderizadas que se sirven para lecturas simples a usuarios que no tienen sesión iniciada en el sitio. MediaWiki soporta nativamente Squid y Varnish, y se integra con esta capa de caché, por ejemplo, notificándoles que purguen una página de la caché cuando se ha cambiado. Para los usuarios conectados (con sesión activa) y para otras solicitudes que no pueden ser atendidas por Squid, éste reenvía las solicitudes al servidor web (Apache).

El segundo nivel de caché se manifiesta cuando MediaWiki genera y ensambla la página a partir de múltiples objetos, muchos de los cuales se pueden almacenar en caché para minimizar el número de llamadas futuras. Tales objetos comprenden la interfaz de la página (barra lateral, menús texto de la interfaz de usuario) y el propio contenido, analizado a partir del wikitexto. La caché de objetos en memoria ha estado disponible en MediaWiki desde la temprana versión 1.1 (2003), y es particularmente importante evitar volver a someter las páginas largas y complejas al análisis sintáctico.

Los datos de la sesión de conexión también se pueden almacenar en memcached, que permite que las sesiones funcionen de forma transparente en múltiples servidores web front-end en una configuración de equilibrio de carga (Wikimedia depende en gran medida del equilibrio de carga, para lo que utiliza LVS junto con PyBal).

Desde la versión 1.16, MediaWiki utiliza una caché de objetos dedicada para textos localizados de la interfaz de usuario; esto se añadió después de observar que una gran parte de los objetos almacenados en memcached consistían en mensajes de la interfaz de usuario localizados en el idioma del usuario. El sistema se basa en recuperaciones rápidas de mensajes individuales de bases de datos constantes (CDB), es decir, archivos con pares clave-valor. Las CDB minimizan la sobrecarga de memoria y el tiempo de arranque en el caso típico y también se utilizan para la caché interwiki.

La última capa de caché consiste en la caché de opcode (código de operación) de PHP, que habitualmente está habilitada para acelerar las aplicaciones PHP. La compilación puede ser un proceso largo; para evitar compilar los scripts de PHP en opcode cada vez que se les invoque, se puede emplear un acelerador PHP para almacenar el opcode compilado y ejecutarlo directamente sin compilación. MediaWiki «funcionará sin más» con muchos aceleradores como APC, un acelerador de PHP.

Debido a su sesgo hacia Wikimedia, MediaWiki está optimizado para esta infraestructura completa, multicapa y distribuida de caché. De todas maneras, también soporta nativamente configuraciones alternativas para sitios más pequeños. Por ejemplo, ofrece un sistema simplista opcional de caché de archivos que almacena la salida de páginas completamente renderizadas, tal como lo hace Squid. Además, la capa de caché de objetos abstractos de MediaWiki le permite almacenar los objetos de la caché en varios lugares, incluyendo el sistema de archivos, la base de datos o la caché de opcode.

ResourceLoader

Al igual que en muchas aplicaciones web, la interfaz de MediaWiki se ha vuelto más interactiva y adaptable a lo largo de los años, principalmente a través del uso de JavaScript. Los esfuerzos para la usabilidad iniciados en 2008, así como la gestión avanzada de archivos multimedia (por ejemplo, la edición en línea de archivos de video), exigían mejoras específicas de rendimiento en el frontal web.

Para optimizar la entrega de activos JavaScript y CSS, se desarrolló el módulo ResourceLoader. Iniciado en 2009, se completó en 2011 y se ha convertido en una funcionalidad del núcleo de MediaWiki a partir de la versión 1.17. ResourceLoader funciona cargando los activos JS y CSS a demanda, reduciendo el tiempo de carga y de análisis sintáctico de funcionalidades no utilizadas, por ejemplo, en navegadores más antiguos. También minifica el código, agrupa los recursos para ahorrar solicitudes y puede incrustar imágenes en forma de URI de datos.

Idiomas

Página principal: Manual:Language

Contexto y justificación

Una parte central de contribuir y diseminar conocimiento libre efectivamente a todo el mundo es proporcionarlos en el mayor número posible de idiomas. Wikipedia está disponible en más de 280 idiomas, y los artículos enciclopédicos en inglés representan menos del 20 % de todos los artículos. Como Wikimedia y sus sitios hermanos existen en tantos idiomas, es importante no sólo proporcionar el contenido en la lengua materna de los lectores, sino también proporcionar una interfaz localizada y herramientas de introducción y conversión para que los participantes puedan aportar contenido.

Por esta razón, la localización e internacionalización (l10n e i18n) son un componente central de MediaWiki. El sistema i18n es omnipresente y afecta a muchas partes del software; asimismo es uno de los más flexibles y ricos en funcionalidades. Generalmente se antepone la comodidad de los traductores a la de los desarrolladores, pero se considera que este es un coste aceptable.

MediaWiki está actualmente traducido a más de 350 idiomas, incluidos los que no utilizan el alfabeto latino o que se escriben de derecha a izquierda (RTL), con distintos niveles de completitud. La interfaz y el contenido pueden estar en distintos idiomas y pueden presentar una direccionalidad mixta.

Idioma del contenido

MediaWiki utilizaba originalmente una codificación en función del idioma, lo que dio lugar a muchos problemas; por ejemplo, no se podían utilizar sistemas de escritura ajenos en los títulos de las páginas. En su lugar se adoptó UTF-8. El soporte de conjuntos de caracteres distintos de UTF-8 fue abandonado en 2005 a la vez que se llevó a cabo el cambio clave del esquema de la base de datos en MediaWiki; el contenido ahora debe estar codificado en UTF-8.

Los caracteres que no están disponibles en el teclado del editor se pueden personalizar e insertar mediante Edittools, un mensaje de la interfaz de MediaWiki que aparece debajo de la ventana de edición; su versión JavaScript inserta automáticamente el carácter que recibe el clic en la ventana de edición. La extensión WikiEditor de MediaWiki, desarrollada como parte de un esfuerzo para la usabilidad, combina caracteres especiales con la barra de herramientas de edición. Otra extensión denominada UniversalLanguageSelector , proporciona métodos adicionales de entrada y funcionalidades de mapeo de teclas para caracteres no ASCII.

Entre las mejoras recientes y futuras está un mejor soporte para texto de derecha a izquierda, texto bidireccional (texto de izquierda a derecha y de derecha a izquierda en la misma página) y UniversalLanguageSelector .

Idioma de la interfaz

Los mensajes de la interfaz se han almacenado en matrices PHP de pares clave-valor desde que se creó el software Phase III. Cada mensaje está identificado por una clave única a la que se asignan distintos valores en función del idioma. Las claves son definidas por los desarrolladores, a los que se les recomienda utilizar prefijos para las extensiones; por ejemplo, las claves de los mensajes de la extensión UploadWizard empiezan por mwe-upwiz-, donde mwe significa MediaWiki extension («extensión de MediaWiki»).

Los mensajes de MediaWiki pueden contener parámetros proporcionados por el software que a menudo afectarán al mensaje desde un punto de vista gramatical. Con el fin de asegurar la compatibilidad de prácticamente cualquier idioma posible, el sistema de localización de MediaWiki ha mejorado y se ha vuelto más complejo con el tiempo para acomodar sus características específicas y sus excepciones, que a menudo les son extrañas a los angloparlantes.

Por ejemplo, los adjetivos son invariables en inglés, pero en otros idiomas como el francés es necesario que concuerden con los sustantivos en género y número. Si el perfil del usuario incluye preferencias de género, se puede emplear el selector {{GENDER:}} en los mensajes de la interfaz para tenerlas en cuenta (más información). Otros selectores son {{PLURAL:}}, para plurales «simples» o para idiomas como el árabe, que pueden incluir otros números gramaticales (dual, trial o paucal), y {{GRAMMAR:}}, que proporcionan funciones de transformación gramatical para idiomas como el finés cuyos casos gramaticales causan alteraciones o inflexiones.

La distinción de género también se puede emplear en espacios de nombres de usuario que dependan del género para que el título y la URL de la página se refieran correctamente al usuario. Las variantes de género estándar para los espacios de nombres de MediaWiki se definen mediante $namespaceGenderAliases en el MessagesXx.php de cada idioma, mientras que $wgExtraGenderNamespaces se puede emplear en espacios de nombres específicos del wiki. A partir de r107559, trece idiomas utilizan por defecto esta funcionalidad.

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

Localización de mensajes

Véase también: [[:Help:Mensaje del sistema ]]

Los mensajes localizados (traducidos) de la interfaz para MediaWiki residen en archivos MessagesXx.php, donde Xx es el código ISO-639 del idioma (por ejemplo, MessagesFr.php para el francés); los mensajes predeterminados están en inglés y se almacenan en MessagesEn.php. Las extensiones de MediaWiki emplean un sistema similar o contienen todos los mensajes localizados en un archivo [Nombre-de-la-extensión].i18n.php. Junto con las traducciones, los archivos Message también incluyen otros datos que dependen del idioma, como los formatos de fecha.

Las traducciones se llevaban a cabo en el pasado mediante el envío de parches PHP para los archivos MessagesXx.php. En diciembre de 2003, MediaWiki 1.1 introdujo los «mensajes de la base de datos» (database messages), un subconjunto de páginas wiki del espacio de nombres MediaWiki que contienen mensajes de interfaz. El contenido de la página wiki MediaWiki:[Clave-de-mensaje] es el texto del mensaje, y redefine su valor en el archivo PHP. Las versiones localizadas del mensaje se encuentran en MediaWiki:[Clave-de-mensaje]/[código-de-idioma], por ejemplo, MediaWiki:Rollbacklink/de.

Esta funcionalidad ha permitido que los usuarios avanzados traduzcan (y personalicen) los mensajes de interfaz de forma local en su wiki, pero el proceso no actualiza los archivos i18n incluidos con MediaWiki. En 2006, Niklas Laxström creó un sitio web especial y muy personalizado de MediaWiki (actualmente albergado en translatewiki.net) donde los traductores pueden localizar con facilidad los mensajes de interfaz a todos los idiomas simplemente editando una página wiki. Los mensajes MessagesXx.php a continuación se actualizan en el repositorio de código de MediaWiki, de donde pueden ser obtenidos automáticamente por cualquier wiki. En los sitios de Wikimedia, los mensajes de la base de datos ya sólo se emplean para la personalización, y no para la localización. Las extensiones de MediaWiki y algunos programas relacionados, como los bots, también se traducen en translatewiki.net

Con el fin de ayudar a los traductores a entender el contexto y significado de un mensaje de interfaz, se considera una buena práctica en MediaWiki añadir documentación a cada mensaje. Esta documentación se almacena en un archivo Message especial, con el código de idioma qqq, que no corresponde a ningún idioma real. La documentación de cada mensaje se muestra a continuación en la interfaz de traducción de translatewiki.net. Otra herramienta útil es el código de idioma qqx : al utilizarlo junto con el parámetro &uselang para mostrar una página wiki (por ejemplo, en.wikipedia.org/wiki/Special:RecentChanges?uselang=qqx), MediaWiki mostrará las claves de los mensajes en lugar de sus valores en la interfaz de usuario, lo cual es muy útil para identificar qué mensaje hay que traducir o modificar.

Gráfico de respaldo de idiomas

Los usuarios registrados pueden establecer el idioma de la interfaz en sus preferencias, en cuyo caso reemplaza el idioma predeterminado de la interfaz del sitio. MediaWiki también cuenta con idiomas de respaldo: si un mensaje no está disponible en el idioma elegido, se mostrará en el idioma más cercano posible y no necesariamente en inglés. Por ejemplo, el idioma de respaldo del bretón es el francés.

Usuarios

Los usuarios están representados en el código mediante instancias de la clase User, que encapsula todos los parámetros de configuración específicos del usuario (identificador de usuario, nombre, permisos, contraseña, dirección de correo electrónico, etc.). Las clases del cliente emplean accesores para acceder a estos campos; hacen todo el trabajo de determinar si el usuario tiene una sesión activa y si la opción solicitada puede ser satisfecha mediante las cookies o si es necesaria una consulta a la base de datos. La mayoría de los parámetros necesarios para generar páginas normales están establecidos en la cookie para minimizar el uso de la base de datos.

MediaWiki proporciona un sistema muy granular de permisos, con esencialmente un permiso de usuario para cada acción posible. Por ejemplo, para realizar la acción Rollback («Revertir», es decir, para anular rápidamente las ediciones del último usuario que editó una página particular), el usuario necesita el permiso rollback, incluido por defecto en el grupo de usuarios sysop de MediaWiki. Pero también se puede añadir a otros grupos de usuarios, o puede haber un grupo de usuarios dedicado que sólo proporcione este permiso (es el caso en Wikipedia en inglés, con el grupo Rollbackers). Se pueden personalizar los permisos de usuario editando la matriz $wgGroupPermissions en LocalSettings.php; por ejemplo, $wgGroupPermissions['user']['movefile'] = true; permite que todos los usuarios registrados puedan renombrar archivos. Un usuario puede pertenecer a varios grupos, y hereda los permisos más altos asociados a cada uno de ellos.

Sin embargo, el sistema de permisos de usuario de MediaWiki se diseñó originalmente pensando en Wikipedia, es decir, un sitio cuyo contenido es accesible para todos y donde sólo determinadas acciones están restringidas a algunos usuarios. MediaWiki carece de un concepto unificado y omnipresente de permisos; no proporciona funcionalidades típicas de los CMS como la restricción del acceso a la lectura o escritura en función del espacio de nombres, de la categoría, etc. Algunas extensiones de MediaWiki proporcionan estas funcionalidades hasta cierto punto.

Contenido

Estructura del contenido

El concepto de espacio de nombres se empleaba ya en la era UseModWiki de Wikipedia, donde las páginas de discusión tenían títulos de la forma «[Nombre del artículo]/Talk». Los espacios de nombres se introdujeron formalmente en el primer «script PHP» de Magnus Manske. Se volvieron a implementar varias veces a lo largo de los años, pero manteniendo siempre la misma función: separar distintos tipos de contenido. Consisten en un prefijo, separado del título de la página por un carácter de dos puntos (por ejemplo, Talk:, File: o Template:), aunque el espacio de nombres del contenido principal no tiene prefijo. Los usuarios de Wikipedia los adoptaron con rapidez y proporcionaron a la comunidad distintos espacios para evolucionar. Los espacios de nombres han demostrado ser una funcionalidad importante de MediaWiki, ya que crean las condiciones necesarias para una comunidad wiki y establecen discusiones de nivel meta, procesos comunitarios, portales, perfiles de usuario, etc.

La configuración predeterminada del espacio de nombres del contenido principal es que sea plano, sin subpáginas, porque así funciona Wikipedia, pero es trivial habilitarlas. Están habilitadas en otros espacios de nombres (como User:, donde los usuarios pueden por ejemplo trabajar en proyectos de artículos) y se muestran migas de pan.

Los espacios de nombres separan el contenido por tipo; dentro de un mismo espacio de nombres, las páginas se pueden organizar por tema mediante las categorías, un esquema pseudojerárquico de organización introducido en MediaWiki 1.3.

Procesado del contenido: el lenguaje de marcado y el analizador sintáctico de MediaWiki

El contenido generado por usuarios y almacenado por MediaWiki no está en HTML, sino en un lenguaje de marcado específico de MediaWiki y que a veces se denomina «wikitexto». Permite a los usuarios hacer cambios de formato (por ejemplo, negrita o cursiva mediante comillas simples), añadir enlaces (mediante corchetes), insertar contenido dependiente del contexto (como una fecha o una firma) y hacer que se produzca una cantidad inimaginable de cosas mágicas.

Para mostrar una página, este contenido se tiene que analizar sintácticamente, ensamblar a partir de todas las piezas externas o dinámicas a las que llama y convertir a HTML. El analizador sintáctico es una de las partes más esenciales de MediaWiki, lo cual también lo hace difícil de cambiar o mejorar. Debido a que cientos de millones de páginas wiki en todo el mundo dependen del analizador para seguir generando HTML como siempre, debe permanecer extremadamente estable.

El lenguaje de marcado no se especificó formalmente desde el principio, sino que empezó partiendo del marcado de UseModWiki y posteriormente se transformó y evolucionó acorde a la demanda. Por ejemplo, el uso de un formato ThreadMode («modo hilo») para las discusiones hizo que Magnus Manske implementara las tres o cuatro virgulillas (~~~~) como atajo para firmar las intervenciones propias en un texto no estructurado. Escogió las virgulillas porque se parecían a la firma manuscrita de su padre.

A falta de una especificación formal, el lenguaje de marcado de MediaWiki se ha convertido en un lenguaje complejo e idiosincrásico, en esencia compatible exclusivamente con el analizador de MediaWiki; no se puede representar como una gramática formal utilizando las sintaxis BNF, EBNF o ANTLR. La especificación del analizador actual se conoce a modo de broma como «lo que el analizador escupa a partir del wikitexto más unos cientos de casos de pruebas».

Ha habido muchas tentativas de utilizar analizadores alternativos, pero ninguno ha tenido éxito hasta ahora. En 2004, Jens Frank creó un tokenizador experimental para analizar wikitexto y se habilitó en Wikipedia, pero tuvo que deshabilitarse tres días después debido al mal rendimiento de la asignación de memoria para las matrices de PHP. Desde entonces, la mayor parte del análisis sintáctico se ha hecho con una enorme pila de expresiones regulares y un montón de funciones auxiliares. El marcado wiki y todos los casos especiales que el analizador necesita soportar también se han vuelto considerablemente más complejos, dificultando aún más cualquier tentativa futura.

Una notable mejora fue la reescritura del preprocesador en MediaWiki 1.12 por parte de Tim Sterling, cuya motivación principal fue mejorar el rendimiento del análisis sintáctico de páginas con plantillas complejas. El preprocesador convierte el wikitexto en un árbol XML del DOM que representa partes del documento (invocaciones de plantillas, funciones del analizador, ganchos de etiquetas, encabezados de secciones y algunas estructuras más), pero puede saltarse «ramas muertas» en la expansión de las plantillas, como los casos no seguidos en una estructura #switch y valores predeterminados no utilizados como argumentos de plantillas. Entonces, el analizador itera por la estructura del DOM y convierte su contenido en HTML.

Los trabajos recientes en un editor visual para MediaWiki han hecho necesario mejorar el proceso de análisis sintáctico (y hacerlo más rápido), por lo que se ha reanudado el trabajo en el analizador y en las capas intermedias entre el marcado de MediaWiki y el HTML final (véase Futuro, a continuación).

Palabras mágicas y plantillas

MediaWiki ofrece «palabras mágicas» que modifican el comportamiento general de la página o incluyen contenido dinámico en la misma. Comprenden conmutadores de comportamiento como __NOTOC__ (para ocultar la tabla de contenido automática) o __NOINDEX__ (para indicar a los motores de búsqueda que no indexen la página); variables como {{CURRENTTIME}} o {{SITENAME}} y funciones del analizador, es decir, palabras mágicas que pueden tomar parámetros, como {{lc:[string]}} (para producir [string] en minúsculas). Las construcciones como {{GENDER:}}, {{PLURAL:}} y {{GRAMMAR:}}, utilizadas para localizar la interfaz de usuario, son funciones del analizador.

La forma más común de incluir contenido de otras páginas en una página de MediaWiki es mediante plantillas. Las plantillas en realidad estaban destinadas a utilizarse para incluir el mismo contenido en distintas páginas, por ejemplo, paneles de navegación o avisos de mantenimiento en artículos de Wikipedia; tener la posibilidad de crear diseños de páginas parciales y reutilizarlos en miles de artículos con mantenimiento central tuvo un enorme impacto en sitios como Wikipedia.

Sin embargo, los usuarios también han utilizado (y abusado de) las plantillas para un propósito completamente diferente. MediaWiki 1.3 permitió que las plantillas tomaran parámetros que cambiaran su salida; la capacidad de añadir un parámetro predeterminado (introducida en MediaWiki 1.6) permitió la construcción de un lenguaje de programación funcional encima de PHP, lo que acabó siendo una de las funcionalidades más costosas en términos de rendimiento.

Tim Starling entonces desarrolló funciones adicionales del analizador (la extensión ParserFunctions) como una medida provisional frente a las construcciones demenciales creadas por usuarios de Wikipedia con las plantillas. Este conjunto de funciones incluía estructuras lógicas como #if y #switch y otras funciones como #expr (para evaluar expresiones matemática) y #time (para los formatos de hora).

Al poco tiempo, los usuarios de Wikipedia empezaron a crear plantillas aún más complejas con las nuevas funciones, lo que degradó considerablemente el rendimiento del análisis sintáctico en páginas ricas en plantillas. El nuevo preprocesador introducido en MediaWiki 1.12 (un cambio importante en la arquitectura) fue implementado para remediar en parte este problema. Posteriormente, los desarrolladores de MediaWiki debatieron sobre la posibilidad de emplear un lenguaje de scripting de verdad para mejorar el rendimiento. Extensión:Scribunto fue añadido en febrero de 2013.

Archivos multimedia

Los usuarios suben ficheros a través de la página Special:Upload; los administradores pueden configurar los tipos de archivos válidos mediante una lista blanca de extensiones. Una vez subidos, los archivos se almacenan en una carpeta en el sistema de archivos, y las miniaturas en un directorio dedicado thumb.

Debido a la misión educativa de Wikimedia, MediaWiki admite tipos de archivos que pueden no ser muy comunes en otras aplicaciones web u otros CMS, como imágenes vectoriales SVG y documentos multipágina PDF y DjVu. Se renderizan como archivos PNG y se pueden mostrar en forma de miniatura o en la línea de texto, como ocurre con otros formatos más comunes de imagen, como GIF, JPG y PNG.

Cuando se sube un archivo, se le asigna una página File: que contiene información introducida por el usuario que lo subió; se trata de texto libre, que generalmente incluye información de derechos de autor (autor, licencia) y elementos que describen o clasifican el contenido del archivo (descripción, ubicación, fecha, categorías, etc.). Aunque los wikis privados puede que no se preocupen mucho por esta información, en las bibliotecas multimedia como Wikimedia Commons es crítica para organizar la colección y asegurar la legalidad de compartir estos archivos. Se ha argumentado que la mayoría de estos metadatos deberían de hecho almacenarse en una estructura consultable como una tabla de base de datos. Esto facilitaría considerablemente la búsqueda, pero también la atribución y la reutilización por parte de terceros, por ejemplo, a través de la API.

La mayoría de los sitios de Wikimedia también permiten subidas «locales» a cada wiki, pero la comunidad trata de almacenar los archivos multimedia con licencia libre en la biblioteca multimedia libre de Wikimedia, es decir, en Wikimedia Commons. Cualquier sitio de Wikimedia puede mostrar un archivo alojado en Commons como si estuviera alojado de forma local. Esta costumbre evita tener que subir un mismo archivo a cada wiki para poder utilizarlo allí.

Como consecuencia de ello, MediaWiki tiene soporte nativo de repositorios multimedia externos, es decir, la capacidad de acceder a archivos multimedia alojados en otro wiki a través de su API y del sistema ForeignAPIRepo. Desde la versión 1.16, cualquier sitio web de MediaWiki puede emplear fácilmente archivos de Wikimedia Commons mediante la funcionalidad InstantCommons. Al utilizar un repositorio externo, las miniaturas se almacenan localmente para ahorrar ancho de banda. Sin embargo, (aún) no es posible subir un archivo a un repositorio multimedia externo desde otro wiki.

Personalización y extensión de MediaWiki

Niveles

La arquitectura de MediaWiki proporciona distintas maneras de personalizar y extender el software. Esto se puede hacer en distintos niveles de acceso:

• Los administradores de sistemas pueden instalar extensiones y apariencia, y configurar por separado los programas auxiliares del wiki (por ejemplo, para la creación de miniaturas de las imágenes o la generación de fórmulas TeX) y los parámetros de configuración globales (véase Configuración atrás).
• Los operadores de sistemas del wiki (sysops, a veces también denominados «administradores») pueden editar accesorios y parámetros de configuración JavaScript y CSS del sitio.
• Cualquier usuario registrado puede personalizar su propia experiencia e interfaz utilizando sus preferencias (para los parámetros existentes, apariencias y accesorios) o hacer sus propias modificaciones (utilizando sus páginas personales JS y CSS). Los programas externos también se pueden comunicar con MediaWiki a través de su API de máquina, si está activada, lo que básicamente hace que cualquier funcionalidad y dato sea accesible para el usuario.

JavaScript y CSS

MediaWiki puede leer y aplicar JavaScript y CSS a nivel de sitio o de apariencia mediante páginas wiki personalizadas; estas páginas se encuentran en el espacio de nombres MediaWiki:, y por tanto sólo pueden ser editadas por los operadores de sistemas; por ejemplo, las modificaciones de JavaScript de MediaWiki:Common.js afectan a todas las apariencias, el CSS de MediaWiki:Common.css afecta a todas las apariencias, pero MediaWiki:Vector.css sólo afecta a usuarios con la apariencia Vector.

Los usuarios pueden hacer los mismos tipos de cambios, que sólo afectarán a su propia interfaz, editando subpáginas de su página de usuario (por ejemplo, User:[Username]/common.js para JavaScript en todas las apariencias, User:[Username]/common.css para CSS en todas las apariencias y User:[Username]/vector.css para modificaciones CSS que sólo afectan a la apariencia de Vector).

Si la extensión Gadgets está instalada, los operadores de sistemas también pueden editar accesorios, es decir, fragmentos de código JavaScript que proporcionan funcionalidades que los usuarios pueden activar y desactivar en sus preferencias. Los próximos desarrollos en los accesorios permitirán compartirlos entre wikis, evitando así la duplicación.

Este conjunto de herramientas ha tenido un enorme impacto y aumentó en gran medida la democratización del desarrollo del software de MediaWiki. Se empodera a los usuarios individuales para que puedan añadir funcionalidades para su propio uso; los usuarios avanzados pueden compartirlas con los demás, ya sea de forma informal o a través de sistemas configurables a nivel global y controlados por los operadores de sistemas. Este marco es ideal para modificaciones pequeñas y autocontenidas, y presenta una barrera de entrada más baja que las modificaciones de código más profundas que se llevan a cabo mediante ganchos y extensiones.

Extensiones y apariencias

Para cuando las modificaciones JavaScript y CSS no bastan, MediaWiki proporciona un sistema de ganchos (hooks) que permite a desarrolladores terceros ejecutar código PHP personalizado antes, después o en lugar del código MediaWiki para eventos particulares. Las extensiones MediaWiki emplean ganchos para conectarse al código.

Antes de la existencia de los ganchos en MediaWiki, añadir código PHP personalizado suponía modificar el código del núcleo, lo cual ni era fácil ni estaba recomendado. Los primeros ganchos fueron propuestos y añadidos en 2004 por Evan Prodromou; desde entonces se han añadido muchos más a lo largo de los años cuando han hecho falta. Mediante los ganchos, incluso se puede extender el marcado wiki de MediaWiki con capacidades adicionales, utilizando extensiones de etiquetas.

El sistema de extensiones no es perfecto: el registro de extensiones se basa en la ejecución de código en el arranque, más que en los datos almacenables en caché, lo que limita la abstracción y la optimización, y perjudica el rendimiento de MediaWiki. Pero, en general, la arquitectura de las extensiones en la actualidad es un a infraestructura razonablemente flexible que ha ayudado a hacer más modular el código especializado, evitando que el software del núcleo se expanda mucho (más de la cuenta) y facilitando que los usuarios terceros puedan construir funcionalidades personalizadas por encima de MediaWiki.

Por el contrario, es muy difícil crear una nueva apariencia para MediaWiki sin reinventar la rueda. En MediaWiki, las apariencias son clases PHP cada una de las cuales extiende la clase padre Skin; contienen funciones que recopilan la información necesaria para generar el HTML. La longeva apariencia MonoBook del pasado era difícil de personalizar porque contenía mucho CSS específico para un navegador para ser compatible con navegadores antiguos; editar la plantilla o el CSS requería hacer muchos cambios ulteriores para reflejar la modificación para todos los navegadores y plataformas.

API

El otro punto de acceso principal de MediaWiki, aparte de index.php, es api.php, empleado para acceder a su API (interfaz de programación de aplicaciones) de consultas legibles por máquinas.

Los usuarios de Wikipedia inicialmente crearon «bots» que funcionaban haciendo raspado de pantalla (screen scraping) del contenido HTML servido por MediaWiki; este método era muy poco fiable y fallaba mucho. Para mejorar esta situación, los desarrolladores introdujeron una interfaz de sólo lectura (ubicada en query.php) que posteriormente evolucionó a una API de máquina completa de lectura y escritura que proporciona un acceso directo y de alto nivel a los datos contenidos en la base de datos de MediaWiki.

Los programas clientes pueden utilizar la API para iniciar sesión, obtener datos y publicar cambios. La API soporta clientes JavaScript ligeros basados en la web y aplicaciones de usuarios finales. Casi todo lo que se puede hacer a través de la interfaz web se puede hacer a través de la API. Hay bibliotecas de clientes que implementan la API de MediaWiki disponibles en muchos lenguajes, como Python y .NET.

Capas, dominios y patrones

Página principal: Architecture:MediaWiki

MediaWiki se puede dividir en unas 12 capas técnicas , cada una de las cuales llama a clases y al código de la capa situada por debajo, pero no por encima. Algunos ejemplos son la capa del instalador , la capa del punto de entrada , la capa del cableado y la capa de la API . El código, que se extiende por todas las capas, se puede agrupar en unos 21 módulos de dominio , algunos ejemplos de los cuales son el dominio de navegación (apariencias), el dominio de administración de usuarios (crear, renombrar, iniciar sesión) y el dominio de internacionalización . En MediaWiki se emplean muchos patrones de diseño de software , como el patrón de fábricas , el patrón de manejadores y el patrón de comandos .

Futuro

Lo que empezó como un proyecto de verano realizado por un solo desarollador PHP voluntario se ha convertido en MediaWiki, un motor wiki maduro y estable que alimenta uno de los diez principales sitios web con una infraestructura operativa ridículamente pequeña. Esto ha sido posible gracias a la optimización constante del rendimiento, los cambios iterativos en la arquitectura y un equipo de desarrolladores maravillosos.

La evolución de las tecnologías web y el crecimiento de Wikipedia reclaman mejoras futuras y nuevas funcionalidades, algunas de las cuales requieren cambios importantes en la arquitectura de MediaWiki. Este es, por ejemplo, el caso del proyecto en curso del editor visual, que ha incitado a retomar el trabajo en el analizador y en el lenguaje de marcado wiki, el DOM y la conversión final en HTML.

MediaWiki es una herramienta utilizada para diversos propósitos. En los proyectos de Wikimedia, por ejemplo, se utiliza para crear y mantener una enciclopedia (Wikipedia), alimentar una enorme biblioteca multimedia (Wikimedia Commons) o transcribir textos de referencia escaneados (Wikisource); y así sucesivamente. En otros contextos, se utiliza MediaWiki como un CMS corporativo o como un repositorio de datos, en ocasiones combinado con un marco semántico. Estos usos especializados para los que no hubo planificación probablemente seguirán dirigiendo evoluciones constantes de la estructura interna del software. Como tal, la arquitectura de MediaWiki está muy viva, al igual que la inmensa comunidad de usuarios que soporta.

Lecturas complementarias

• Documentación y soporte de MediaWiki: https://www.mediawiki.org
• Documentación de MediaWiki automáticamente generada: https://doc.wikimedia.org
• Domas Mituzas, Wikipedia: site internals, configuration, code examples and management issues [Wikipedia:variables internas del sitio, configuración, ejemplos de código e incidentes de gestión], Conferencia de Usuarios de MySQL, 2007. Texto completo disponible en http://dom.as/talks/
• Faidon Liambotis, The Wikimedia infrastructure [La infraestructura de Wikimedia], dotScale 2014. (video de YouTube)

Véase también

• Cómo llegar a ser un hacker de MediaWiki
• Manual:Architectural modules