Dico:Multilingue/Feuille de route

Attention : le contenu de cette page (Dico:Multilingue/Feuille de route) est publié sous la licence CreativeCommons − Zero. Toute modification y est également placée, veiller à ce que les modèles et images utilisés ne brisent pas cette licence (attention donc aux versions précédentes qui n’ont pas été cohérentes, le modèle !! n’est pas sous cette licence).

Cette page rassemble des réflexions et des procédures dans le but de passer le Dico en multilingue. Elle ne prétend pas être exhaustive et infaillible, mais cherche à lister, prévoir et planifier ce qui devra être fait, ainsi qu’élargir la réflexion à toute personne intéressée qui peut donc commenter et proposer des choses (voir la page de discussion). La licence indiquée ci-dessus permet d’éviter que l’utilisation / reproduction de cette page par qui que ce soit (entreprise ou autre) soit empêchée par un conflit entre CC-BY-SA et une autre licence.

Passage en multilingue (une fois pour toute)

Mise du Dico en « ferme de wiki »

• But : faire en sorte que la configuration du Dico des Ados soit faite de telle sorte qu’il soit possible d’ajouter et d’accéder à d’autres wikis, tout en restant sur la même installation de MediaWiki. Cela peut se faire de différentes manière, par exemple en utilisant wgConfig, en créant un code analysant le nom de domaine utilisé / les paramètres passés en ligne de commande pour savoir quelle BDD utiliser, en créant plusieurs fichiers qui se chargent en fonction de ce qu’il faut…
• Résultat : le système est capable, à partir du sous-domaine utilisé (xxx.dicoado.org) ou des paramètres d’une commande (--wiki), de charger la bonne base de données et la bonne configuration de MediaWiki afin de charger le wiki correspondant. L’installation de MediaWiki reste la même (il n’est pas question de dupliquer n fois le code du CMS), seule la base chargée et la configuration appliquée change.
• Nécessite : connaissance suffisante en administration système, en PHP, en fonctionnement de MediaWiki, et un peu de configuration pour Apache. 1 sysadmin min., 2 ou 3 ne sont pas de trop en conseil.

☑ Avoir un code capable d’analyser les informations entrantes (nom de domaine / paramètre --wiki) et choisir la base de données possible. Si aucune n’est disponible, échouer. ⇒ Fait, relecture toujours bienvenue pour la sécurité, me contacter. − Rififi ☑ Créer une architecture permettant de garder et charger les configs dans un ordre cohérent. ⇒ Choisie : on utilise wgConfig pour les configurations qui ont tendance à s’adapter avec le wiki. Plusieurs fichiers séparent les identifiants, les permissions du core, les extensions et leur configuration. − Rififi ☐ Relire attentivement la configuration, afin qu’elle soit bien la même (substantiellement) qu’avant. Prêter particulièrement attention au modification effectuée en même temps que la mise à jour de la configuration (telle que la suppression de Google Analytics, de certaines extensions, le changement de certains comportement, l’écriture explicite des permissions…) ☐ Adapter la configuration Apache actuelle (.htaccess dans la racine du dosier web) pour être prêt à accueillir de nouveaux wikis. ☐ Verrouiller le site, sauvegarder (le système de fichiers et la base de données), déployer la nouvelle configuration, effectuer les déplacements des dossiers nécessaires (/images/ → /images/fr et /cache/ → /cache/fr), faire expirer le cache ($wgCacheEpoch), update.php --wiki <bdd de fr>, vérifier, déverrouiller.

Installation d’un système d’authentification centralisé

• But : faire en sorte que les utilisateurs aient des comptes exclusivement globaux, qui peuvent être utilisés entre les (futurs) wikis de la ferme.
• Résultat : les comptes utilisateurs sont tous globaux et peuvent être utilisés quel que soit le wiki. Il n’est pas possible de créer un compte restreint à un seul wiki, tout compte sera un compte pour tout les wikis de la ferme.
• Nécessite : connaissance en administration système, en fonctionnement de MediaWiki et particulièrement du système de centralisation utilisé (CentralAuth ou wgSharedDb). Il peut-être utile d’avoir plusieurs avis afin de mieux choisir la solution adaptée. Prévoir du temps pour les tests et les bugs qui arriveront. 1 sysadmin min., 2 ou 3 ne sont pas de trop en conseil et en aide. La communauté autour peut aussi donner des avis concernant les solutions qu’elle préfère.

