20 secondes suffisent pour créer un compte. Rejoins-nous ! Clin d’œil

Dico

Dico:Multilingue/Feuille de route

sur le Dico des Ados : ton dictionnaire collaboratif, libre et gratuit !

< Dico:Multilingue
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. Le but est de pouvoir donner à toute personne le nécessitant les clés de réflexion existantes pour devenir multilingue. 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 :

  • nous sommes en date du 14/08/2023 sur un hébergement mutualisé, cela devrait changer mais cela provoque des contraintes pour le moment.

Passage en fonctionnement multilingue (à faire une fois pour toute)[modifier le wikicode]

Mise du Dico en « ferme de wiki »[modifier le wikicode]

  • But : faire en sorte que la configuration du Dico des Ados permette d’ajouter et d’accéder à d’autres wikis, tout en restant sur la même installation de MediaWiki. On utilisera $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, puis en choisissant les variables de configurations à charger ainsi que leurs valeurs.
  • Résultat : le système est capable, à partir du sous-domaine utilisé (xxx.dicoado.org) ou des paramètres données en ligne de 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 de choisir la base de données (qui représente donc le wiki utilisé). Si aucun choix ne peut être trouvé, échouer. ⇒ Fait, il faut que je donne le code déjà réalisé. À vérifier qu'il marche en 1.39. − Rififi
Remarque : les changements listés ici doivent être fait ailleurs (typiquement sur une branche git) afin de ne pas perturber le wiki jusqu’au dernier moment.
☑ Créer une architecture permettant de garder et charger les configs dans un ordre cohérent, en fonction du wiki chargé. Cette architecture concerne à la fois l’organisation du LocalSettings.php et des autres fichiers qu’on inclus, mais aussi des dossiers (par exemple cache/, images/ il en faut un par wiki). ⇒ 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. Chaque wiki a son propre dossier lorsque nécessaire (par exemple cache/ et images/, on a un sous dossier fr, un sous dossier, en etc.). Je dois fournir ce code et cette architecture. − 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). ⇒ C’était en cours, à mettre à jour, je dois fournir le code (j’avais aussi fait des changements de configuration telle que la suppressions de choses inutiles). − Rififi
☐ Relire attentivement la configuration, afin qu’elle soit bien la même (substantiellement) qu’avant. Prêter particulièrement attention aux modifications qu’on peut avoir provoqué. 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 à l’heure actuelle, plus tard dans un fichier.conf adapté) pour être prêt à accueillir de nouveaux wikis. Typiquement, c’est surtout permettre d’ajouter facilement un sous domaine comme "autorisé".
☐ 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), php maintenance/update.php --wiki <bdd de fr>, vérifier que fr.dicoado.org fonctionne toujours, déverrouiller.

Installation d’un système d’authentification centralisé[modifier le wikicode]

  • 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. Lorsque que quelqu’un se connecte à un wiki, il est connecté partout (on n’a pas à se connecter n fois).
  • Nécessite : connaissance en administration système, en base de données, en fonctionnement de MediaWiki et particulièrement du système de centralisation utilisé (CentralAuth ou $wgSharedDB). Il peut être utile d’avoir l’avis de la communauté afin de choisir les solutions adaptées. 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.

⏳ Décider de la méthode à utiliser pour créer un système centralisé. ⇒ L’usage de wgSharedDB semble plus simple, plus concis / fiable, bien que plus rudimentaire. CentralAuth offre plus de fonctionnalités "directement", et est testé par Wikimedia, mais pose des problèmes tels que la maintenance de l’extension qui a parfois laissé à désirer, ou encore cette tâche qui pose un problème de sécurité / vie privée, ou encore le côte inutile pour une grande partie de l’extension (nous n’avons pas de bases utilisateurs à fusionner).
⏳ Tester et configurer correctement la solution choisie. Penser aux données à partager (tables), aux cookies de connexions (avec un $wgCookieDomain réglé sur .dicoado.org → si besoin ne pas hésiter à créer un script qui réinitialise les cookies), et au fait que l’on doit être global uniquement. ⇒ 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, ainsi que pour wgSharedDB dans une moindre mesure. Je peux fournir les "trouvailles". − Rififi
☐ Ailleurs que sur le dico, typiquement sur une branche d’un git, créer la configuration nécessaire pour pouvoir migrer. Préparer la migration (être au point sur la procédure pour pouvoir la faire d’une traite).
☐ Créer une base de données, avec un nom adapté, donner l’accès lecture/écriture à l’utilisateur non admin de MediaWiki pour la version française, et l’accès lecture/écriture/admin pour l’utilisateur admin. Créer au besoin les tables dans la base de donnes créée.
☐ Sauvegarder la base de données, verrouiller au public.
☐ Mettre en place la configuration (mettre à jour les fichiers).
☐ Faire migrer tous les comptes d'une base à l’autre (déplacer les données nécessaires).
☐ Vérifier que le wiki ne s’est pas désintégré, vérifier qu’aucun compte n’est bloqué et que tous ont bien été globalisé (tenter de se connecter, accéder aux pages spéciales de comptes globaux si applicables, faire des actions wikis, vérifier que les sessions n’ont pas besoin de réinitialisation / fonctionnent bien). Rouvrir le site.
☐ Mettre en place les groupes globaux pour les sysadmins (pas besoin de tout configurer maintenant, mais au moins les sys).

