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 (ni finie), 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.

Remarques :

• il est rappelé que nous sommes actuellement sur un hébergement mutualisé. Si cela donne certains avantages, il est clair que certaines actions sont soit limitées soit doivent passer par une interface graphique.
• il y a des fautes, veuillez m’en excuser

Passage en fonctionnement multilingue (à faire 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 servir 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 aucun choix ne peut-être trouvé, é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
☐ Transformer l’ancienne configuration et la mettre avec la nouvelle architecture, effectuer les modifications qui permettront plus tard de servir d’autres wikis (notamment les dossiers de cache ou de téléversement, un par wiki). ⇒ Presque terminée − Rififi
☐ Relire attentivement la configuration, afin qu’elle soit bien la même (substantiellement) qu’avant. Prêter particulièrement attention aux modifications effectuées 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, le renommage des chemins…)
☐ Adapter la configuration Apache actuelle (.htaccess dans la racine du dossier web, rappel hébergement mutualisé) 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 (c-à-d la pérennité dans les bases locales des mots de passes et adresses mails changés en global) puissent ê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 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 ? En tout cas me demander pour les travaux réalisés. − Rififi
☐ Créer une base de données, nommée en toute originalité centralauth ou centraldb, donner l’accès lecture/écriture à l’utilisateur non admin de MediaWiki pour la version française, et l’accès/écriture/admin pour la l’utilisateur admin (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 la configuration choisie) et installer CentralAuth (une procédure précise et concise, se basant sur la config choisie et les tests, est à venir). Remarque : ne pas à priori faire la requête à la base de données pour donner les droits utilisateurs globaux pour le moment, contrairement à ce que dit la doc. Ne créer que le groupe local développeur et le migrer (appelé steward dans la doc). 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 $wgCookieDomain réglé sur .dicoado.org). Au besoin, créer un script PHP 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é (tenter de se connecter, accéder à special:globalaccount, modifier, vérifier que les sessions n’ont pas besoin de réinitialisation / fonctionnent bien). 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éé, langue de base = anglaise. 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) sur cette page (plus bas). 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, SemanticMediaWiki, Cargo… des économies peuvent être faites sur ce point.
☐ Donner les droits admins/bubus sur central aux devs seuls pour le moment.
☐ Fermer l’écriture du wiki au public pour le moment, ne laisser qu’aux développeurs pour le mettre en place.
☐ 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. Créer à ce moment le premier groupe global (développeur) mais sans la possibilité de modifier les droits globaux. Donner la possibilité dans les droits locaux seulement de modifier les droits globaux (grâce à la permission globalgrouppermissions).
☐ (Plus tard, non bloquant) expliciter les politiques globales du dico, adapter les messages et l’interface, et probablement installer Translate dans le but d’avoir des pages dans plusieurs langues.

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 et fusions globaux (essentiel) : vérifier la procédure de renommage et de fusion d’un compte utilisateur global.
  • Vérifications d’utilisateurs globales (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 (sur CentralAuth : Special:GlobalGroupPermissions) : créer des groupes globaux (développeur, bureaucrate global, administrateur+ global, administrateur global). Les permissions globales ne doivent être modifiables que sur le wiki central pour la pouvoir garder trace facilement (ne donc donner la permission globalgrouppermissions qu'à un groupe local de central, à priori, à voir comment cela se fait). Nommer les premiers utilisateurs avec des permissions globales (Special:GlobalGroupMembership). Bien vérifier la cohérence + ne pas s’y perdre entre les permissions globales et les permissions locales à central (peut-être qu’un groupe local développeur peut-être envisageable sur Central ?)
☐ Blocages globaux : à vérifier qu’ils fonctionnent comme voulus, réfléchir à des politiques, s’assurer que tout soit fait sur central (special:centralauth).
☐ Configurer, vérifier le système de renommage global. CentralAuth fourni un système de demande (special:GlobalRenameRequest), s’il convient alors rediriger les demandes vers celui-ci. De même, s’assurer que les actions soit faites sur central. Voir aussi pour la fusion des comptes (special:globalusermerge).
Les quatre points suivants ne sont pas obligatoires pour passer à la suite :
☐ Vérifications d’utilisateurs globales : décider si oui ou non on le fait, si oui alors le configurer avec CheckUser et créer un groupe "vérificateur d’utilisateur global" (ou bien vérificateur d’utilisateur tout court qui ne deviendrait qu’un groupe global, à décider). Même remarque pour réaliser tout ceci sur le wiki central.
☐ Notifications globales : à mettre en place avec l’extension Echo, en utilisant la base centrale.
☐ Filtres globaux : à mettre en place avec AbuseFilter, de même tout sur le wiki central.

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.
• Nécessite : compétence en l’utilisation de MediaWiki et d’une base de données d’un wiki, compétence en réalisation d’un script. 1 sys min. mais 2 recommandé.

☐ (en amont à réfléchir bien avant de commencer la migration effective) Réfléchir à un script capable de transférer les images présentes sur fr vers un autre wiki. Extension utile à connaître : FileImporter, qui permet de transférer proprement une image. Il serait bien de pouvoir supprimer définitivement les images sur fr afin de ne pas garder dans les archives des doublons sans intérêt.
☐ Décider si le wiki « répertoire d’image » sera central ou un autre.
☐ Configurer un répertoire partagé ($wgSharedRepo) en utilisant une base locale, qui pointe vers le wiki cité plus haut. Garder également le lien avec Commons ! ⇒ J’y ai déjà travaillé et ais une configuration normalement fonctionnelle sur laquelle se baser − Rififi
☐ Désactiver le téléversement des fichiers partout sauf sur le wiki répertoire.
☐ Faire en sorte que la page spécial:téléverser de chaque wiki pointe vers le wiki central ($wgUploadNavigationUrl).
☐ Migrer les fichiers avec le script créé plus haut. Bonne chance, compagnon.

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.
• Nécessite : des gens motivés, des gens parlant la langue, un sys prêt à configurer les wikis, un Vivian chaud bouillant pour lancer un autre Dico des Ados.

Suivre les procédures de création de wiki puis de wiki linguistique.
☐ Anglais
☐ Allemand
☐ Italien
☐ Romanche

Page d’accueil : [1]

• But : pour le moment cette page redirige vers fr.dicoado.org, l’idée est de faire une page d’accueil multilingue pour diriger les gens.
• Résultat : une page d’accueil belle, multilingue, mais qui doit aussi avoir été pensée pour les personnes ayant suivi un vieux lien (donc qui s’attendent à tomber sur la version française).
• Nécessite : développement site web (HTML5 / CSS3 / PHP), designer. 1 dev 1 designer (ou une personne qui sait gérer les deux).
  

⏳ Choisir le design. Penser à utiliser les Dicoo de Myriam Thomas. Avoir un design simple. Lazysnail est sur le coup
⏳ Le développer
☐ À savoir qu’il sera aussi intéressant de créer les pages d’erreurs (400/404/403/500/503), en plusieurs langues, avec un message aidant l’utilisateur (typiquement quelqu’un qui tape fr.dicoado.org/wiki/mot au lieu de fr.dicoado.org/dico/mot).

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

Ajout d’un wiki (partie technique)

Une procédure plus précise encore est à venir. Une version anglaise sera probablement produite aussi.

• 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 (***_*******_$code)
   2. Créer un utilisateur avec lecture/écriture sur la base de données tout juste créée, ainsi que sur la base de données 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ées pour cette extension ; 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ées 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ées de Cargo devra être indiquée dans ce même fichier. La zone pour les identifiants administrateur est repérée par un commentaire. Générer une clé aléatoire (procédure à venir) et la mettre dans wgSecretKey.
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 (c’est $code, 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. En rapport avec la langue cible du wiki et son usage, voir les espaces de noms à créer et leurs raccourcis.
   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ées dans "template/db", donner une structure à la nouvelle base de données 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é pour un Dico des Ados dans une nouvelle langue.
• 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 (y compris orthographique et grammaticale), connaissance suffisante en wikicode et en utilisation de PageForms, connaissance en gestion de communauté.
• Préréquis : avoir installé un wiki vide, en utilisant les noms localisés adaptés (wgSitename, wgMetaNamespace).

Pendant toute l’opération tout bug est bien entendu à signaler aux sysadmins.

1. Créer un mot (même sans aucun modèle / formulaire de disponible, juste pour l’honneur)
2. Donner les premiers droits utilisateurs locaux aux personnes motivées (à décider par les développeurs / bureaucrates globaux).
3. Créer la page d’accueil (la protéger), la page de discussion principale (analogue à Dico:Salon), ensuite le formulaire PageForms pour la création de mot (Form:Ajouter un mot) et le modèle qui va avec (voir les modèles utilisés sur un mot du dico en français) (les protéger). Importer (attention aux licences) les feuilles de style / scripts nécessaires, ainsi que les modèles basiques (ceux permettant de réaliser les articles, on peut aussi voir redBox).
4. Configurer les messages systèmes (espace de nom MediaWiki:) copyrightwarning, editpage-tos-summary, protect-* et protected*
5. À partir de là, le dictionnaire est rendu utilisable. Ne pas hésiter à le dire sur les réseaux et sur MediaWiki:Sitenotice.
6. Configurer les sémantics : Cargo, MediaWiki Semantics.
7. Créer les premières pages d’aides, organiser les pages de demandes, tout en créant de nouveaux mots. Laisser la communauté grandir.
8. Collaborer avec Myriam Thomas : d’autres Dicoo peuvent être créés pour la langue cible et les cultures qui y sont liées.