⏳ Décider de la méthode à utiliser pour créer un système centralisé. ⇒ Au vu de la dépréciation de wgSharedDb, et des fonctionnalités ajoutées par CentralAuth, et du fait que la méthode soit déjà « testée » par Wikimedia, on peut dire que cette extension, malgré la duplication pas si utile des tables utilisateurs que ça implique, soit la méthode la plus adaptée. Cela nécessitera en revanche plus de travail et il faut veiller à ce que les problèmes relevés dans cette tâche Phabricator puisse être mitigés (en utilisant le script de maintenance par exemple). − Rififi ⏳ Tester et voir quelle configuration de la solution choisie est adaptée. ⇒ Mes tests remontent malheureusement à longtemps et doivent être repris mais j’ai tout de même pu étudier un peu le fonctionnement de CentralAuth et des différentes fonctionnalités. J’ai pu également voir quelle configuration serait utile pour le dico : à priori on fera en sorte qu'il n’y ait que des comptes globaux, et comme nous resterons dans un seul sous-domaine nous n’aurons pas de "login wiki" mais un cookie CentralAuth partagé entre les domaines. Attention cependant, penser au fait que matomo.vikidia.org recevra aussi le cookie par conséquent. Risque ? − Rififi ☐ Créer une base de données, en configurant les utilisateurs adaptés pour CentralAuth (utilise l’interface d’Infomaniak). ☐ Sauvegarder la base de données ! Verrouiller au public pendant le travail. ☐ Configurer (se baser sur les tests précédemment réalisés) et installer CentralAuth. Bien penser à faire changer la configuration pour les cookies, y compris celle par wiki qui avait été réalisée dans l’optique de l’usage de wgSharedDb (avec un domaine réglé sur .dicoado.org). Au besoin, créer un script qui permet de supprimer les anciens cookies de manière transparente. ☐ Faire migrer tous les comptes. ☐ Vérifier que le wiki ne s’est pas désintégré dans l’espace-temps, vérifier qu’aucun compte n’est bloqué et que tous ont bien été globalisé. Rouvrir le site.

Création d’un Wiki « central »