Création d’un Wiki « central » (ou autre nom)[modifier le wikicode]

  • 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 globales seront modifiées/effectuées sur ce wiki, et les politiques globales s’y trouveront). Il servira pour le repertoire centralisé d’images, mais on ne s’en occupe pas pour le moment.
  • Résultat : un wiki est créé, langue de base = anglaise. Il sert à toute action qui concerne tous les wikis.
  • Nécessite : connaissance en sysadmin, en base de données, en gestion de wikis, connaisse un minimum le Dico (les habitudes de la communauté un peu). 1 sys min., un deuxième en backup n’est pas de trop.

☐ Être au clair sur la procédure de création de wiki ainsi que ses prérequis (voir ci-dessous), elle doit être utilisable en entier et d'une traite.
☐ Suivre la procédure de création d’un wiki (partie technique). Ce wiki sera en anglais, appelé Central Dicoado (à changer le nom peut-être). 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. Une fois le wiki créé, tester de fond en comble (ça sera le premier wiki créé et ajouté à la ferme).
☐ Donner les droits admins/bubus sur ce wiki 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.
☐ Faire en sorte que ce wiki soit considéré comme celui central (que ça soit au niveau des liens sur les autres wikis comme la page téléverser, les pages d’aides, au niveau technique aussi si nécessaire). Réserver ay possible les actions globales à ce wiki. Typiquement, pour CentralAuth, le régler pour considérer ce wiki comme le "meta/central" : la page d’exception pour le verrouillage global doit être une page de ce wiki, etc.
☐ Configure les permissions globales en entier (admin global = admin local), et les attribuer. Garder central en restreint en attendant qu’il soit prêt à l’usage au niveau des fichiers par exemple.
☐ (non technique, à faire aussi plus tard) Expliciter les politiques globales du dico, adapter les messages, les règles, ce qui s’affiche. Petite suggestion : installer Translate dans le but d’avoir des pages dans plusieurs langues (un peu complexe).


Installation d’un répertoire centralisé de fichiers[modifier le wikicode]

  • But : utiliser central en répertoire de fichiers utilisé par tous les autres wikis de la ferme. Les autres wikis ne devront pas avoir la possibilité de posséder de fichiers locaux . Le lien à Wikimedia Commons ne doit pas être affecté (on doit pouvoir continuer à utiliser des fichiers de Commons, sous contrôle).
  • Résultat : l’importation et l’utilisation des fichiers sur les wikis de la ferme n’est possible qu’à travers le wiki centralisé ou Wikimedia Commons. Attention : en conséquence, les fichiers du wiki français devront donc être déplacés vers le wiki central.
  • Nécessite : 1 sysadmin, bonne 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 (pour le déplacement des fichiers). 1 sys min. mais 2 pas de trop.

☐ (en amont à réfléchir bien avant de commencer la migration effective) Réfléchir à un script capable de transférer les fichiers présentes sur fr vers central. Extension utile à connaître : FileImporter, qui permet de transférer proprement un fichier. Il serait bien de pouvoir supprimer définitivement les fichiers sur fr afin de ne pas garder dans les archives des doublons sans intérêt (à voir comment faire). Tester en local tant qu'à faire...
☐ Configurer (d'abord sur git, puis sur le dico quand c'est prêt) un répertoire partagé ($wgSharedRepo) en utilisant l'option "base locale" vers le wiki central. Garder également le lien avec Commons ! ⇒ J’y ai déjà travaillé et ai une configuration normalement fonctionnelle sur laquelle se baser. Je peux fournir les codes. − 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.

Passage en global des paramètres et des extensions qui le peuvent[modifier le wikicode]

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

Création des autres langues initiales (en, de, it, ro)[modifier le wikicode]

  • But : créer 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 et maitrisant ses particularités linguistiques, un sys prêt à configurer les wikis, un Vivian chaud bouillant pour lancer un Dico des Ados dans une nouvelle langue.

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

Page d’accueil principale[modifier le wikicode]

  • 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)[modifier le wikicode]

Ajout d’un wiki (partie technique)[modifier le wikicode]

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, connaisse un peu le dico. Sachant que si on est toujours sur infomaniak, il faudra que la personne s’adapte. 1 autre en backup ne sera pas de trop.
  • Prérequis : avoir une base VIDE sous la version de MediaWiki correspondante (actuellement 1.35.11), 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)[modifier le wikicode]

  • 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 le geste)
  2. Donner les premiers droits utilisateurs locaux aux personnes motivées (à décider par les développeurs / bureaucrates globaux).
  3. Traduire l’interface (notamment les messages systèmes modifiés)
  4. 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 Aide:Modèles et redBox).
  5. Configurer les messages systèmes (espace de nom MediaWiki:) copyrightwarning, editpage-tos-summary, protect-* et protected*
  6. À partir de là, le dictionnaire est rendu utilisable. Ne pas hésiter à le dire sur les réseaux et sur MediaWiki:Sitenotice.
  7. Configurer les sémantics : Cargo, MediaWiki Semantics.
  8. Créer les premières pages d’aides, organiser les pages de demandes, tout en créant de nouveaux mots. Laisser la communauté grandir.
  9. Collaborer avec Myriam Thomas : d’autres Dicoo peuvent être créés pour la langue cible et les cultures qui y sont liées.