• But : création d’un wiki qui n’est pas une version linguistique, qui rassemblera les informations et les outils de gestion de la ferme (par exemple, les permissions globales et autres actions de ce genre seront modifiées/effectuées sur ce wiki, et les politiques globales s'y trouveront).
• À décider : ce wiki devrait à priori contenir le répertoire centralisé d’image.
• Résultat : un wiki est créé. Il est configurable dans le but de pouvoir ensuite accueillir la gestion globale de la ferme.
• Nécessite : connaissance en sysadmin, en base de données, en gestion de wikis. 1sys min., un deuxième en backup n’est pas de trop.

☐ Suivre la procédure de création d’un wiki (partie technique). Ce wiki sera en anglais, appelé Central Dicoado. Le skin sera Foreground, logo identique. Il n’y aura en revanche à priori pas besoin de charger certaines extensions telles que PageForms, MediaWiki Semantics, Cargo… des économies peuvent être faites sur ce point. ☐ Régler CentralAuth pour considérer ce wiki comme le Central : la page d’exception pour le verrouillage global doit être une page de ce wiki, etc.

Passage en global des paramètres et des extensions qui le peuvent

• But : afin de gérer au mieux la ferme, il faudra activer et configurer les fonctionnalités globales disponibles et intéressantes. Les fonctionnalités repérées actuellement sont :
  • Permissions globales (essentiel) : un compte utilisateur peut avoir des droits sur tous les wikis ; une politique pour les permissions globales sera mise en place, en même temps ou plus tard.
  • Blocage globaux (essentiel) : permet de bloquer globalement un compte, une IP, ou les deux.
  • Renommage globaux (essentiel) : vérifier la procédure de renommage d’un compte utilisateur global.
  • Vérifications d’utilisateurs globale (utile) : décider si on laisse cette possibilité, et si oui l’activer.
  • Notifications globales (utile) : permet de recevoir les notifications d’un wiki tout en étant sur l’autre.
  • Filtres globaux (bonus) : peut avoir un intérêt de les configurer afin de ne pas répéter certains filtres.
• Résultat : lesdites fonctionnalités sont actives et fonctionnelles, et ont été configurées comme souhaitées.
• Nécessite : connaissance en les extensions / configuration utilisées. Nécessite de prendre des décisions qui impacteront la communauté future, prudence est donc de mise, il est important de connaître le fonctionnement du dico. 1sys min. et contact avec la communauté.

☐ Configurer les permissions globales : créer des groupes globaux (développeur, bureaucrate global, administrateur+ global, administrateur global).

Installation d’un répertoire centralisé d’images

• But : avoir un wiki qui sera un répertoire d’images utilisé par tous les autres wikis de la ferme. Les autres wikis ne devront pas avoir la possibilité de posséder des images locales, car les images importées sur le Dico sont généralement des logos ou du contenu utilisable sur tous les wikis et qui a donc plus de sens d’être centralisé. La connexion à Wikimedia Commons ne doit pas être affectée.
• À décider : ce wiki peut être le même que « central » mentionné plus haut. Cela serait mieux que le wiki français même si cela complexifie la chose, afin que le wiki français ne soit pas le centre des autres langues.
• Résultat : l’importation et l’utilisation des images sur les wikis de la ferme n’est possible qu’à travers le wiki centralisé ou Wikimedia Commons. Attention : en conséquence, les images du wiki français auront donc été déplacées vers le wiki central.

Création des autres langues initiales (en, de, it, ro)

• But : créer enfin les premières déclinaisons linguistiques du dico.
• Résultat : les versions linguistiques sont créées et lancées.

Procédures (à répéter autant que besoin)

Ajout d’un wiki (partie technique)

• But : cette procédure explique comment ajouter un wiki à la ferme.
• Résultat : la procédure est réussie dès qu’un wiki qui peut-être vide est ajouté à la ferme et est créé. Attention : elle ne prend aucunement compte de la création du contenu et de la communauté du wiki.
• Nécessite : 1 sysadmin min. pouvant manipuler des bases de données, pouvant gérer l’installation d’un wiki classique, et pouvant utiliser l’interface (assez intuitive) d’Infomaniak. 1 autre en backup ne sera pas de trop.
• Prérequis : avoir une base VIDE sous la version de MediaWiki correspondante (actuellement 1.35.6), créée avec l’installeur réglé avec AUCUNE extension (elles seront ajoutées lors du lancement du script update.php) ; elle se trouve dans template/db/ dans le dossier privé. Avoir les modèles (fichiers de base) pour les dossiers de la racine de MediaWiki "cache/" et "images/", dans le dossier template/mw_source du dossier privé.

1. Choisir un sous-domaine pour le wiki, qui sera son « code de wiki » (par exemple truc.dicoado.org). Par la suite appelons « code de wiki » $code.
2. Créer les dossiers ~/w/cache/$code et ~/w/images/$code. Remplir ces dossiers avec les modèles correspondant se trouvant dans le dossier "templates/mw_source/" du dossier privé.
3. Création des utilisateurs de base de données (interface d’Infomaniak)
   1. Créer une base de données, nommée dans le même modèle que les autres existantes pour MediaWiki.
   2. Créer un utilisateur avec lecture/écriture sur la base de donnée tout juste créée, ainsi que sur la base de donnée central (utilisée par CentralAuth). De même, nommer l’utilisateur en suivant la même logique que les autres utilisateurs prévus pour MediaWiki.
   3. Créer un utilisateur avec lecture/écriture/admin sur la base créée et sur celle centralisée.
   4. Si le wiki utilisera Cargo, alors créer une base de donnée pour Cargo ; ajouter un utilisateur avec lecture/écriture sur cette base ; ajouter un autre utilisateur avec lecture/écriture/admin sur cette base.
   5. Ajouter le nom de la base de donnée du wiki nouvellement créée dans LocalSettings.php ($wgLocalDatabases).
   6. Dans PrivateSettings.php, ajouter les identifiants crées dans la configuration, en utilisant pour identifier le wiki le nom de sa base de donnée. Attention à utiliser les bons identifiants (administrateur ou simple lecture/écriture) au bons endroits, et à ne pas confondre les identifiants de Cargo et ceux du wiki. Noter que le nom de la base de donnée de Cargo devra être notée dans ce même fichier. La zone pour les identifiants administrateur est repérée par un commentaire.
4. Configuration du wiki
   1. Passer en revue MainSettings.php : regarder notamment les configurations utilisant wgConfig, ce sont celles qui ont tendance à changer entre les wikis. Garder à l’esprit que $lang correspond au sous-domaine utilisé pour accéder au wiki (donc dans truc.dicoado.org il vaudra truc) : ne pas l’utiliser aveuglément s'il ne correspond pas à une vraie langue, en particulier pour wgLanguageCode. Observer aussi les configurations dites "globales" et voir si une ne serait pas inadaptée pour le wiki à créer.
   2. Passer en revue ExtAndMainSettings.php : doit-on charger toutes les extensions ? Leur configuration doit-elle changer de celles par défaut pour notre wiki ? Bien vérifier la configuration CentralAuth du wiki, afin que le SUL y soit bien présent.
5. Lancement du wiki
   1. En utilisant le modèle de base de donnée dans "template/db", donner une structure à la nouvelle base de donnée du wiki.
   2. Lancer maintenance/update.php --wiki <nom de la nouvelle base>, réparer les bugs au besoin.
   3. Changer le .htaccess de la racine du dossier web afin d’autoriser le nouveau nom de domaine.
   4. Se connecter au wiki, vérifier qu'il est bien accessible, que CentralAuth vous authentifie et relie bien votre compte global au wiki, puis qu'il est modifiable.
   5. Enjoy

Ajout d’une version linguistique (partie communautaire)

• But : cette procédure rassemble les actions à faire pour créer une nouvelle communauté dans une langue et lancer un nouveau Dico.
• Résultat : à partir d’un wiki presque vide, on a pu créer une nouvelle déclinaison du Dico des Ados dans la langue sélectionnée, avec une communauté.
• Nécessite : du temps et des personnes motivées pour lancer un wiki, connaissance suffisante dans la langue cible, connaissance suffisante en wikicode et en utilisation de PageForms, connaissance en gestion de communauté.