Wikisource:Questions techniques

Vous êtes ici : accueil >Aide >Questions >Questions techniques

Questions
Raccourci [+]
WS:S


Choix éditoriaux
Contenu des livres, mise en page, typographie, etc.


Questions techniques
Utilisation de Wikisource, de la syntaxe d'édition, de l'interface.


Questions légales
Droits d'auteurs sur les livres et questions juridiques.


Questions sur les Glyphes & caractères
Codage et représentation des glyphes et caractères.


Scriptorium
(Mois en cours, Archives, discussion générale en anglais)
Pour laisser un message qui ne concerne pas les cas cités.
Communauté : Forum des nouveaux - Annonces - Projets - Actualités - Newsletter technique - Pages à supprimer



l'OCR sur la barre d'outils

modifier

Quel script est la source de l'OCR sur la barre d'outils, du l'éditeur source, de ce wiki? Je voudrais le lier à partir de la Wikisource anglaise.—Ineuw 2 janvier 2020 à 20:11 (UTC)[répondre]

Erreur du bouton T

modifier

Je viens de faire plusieurs fois (la dernière ici) l’expérience d’une erreur (sporadique) du bouton T : il a corrigé plusieurs occurrences de deux point (:) ou de points-virgules (;), en supprimant les espaces avant ou après, pourtant nécessaires en typographie du français ! Merci d’avance pour un conseil ou un correctif. Fabrice Dury (d) 27 janvier 2020 à 08:30 (UTC)[répondre]

  Fabrice Dury :Cela arrive dans certains cas, quand on a une syntaxe utilisant des guillemets clavier (pas toujours cependant, mais quand ça se passe, c'est toujours qu'il y a quelque chose comme ça) : personnellement, j'utilise toujours le gadget avant de mettre en place ces éléments de syntaxe. --Acélan (d) 4 février 2020 à 09:45 (UTC)[répondre]
Merci pour l’explication. Il serait mieux, tout de même, que le défaut soit évité inconditionnellement, donc que le bouton T soit corrigé. Cordialement. Fabrice Dury (d) 4 février 2020 à 09:52 (UTC)[répondre]

Non affichage des pages d'un fac-similé

modifier

Bonjour,

Les pages de l'ouvrage L’isotopie et les éléments isotopiques de Marie Curie ne s'affichent pas, c'est peut-être lié au fait que j'ai chargé l'ouvrage hier alors que certains serveurs de la Wikimedia Foundation rencontraient des problèmes (d'après ce que j'ai pu voir sur Twitter). Savez-vous comment régler ce problème ?

--George2etexte (d) 27 janvier 2020 à 18:01 (UTC)[répondre]

Export pdf => changement de format ?

modifier

Bonsoir,

J'ai des différences de format sur des exports réalisés ce soir avec l'outil "Télécharger en PDF" en haut de page… En effet, la mention "Exporté de Wikisource le …" apparait deux fois de suite (la deuxième sur une page presque vide), et les marges semblent maintenant beaucoup plus importantes que précédemment…

Est-ce un bug de fonctionnement pour ce soir ? des tests en cours ? ou bien un changement définitif dû à une évolution de l'outil ?? Si c'est un changement définitif, cela ne m'arrange pas, car je formate souvent les deuxièmes de couverture, et les pages de présentation en fonction de ce que cela donne à l'export…

Y-a-t-il moyen de revenir en arrière ??? Enfin, l'idéal serait peut être de pouvoir paramétrer la marge comme on veut !?

merci si vous avez des explication sur ce phénomène  

--Lorlam (d) 3 février 2020 à 22:31 (UTC)[répondre]

  Hsarrazin : Hélène, le changement de format d'export se confirme aujourd'hui… sais tu si c'est une modification définitive de l'outil ? merci --Lorlam (d) 4 février 2020 à 19:11 (UTC)[répondre]
  Lorlam : pas la moindre idée... peux-tu, stp, me mettre le lien vers la page du livre sur lequel tu as ce problème ?
  Tpt : y a-t-il eu des changements sur WSexport ? --Hélène (dite ''le bot de service'') (d) 5 février 2020 à 09:10 (UTC)[répondre]
  Hsarrazin : Je me suis aperçu du changement en faisant un export sur le livre sur lequel je travaille en ce moment : Michel Strogoff (théâtre 1881), mais j'ai vu après que cela impactait en fait tous les livres… D'où ma question… Pour moi, il est clair que l'export ne "marche" pas comme avant (je le constate encore aujourd'hui)… maintenant, je ne sais pas si c'est une évolution "volontaire" ou bien un bug !!! a+ --Lorlam (d) 5 février 2020 à 09:53 (UTC)[répondre]
La version de Calibre utilisé pour générer les PDFs à partir de l'ePub a été mise à jour. C'est sans doute l'origine des différences. Cela devrait être possible de configurer les marges pour faire en sorte qu'elles reste les même qu'avant. Je vais creuser cela. Tpt (d) 5 février 2020 à 13:47 (UTC)[répondre]
  Hsarrazin et Tpt : Oui, merci beaucoup Tpt… en effet ce serait bien de revenir aux marges d'avant   a+ Laurent --Lorlam (d) 5 février 2020 à 19:43 (UTC)[répondre]
  Tpt : À propos, Tpt, en dehors du "problème" de marge, il y a aussi le fait que la mention "Exporté de Wikisource le xxx" s'affiche deux fois : une fois au bas de la page 3 de l'export (normal)… et une deuxième fois sur une page 4 qui apparaît du coup intempestivement… Tiens nous au courant des corrections si c'est possible… merci encore. Laurent --Lorlam (d) 7 février 2020 à 17:03 (UTC)[répondre]
  Hsarrazin et Tpt : re-bonjour… je reviens de quelques jours de vacances et j'ai re-tenté l'export pdf => le résultat a encore changé depuis une semaine, mais les marges sont toujours très larges ! a+ Laurent --Lorlam (d) 15 février 2020 à 23:08 (UTC)[répondre]
  Hsarrazin et Tpt : re-re-bonjour… Autre chose, j'ai l'impression qu'il y a quelquefois un "bug" sur l'extraction de la page de garde ; par exemple sur le livre Le Secrétaire et le Cuisinier => j'ai fait un export, mais il y a un message d'erreur quand on ouvre le fichier avec Acrobat Reader : "Données insuffisantes pour une image"… Avant, l'export de cette même page marchait très bien… a+ Laurent --Lorlam (d) 16 février 2020 à 01:04 (UTC)[répondre]
  Lorlam : Calibre a été en effet mis à jour vers la version 4 depuis une semaine. Sam Wilson viens de mettre sur la version test de l'outil un correctif pour les marges. N'hésite pas à le tester. Je regarde pour la page de garde. Tpt (d) 17 février 2020 à 11:14 (UTC)[répondre]
  Tpt : Tpt : oui, j'ai testé la version "test" en mode pdf A5 (la plus proche du résultat de l'ancien outil) => les marges sont "ok", par contre, la police de caractères est un peu différente d'avant (taille un tout petit peu plus grosse, mais pas plus lisible car caractères un peu moins épais)… par contre, il y a là aussi le problème d'export de l'image de première page, qui est gênant ! (voir par exemple sur cette page : Le Château de la Poularde)… s'il y a des essais de correction ultérieurs, je veux bien tester à nouveau pour aider   a+ --Lorlam (d) 17 février 2020 à 20:12 (UTC)[répondre]
  Tpt : Tpt : juste pour savoir ; tu as pu reproduire et constater ce "bug" sur l'extraction de la page de garde qui donne à la lecture du fichier pdf le message "Données insuffisantes pour une image" ?… Personnellement je le constate sur tous les textes qui font partie d'un volume plus gros, comme par exemple les pièces de théatre de Scribe : Le Secrétaire et le Cuisinier / Le Coiffeur et le Perruquier / etc… a+ Laurent --Lorlam (d) 19 février 2020 à 13:22 (UTC)[répondre]
  Hsarrazin et Tpt : Tpt : Désolé d'insister, mais, n'y aurait-il pas moyen de remettre "temporairement" l'ancien outil d'export, qui marchait très bien ??? (en attendant que les problèmes de celui-ci soient résolus). Car, c'est quand même dommage de ne pas pouvoir export proprement en "pdf" depuis plusieurs semaines… a+ Laurent --Lorlam (d) 23 février 2020 à 09:45 (UTC)[répondre]
  Lorlam : - merci de ne pas continuer à me pinguer sur ce problème... je n’ai aucune compétence technique en la matière   --Hélène (dite ''le bot de service'') (d) 24 février 2020 à 11:01 (UTC)[répondre]
  Lorlam : je viens de finaliser un correctif pour l'affichage de la première page. Il est en attente d'une seconde vérification de la part de Sam pour (re)vérifier le changement avant déploiement. Tpt (d) 1 mars 2020 à 11:37 (UTC)[répondre]
  Tpt : Super Tpt, entre cette correction et celle des marges, on va bientôt pouvoir ré-exporter en obtenant un résultat satisfaisant ! c'est à mon sens important pour valoriser le travail de tous les contributeurs qui participent pour mettre à disposition des œuvres sur WS… merci beaucoup en tout cas, pour tout le travail technique nécessaire à la correction de l'outil   Et puis, je suis preneur de l'info du futur déploiement de la version ad-hoc. A+ Laurent --Lorlam (d) 1 mars 2020 à 12:53 (UTC)[répondre]
  Tpt : Tpt, je viens de re-faire des exports "pdf" => le problème des marges est maintenant résolu… par contre, le problème d'affichage de la première page subsiste sur certains livres… Je suppose que ta correction n'est pas encore implémentée… y-a-t-il moyen de la vérifier quelquepart sur une version de test ??? a+ Laurent --Lorlam (d) 7 mars 2020 à 13:48 (UTC)[répondre]
  Tpt : et   Lorlam : Bonjour! je pense avoir identifié une source à ce problème d’affichage de la première page de certains fichiers PDF.
Les ouvrages testés ont tous en commun une image-couverture codée sur 8 bits. Il s’agit de:
  • Histoire de Rouyn
  • Le Secrétaire et le Cuisinier
  • La région du lac Saint-Jean, grenier de la province de Québec
  • Lionel Duvernoy
Résultat obtenu: dans tous les cas, le message « Données insuffisantes pour une image » est lancé systématiquement à chaque ouverture du fichier exporté ou converti en format PDF
Deuxième test effectué: insertion dans MS Word des fichiers cover.jpg (8 bits) et impression avec Print to PDF. Toujours le même résultat : « Données insuffisantes pour une image »
Troisième test avec les fichiers cover.jpg rééchantillonnés en 24 bits: conversions en PDF réussies tant avec Calibre qu’avec Word (Print to PDF).
Quatrième test effectué avec les fichiers reconvertis en 8 bits => le problème revient
Cette incompatibilité avec une image codée sur 8 bits a été signalée récemment et corrigée par Autodesk et par Microsoft dans SQL Server.
Solution proposée: Je m'en remets à toi, Tpt, pour évaluer la pertinence de rééchantillonner sur 24 bits directement dans wsexport. Je ne m’y connais pas du tout en PHP mais peut-être essayer avec « Imagick::getImageDepth » et « Imagick::setImageDepth » dans la fonction « getCover( $cover, $lang ) » ?? En même temps, si possible, envisager une augmentation de la taille de cover.jpg qui doit s'étirer sur toute l'étendue de la première page d’un PDF. L'image par défaut dans Calibre a une largeur de 600px. Merci et souhaitons que cet irritant puisse être corrigé.--Denis Gagne52 (d) 8 mars 2020 à 19:03 (UTC)[répondre]
  Tpt : et   Denis Gagne52 : re-bonjour à vous deux… personnellement, je n'y connais rien, mais il semble que le problème ne soit pas simple à résoudre… avez-vous une version de test quelquepart ? merci a+ Laurent --Lorlam (d) 15 mars 2020 à 13:40 (UTC)[répondre]
  Tpt : pas de nouvelles ? a+ --Lorlam (d) 28 mars 2020 à 09:36 (UTC)[répondre]
  Lorlam : Dans ses commentaires à Sam Wilson datées du 3 mars,   Tpt : mentionne qu’il obtient trois images couverture dans le pdf du livre « Le Secrétaire et le cuisinier » alors que, de notre côté, on reçoit plutôt un message d'erreur « Données insuff… », la première page refusant de s’afficher sur une image en ton de gris.
La correction semble donc viser l’affichage multiple qui pourrait aussi être solutionné en modifiant le fichier « content.opf » de la façon suivante :
manifest
item id="cover" href="cover.xhtml" media-type="application/xhtml+xml" properties="calibre:title-page"
.....
/manifest
spine toc="ncx"
itemref idref="cover" linear="yes"
mais ce problème me semble différent de celui que nous avions signalé. À suivre. --Denis Gagne52 (d) 3 avril 2020 à 04:27 (UTC)[répondre]
Il y a en effet deux problèmes, l'affichage multiple et le "données insuffisantes" qui affectes quelques lecteurs PDFs. Pour l'affichage multiple, je viens de déployer un correctif. Au lieu de modifier le content.opf tel que suggéré par Denis Gagne52 (merci !), j'ai remplacer le fichier cover.xhtml par l'image de couverture directement. Comme cela, il n'y a pas à jouer avec le CSS pour afficher l'image en pleine page et Calibre n'a pas la tentation de placer le fichier XHTML à la fin du PDF en croyant qu'il fait partie du contenu du fichier. Pour les données insuffisantes, merci de l'idée d'utiliser Imagic, je suis en train d'écrire un patch avec. Tpt (d) 6 avril 2020 à 10:35 (UTC)[répondre]
  Lorlam :. Je viens d'écrire un correctif. Est-ce que ce fichier PDF fonctionne chez toi pour confirmer que le problème est corrigé avant que je pousse le correctif ? Tpt (d) 6 avril 2020 à 10:47 (UTC
  Tpt : oui c'est bon :-) Yessssssssssss !!!!!!!! --Lorlam (d) 6 avril 2020 à 11:33 (UTC)[répondre]
Coucou   Tpt : Alors, tu as pu "pousser" ton correctif ? Y-a-t-il un lien quelquepart pour pouvoir l'utiliser en version de test ??? a+ --Lorlam (d) 11 avril 2020 à 18:59 (UTC)[répondre]
  Lorlam : Le correctif est déployé sur les serveurs. Notifie moi si tu vois un problème quelconque. Désolé du temps d'attente. Tpt (d) 19 avril 2020 à 07:39 (UTC)[répondre]
  Tpt : Je suis vraiment désolé… j'ai essayé d'utiliser l'export… mais pour moi ça ne marche toujours pas… en fait je ne vois aucun changement… tu es sûr que ton correctif a bien été déployé sur le serveur ??? J'ai essayé sur les pages Le Codicille et Le Mystificateur et la page de garde n'apparait pas… tu peux certainement le voir par toi même !? snif……. en espérant que ce n'est qu'un contre-temps. a+ Laurent --Lorlam (d) 19 avril 2020 à 08:50 (UTC)[répondre]
  Lorlam : Désolé, il y a peut-être un malentendu. En ePub l'image de couverture extraite automatiquement du PDF/DjVu n'est pas supposée être affiché lors de la lecture mais seulement dans la navigation des liseuses, de Calibre... Le convertisseur ePub vers PDF l'ajoute en première page du PDF. La page de garde avec le moine copiste doit être la première page de l'ePub lors de la lecture et la seconde du PDF. Es-ce que tu as toujours le problème de crash lors de l'ouverture du PDF ou est-ce autre chose ? Le serveur est à jour et utilise le même code que le PDF de référence que je t'ai envoyé avec seulement une version de Calibre plus récente. Tpt (d) 19 avril 2020 à 13:12 (UTC)[répondre]
  Tpt : À mon tour d’être désolé, je constate aussi que la conversion de l’image couverture ne fonctionne pas avec « Imagick::setImageDepth » comme je l’avais espéré car la profondeur est de 8 bits partout. Ce qui diffère c’est uniquement le nombre de canaux ( 1 -> 3 ). Dans ce cas, il faudrait plutôt utiliser [Imagick::getImageType] pour rechercher les images de type 2 ou « Imagick::IMGTYPE_GRAYSCALE » et les convertir en utilisant [Imagick::setImageType] avec en paramètre 6 ou « Imagick::IMGTYPE_TRUECOLOR ». --Denis Gagne52 (d) 19 avril 2020 à 13:49 (UTC)[répondre]
  Tpt : Je ne pense pas qu'il y ait de malentendu… en pdf, la page avec le moine copiste apparait effectivement bien en 2e page, et la première page sensée montrer l'image de couverture issue du DjVu ne s'affiche pas… par contre il y a un message d'erreur à l'ouverture du pdf : "Données insuffisantes pour une image" (le même qu'il y a deux mois). Pourtant, le pdf que tu m'avais joins le 11 avril était "ok" => il y a donc une différence entre ces deux outils !… j'avais bon espoir que ça marche, mais ce n'est pas pas encore gagné. :-( a+ Laurent --Lorlam (d) 19 avril 2020 à 17:16 (UTC)[répondre]
Re-bonjour   Tpt : c'est bon tu as pu visualiser le problème ? Apparemment tu avais pu le corriger dans un cas précis, puisque le fichier que tu m'avais transmis il y a quelques temps était "ok"… mais le soucis vient peut être des différentes versions de calibre qui ne sont pas compatibles entre elles, et qui apportent des régressions, ou du moins des fonctionnements différents !? Mais bon… je ne peux pas aider plus que ça car je ne connais rien à cet outil… je suis juste impatient de pouvoir l'utiliser   a+ --Lorlam (d) 22 avril 2020 à 17:19 (UTC)[répondre]
  Lorlam : J'ai mis en place le correctif dans wexport. Il est maintenant live sur https://wsexport-test.wmflabs.org/ . Fonctionne-t-il ?   Denis Gagne52 : Merci pour le correctif ! N'hésite pas à faire des "pull request" dans le code https://github.com/wsexport/tool/ si tu en as envie. Cela serait plus que bienvenu. Tpt (d) 25 avril 2020 à 12:43 (UTC)[répondre]
  Tpt : Merci beaucoup de te pencher sur le problème… celà dit, j'ai essayé d'exporter plusieurs livres en mode "pdf A5 format (in beta)"… (par exemple Le Codicille et Le Mystificateur)… et pour moi ça ne marche pas !!! :-( a+ Laurent --Lorlam (d) 25 avril 2020 à 13:33 (UTC)[répondre]
  Tpt : J’aimerais bien pouvoir contribuer davantage mais ne m’y connais pas assez en PHP. Pourrais-tu apporter la modification suivante à ton correctif de ce matin: « $imagic->setImageType( Imagick::IMGTYPE_TRUECOLOR ); » au lieu de « $imagic->setImageDepth( Imagick::IMGTYPE_TRUECOLOR ); ». Merci --Denis Gagne52 (d) 25 avril 2020 à 14:05 (UTC)[répondre]
  Denis Gagne52 : Merci ! J'ai apporté la modification. J'aurais dû faire attention à ce que je faisais...   Lorlam : J'ai apporté le correctif de Denis sur https://wsexport-test.wmflabs.org/ , pourrais-tu le réessayer ? Tpt (d) 26 avril 2020 à 04:48 (UTC)[répondre]
  Tpt : La conversion ne se fait toujours pas. Il va falloir sortir l’artillerie lourde. Ne te décourage surtout pas. On va y arriver. Je te propose donc :
— d’élargir le filtre à « Imagick::IMGTYPE_GRAYSCALEMATTE » ou « Imagick::IMGTYPE_GRAYSCALE » ;
— on laisse tomber setImageType() qui ne semble agir que sur l’en-tête du fichier et on remplace par $imagic->transformImageColorspace( imagick::COLORSPACE_SRGB );
— prévoir libérer la mémoire après avoir sauvegardé le fichier: « $imagic->clear(); »
Tu peux me répondre sur ma page personnelle et je m’empresserai de tester. --Denis Gagne52 (d) 26 avril 2020 à 14:32 (UTC)[répondre]
  Tpt : et   Denis Gagne52 : En effet ̧ça ne marche pas encore… merci à vous deux pour vos essais… et n'oubliez pas de me mettre dans la boucle si ça avance, ou si vous voulez un testeur :-) a+ Laurent --Lorlam (d) 26 avril 2020 à 21:44 (UTC)[répondre]
  Denis Gagne52 : Le serveur de test a le nouveau correctif. Cela marge pour toi ? Tpt (d) 27 avril 2020 à 04:39 (UTC)[répondre]
  Tpt : "Chez moi" ça ne marche pas encore… désolé… Sinon, continue à me mettre en "ping" quand tu as du nouveau, merci :-) a+ Laurent--Lorlam (d) 27 avril 2020 à 12:17 (UTC)[répondre]
  Tpt : Pour ne pas décevoir   Lorlam : qui ne perd pas espoir malgré nos tentatives infructueuses, j’ai finalement installer Imagick sur mon poste de travail et mis la main sur la baguette magique pour finaliser ce travail de conversion. Sur Windows, je dois procéder par ligne de commande mais les mêmes commandes sont disponibles dans tous les environnements. J’ai testé avec l’image couverture de Le Secrétaire et le Cuisinier. La conversion sur 24 bits a réussi avec l’équivalant en ligne de commande de « Imagick::setImageType » que tu avais pourtant testé avec la bonne syntaxe. Pour m’assurer du résultat j’ai produit un pdf de l’image obtenue soit « scribe_TrueColor.jpg » et l’affichage se fait normalement. Voici quelques détails techniques qui pourraient t’être utiles.
Commandes Imagick utilisée pour la conversion et résultats obtenus
magick "scribe_Grayscale.jpg" -type "TrueColor" "scribe_TrueColor.jpg"
Magick identify –verbose "scribe_Grayscale.jpg" Magick identify –verbose "scribe_TrueColor.jpg"

Image: scribe_Grayscale.jpg

 Format: JPEG (Joint Photographic 
         Experts Group JFIF format)
 Mime type: image/jpeg
 Class: PseudoClass
 Geometry: 400x565+0+0
 Units: Undefined
 Colorspace: Gray
 Type: Grayscale
 Base type: Undefined
 Endianness: Undefined
 Depth: 8-bit
 Channel depth:
   Gray: 8-bit
 Channel statistics:
   Pixels: 226000

 Colors: 256

Image scribe_TrueColor.jpg

 Format: JPEG (Joint Photographic 
         Experts Group JFIF format)
 Mime type: image/jpeg
 Class: DirectClass
 Geometry: 400x565+0+0
 Units: Undefined
 Colorspace: sRGB
 Type: Grayscale
 Base type: Undefined
 Endianness: Undefined
 Depth: 8-bit
 Channel depth:
   Red: 8-bit
   Green: 8-bit
   Blue: 8-bit
 Channel statistics:
   Pixels: 226000
    ….
 Colors: 256
Et ma dernière proposition : soit tu procèdes par ligne de commande, solution moins élégante mais qui fonctionne ou tu persistes avec setImageType en t’inspirant de l’exemple 5 sur cette page qui décrit un subterfurge pour forcer la main au récalcitrant Imagick. Croisons-nous les doigts. --Denis Gagne52 (d) 27 avril 2020 à 21:33 (UTC)[répondre]
  Denis Gagne52 : J'ai mis ta dernière proposition en place. J'espère que cela va marger maintenant   Lorlam :. Tpt (d) 28 avril 2020 à 04:47 (UTC)[répondre]
  Tpt : et   Denis Gagne52 : Encore désolé, mais pour moi ça ne marche pas mieux :-( --Lorlam (d) 28 avril 2020 à 09:17 (UTC)[répondre]
  Tpt : Que se passe-t-il ? Je n’arrive pas à trouver tes derniers changements sur Github. Les changements à la « branch jpeg » semblent remonter à 3 jours. Peux-tu m’orienter ? Merci. --Denis Gagne52 (d) 28 avril 2020 à 12:50 (UTC)[répondre]
  Denis Gagne52 et Lorlam : J'avais oublié de pousser mes dernières modifications... J'aurais dû faire attention. Le serveur de test devrait être maintenant à jour. Tpt (d) 29 avril 2020 à 06:04 (UTC)[répondre]
  Tpt : et   Denis Gagne52 : J'ai donc ré-essayé ce matin… c'est pas mieux :-( --Lorlam (d) 29 avril 2020 à 09:39 (UTC)[répondre]

  Tpt : J’ai regardé les changements que tu as apportés sur Github et effectué les mêmes opérations dans Powershell en ligne de commandes. J’obtiens une image Truecolor avec un beau petit point rouge dans le coin supérieur gauche. Donc tu es vraiment très prêt du but. Je remarque que tu n’as pas intégré le début de l’exemple 5 fourni par pawansgi92 (qui est aussi actif sur Github). Peux-tu changer le début de ta fonction et contrôler avec un log autrement que les fichiers passent bien par toutes les étapes ?

		$imagic = new Imagick( $fileName );
		if  ( $imagic->getImageColorspace() == Imagick::COLORSPACE_GRAY ) {
   //  Log : Trying to convert $filename to sRGB
           $imagic->setImageColorspace( Imagick::COLORSPACE_SRGB );
       // important: HACK to force grayscale images to be real RGB - truecolor, 
       // some PDF's readers do not support "real" grayscale JPEGs or PNGs
       // special thanks to pawansgi92
   // log : Trying to Draw a red point on $filename
         etc.

Faut persister, tu vas réussir !!! --Denis Gagne52 (d) 30 avril 2020 à 01:08 (UTC)[répondre]

Merci   Tpt : et   Denis Gagne52 : pour vos efforts… j'espère bien en effet que vous êtes prêts du but… Juste une question générale : je suppose que cet outil d'export est aussi utilisé dans la Wikisource anglophone… Nous sommes les seuls à avoir remonté le problème ?? En attendant, bon courage pour la recherche de solution. a+ Laurent --Lorlam (d) 3 mai 2020 à 17:23 (UTC)[répondre]
  Denis Gagne52 : J'ai changé la condition en if ( $imagic->getImageColorspace() === Imagick::COLORSPACE_GRAY ) {. Le fichier est bien convertie de grayscale à srgb.   Lorlam : Est-ce que cela marche maintenant ? Tpt (d) 4 mai 2020 à 18:17 (UTC)[répondre]
Merci   Tpt : Ben… je regrette vraiment, mais… non !!! :-(   Denis Gagne52 : Tu vois quelquechose ? a+ --Lorlam (d) 4 mai 2020 à 19:08 (UTC)[répondre]
  Tpt : Selon ce que je vois sur Github, tu as effectivement changé la première ligne mais pas la suivante : « $imagic->setImageColorspace( Imagick::COLORSPACE_SRGB ); ». Donc le code ne reproduit pas tout à fait ce qui est illustré dans l’exemple et l’image ne s’affiche pas. --Denis Gagne52 (d) 4 mai 2020 à 19:14 (UTC)[répondre]
  Denis Gagne52 :. En effet, je n'avais pas fait attention au fait qu'il y a deux fonctions différentes. C'est corrigé. Tpt (d) 5 mai 2020 à 05:57 (UTC)[répondre]
  Tpt : et   Denis Gagne52 : Désolé je n'ai pas vu tout de suite le message… malheureusement, il doit y avoir autre chose, car l'image ne s'affiche pas encore sur la page de garde du pdf… a+ --Lorlam (d) 6 mai 2020 à 07:07 (UTC)[répondre]
  Denis Gagne52 : J'espère encore… toi qui a l'air de t'y connaître, tu n'a plus d'idée de ce qu'il est possible de faire ? a+ --Lorlam (d) 8 mai 2020 à 14:51 (UTC)[répondre]
  Lorlam : Désolé du retard à te répondre. Je ne vois rien à modifier dans ce que   Tpt : a inscrit sur Github. J’ai testé Imagick en mode « ligne de commande » et la conversion a réussi. Il faudrait que je le fasse aussi en utilisant PHP mais cela implique une autre installation sur mon poste de travail. Le temps me manque pour le moment. Tpt est-ce que les contrôles post-installation de Imagick sur le serveur de test ont été concluants ? Je ne comprend pas que le jpg nous revienne sans le moindre petit changement et qu’aucune erreur ne soit signalée. --Denis Gagne52 (d) 15 mai 2020 à 00:15 (UTC)[répondre]

  Tpt : et   Denis Gagne52 : Bon… pas de solution ? même pas celle de revenir à ce qui marchait bien "avant" ?… a+ Laurent --Lorlam (d) 18 mai 2020 à 21:40 (UTC)[répondre]

  Lorlam : Bon voilà ! Le lecteur PDF que nous utilisons pour la plupart n’accepte pas les images 8 bits, il gère mal les images 32 bits qu’il pivote de temps à autres. À l’occasion, il tranche en deux la dernière ligne de caractères au bas des pages. Revenir en arrière n’est définitivement pas une solution, il faudrait plutôt encourager l’utilisation d’un autre format que le PDF. Entre temps voici comment régler le premier problème constaté.   Tpt : N’ayant pas trouvé de solution simple sur le WEB, j’ai tenté l’approche « ouvrir… et sauvegarder sous… » et la conversion réussit. Salutations à vous deux.

<?php

   // Fichiers  source et destination
     $originalFileName    = 'D:\Outils\Script\Scribe_08bits.jpg';
     $destinationFileName = 'D:\Outils\Script\Scribe_24bits.jpg';
   // chargement de l’image en mémoire
     $sourceImage = imagecreatefromjpeg($originalFileName);
   // lecture de ses dimensions
     $img_width  = imageSX($sourceImage);
     $img_height = imageSY($sourceImage);
   // création d’une image couleur ayant les mêmes dimensions
     $destinationImage = ImageCreateTrueColor($img_width, $img_height);
   // copie de l’image dans son nouveau contenant
     imagecopy($destinationImage, $sourceImage, 0, 0, 0, 0, $img_width, $img_height);
   // sauvegarde de la nouvelle image sur disque
     imagejpeg($destinationImage, $destinationFileName);
   // libère la mémoire
     imagedestroy($destinationImage);    
     imagedestroy($sourceImage);

?> --Denis Gagne52 (d) 27 mai 2020 à 18:44 (UTC)[répondre]

Re-bonjour   Denis Gagne52 : Je ne comprend pas de quoi tu parles avec l’approche « ouvrir… et sauvegarder sous… »… tu proposes une astuce de traitement de l'image lors de l'export ? Si ça donne le résultat escompté, ma fois, pourquoi pas ? Mais bon… personnellement je n'y connais rien dan ce domaine…
Concernant l'utilisation d'un autre format que le "pdf", je sais bien que le "epub" a plus la côte maintenant pour les ebooks, mais le "pdf" reste tout de même un format standard pour les documents… a+ Laurent --Lorlam (d) 28 mai 2020 à 20:16 (UTC)[répondre]
Bonjour   Lorlam : Jusqu’à présent je n’avais fourni que des pistes de solution à Tpt sans avoir pu les tester. J’ai donc installé PHP sur mon ordinateur et réalisé que la librairie standard GD2 qui vient automatiquement avec PHP permet d’effectuer la conversion nécessaires pour compenser le bug du lecteur Acrobat. Il est important de préciser que c’est Acrobat qui est à l’origine de ton problème et nullement l’outil rédigé par Tpt. Je n’ai rien contre le format PDF mais si on souhaite exporter dans ce format, il faudra rédiger des documents qui tiennent compte de ses limitations. Quoiqu’il en soit le code que j’ai fourni permet de produire avec PHP 7.4.6 une image 24 bits qu’Acrobat sera en mesure d’afficher. --Denis Gagne52 (d) 28 mai 2020 à 21:11 (UTC)[répondre]
re-Bonjour  Tpt : et   Denis Gagne52 : : et du coup… il est possible de mettre en place ces solutions dont parle Denis dans l'outil d'export ??? a+ Laurent --Lorlam (d) 2 juin 2020 à 23:14 (UTC)[répondre]
  Denis Gagne52 : Denis, saurais tu expliquer en quelques mots (plus techniques que moi) ce que tu as compris du problème d'export de l'image de première page, suite aux tentatives que vous avez essayé de faire avec Tpt… sur la page https://meta.wikimedia.org/wiki/Talk:Community_Tech/Ebook_Export_Improvement
si on peut avoir de l'aide de l'équipe technique Wikimedia, c'est toujours bon à prendre, a+ Laurent --Lorlam (d) 26 juin 2020 à 12:12 (UTC)[répondre]
Bonjour   Lorlam :, Tpt a déjà fait part sur Github de cette rebuffade d’Acrobat qui s’attend à recevoir une image couleur puisque Calibre lui a accolé l’étiquette DeviceRGB au lieu de DeviceGray. L’équipe technique peut prendre connaissance du traitement déjà prévu dans Ws-Export pour convertir les images « Grayscale » en image « True Color » et ainsi contourner ce problème. En remplaçant le code par celui que j’ai testé ou par celui qui leur conviendra, cela va régler la question. --Denis Gagne52 (d) 26 juin 2020 à 14:51 (UTC)[répondre]
  Denis Gagne52 : Ok parfait, a+ --Lorlam (d) 26 juin 2020 à 15:53 (UTC)[répondre]

Astérisme

modifier

Bonjour, Il semblerait que le "fs" dans l'Astérisme ne fonctionne pas. Merci de votre intervention.--Kaviraf (d) 4 février 2020 à 08:29 (UTC)[répondre]

Cela fonctionne, mais sous cette forme : {{***|200%}} --Acélan (d) 4 février 2020 à 09:40 (UTC)[répondre]
Merci   Acélan :--Kaviraf (d) 4 février 2020 à 09:53 (UTC)[répondre]
{{Astérisme|200%}} "marche" aussi. --*j*jac (d) 4 février 2020 à 12:08 (UTC)[répondre]
Oui, j'ai remarqué qu'avec "200%" l'astérisme fonctionne sans toutefois montrer sa réelle valeur, mais on ne peut pas moduler le "fs". On s'en contentera donc. Merci à vous deux. :))--Kaviraf (d) 4 février 2020 à 15:33 (UTC)[répondre]

  Kaviraf : Je ne sais pas si j'ai bien compris mais sache qu'on peut faire varier la valeur de grandissement :

150%
200%
350%

--*j*jac (d) 4 février 2020 à 17:16 (UTC)[répondre]

Merci  
  Kaviraf : Tu as essayé avec d’autres navigateurs ? V!v£ l@ Rosière /Murmurer…/ 14 février 2020 à 03:36 (UTC)[répondre]

Nouveaux messages d'erreur pour l'attribut "follow" dans les balises référence

modifier

Bonjour à toutes et à tous,

De nouveaux messages d'erreur ont été ajoutés pour les cas où l'attribut "follow" est incorrectement utilisé dans la balise <ref>.

L'attribut follow dans la balise <ref> permet aux utilisateurs de fusionner des documents sources qui s'étendent sur plusieurs pages. Il a été utilisé pour la première fois sur la Wikisource en français et n'existe que sur Wikisource. Il fonctionne ainsi : vous pouvez fusionner le contenu de deux références en une seule note de bas de page, par exemple : <ref name="a">Texte pour la source 1</ref> [...] <ref follow="a">Texte pour la source 2</ref>. Dans la section de références, la note de bas de page sera affichée comme ceci : Texte pour la source 1 Texte pour la source 2. Vous trouverez plus d'informations sur cet attribut ici.

 
Message d'erreur pour l'attribut "follow".

Pour que l'attribut follow fonctionne, il est important que l'attribut name de la référence soit défini dans le texte avant que l'attribut follow ne soit appelé. Malheureusement, si ce n'est pas le cas, la référence figurera en haut de la liste des références, sans marqueur de note de bas de page et sans lien avec la précédente référence qu'elle est censée suivre. Auparavant, il n'y avait pas de message d'erreur pour ce cas de figure. Cela va bientôt changer : pour améliorer l'intégration à l'extension Cite, un message d'erreur sera affiché pour ce cas (voir l'image ci-jointe). Si vous voulez trouver toutes les pages de votre wiki qui utilisent l'attribut follow, vous pouvez utiliser cette requête.

Ce changement a été réalisé dans le cadre du développement de l'attribut extends, ce qui a amené l'équipe Technical Wishes de WMDE à retravailler de grandes parties de l'extension Cite. Le nouveau message d'erreur sera activé le 5 février.

Si vous souhaitez en savoir plus sur ce changement, vous pouvez trouver des informations plus détaillées dans ce ticket Phabricator : T240858. Si vous avez des questions ou remarques, n'hésitez pas à nous en faire part sur cette page (en anglais ou en français, comme vous préférez).

Pour l'équipe Technical Wishes de WMDE, Max Klemm (WMDE) (d) 4 février 2020 à 11:45 (UTC)[répondre]

Informations actuelles : Il n'y aura pas de nouveaux messages d'erreur après tout.

modifier

Contrairement à ce qui a été annoncé, le changement ci-dessus n'aura pas lieu. Il y a un risque qu'à la suite de ce changement, des messages d'erreur soient affichés sur de nombreuses pages Wikisource, même s'il n'y a pas d'erreur. Vous trouverez de plus amples informations sur Phabricator (T240858). Un grand merci à tous ceux qui l'ont remarqué !
À l'heure actuelle, on ne sait pas si le changement annoncé peut être supprimé de l’actualisation générale du logiciel (prévue pour ce soir) ou si l'équipe des Technical Wishes de WMDE le supprimera rapidement par la suite. -- Pour l'équipe Technical Wishes de WMDE, Max Klemm (WMDE) (d) 5 février 2020 à 10:52 (UTC)[répondre]

  Max Klemm (WMDE) :J'ai regardé un texte que j'ai corrigé et qui comporte des milliers de notes, souvent courant sur plusieurs pages comme Page:Taine - Les Origines de la France contemporaine, t. 2, 1910.djvu/140 et le problème est bien présent alors que la syntaxe me semble correcte. Je ne me vois pas reprendre les 11 volumes des Origines (6 mois de travail de correction), + les 7 volumes de L’Histoire de l’Affaire Dreyfus qui comprends également des milliers de notes, pour corriger des notes sans même comprendre comment il faut faire pour que cela fonctionne (la page en anglais citée plus haut est loin d’être explicite pour moi - faut-il mettre la partie de la note follow, sur la même page que la partie name ? à ce moment cela ne correspond plus au fac-similé. Bref que doit-on faire concrètement pour les ouvrages déjà corrigés et parfois validés ? En tout état de cause, il me semble essentiel de sécuriser le travail réalisé par les contributeurs sous peine de les décourager et de les faire fuir.--Cunegonde1 (d) 6 février 2020 à 06:55 (UTC)[répondre]
  Cunegonde1 : Bonjour et merci pour la réponse. Le changement annoncé ci-dessus n'a pas été mis en œuvre à court terme, il n'y a donc pas de nouveaux messages d'erreur et il n'est donc pas nécessaire d'ajuster les pages avec l'attribut follow du côté communautaire. Ou bien quelque chose a changé sur vos pages après tout ? Il serait alors très utile que vous puissiez décrire cela plus en détail. En plus, puis-je vous demander de laisser votre réponse sur cette page centrale ? Nous y recueillons tous les commentaires afin que rien ne nous échappe. -- Salutations distinguées, Max Klemm (WMDE) (d) 7 février 2020 à 08:38 (UTC)[répondre]
  Max Klemm (WMDE) : Le message d’erreur apparaît toujours à la place de la seconde partie de la note introduite par follow à la page mentionnée plus haut Page:Taine - Les Origines de la France contemporaine, t. 2, 1910.djvu/140, alors qu’elle apparaît correctement reconstituée dans l’espace principal Les Origines de la France contemporaine/Tome 2/Livre IV/Chapitre 2, p. 123 n. 4. Je comprends que l’erreur ne devrait plus apparaître dans les nouvelles notes, mais quid des milliers de notes affectées par le problème et qui apparemment ne sont pas réparées ? Cordialement.--Cunegonde1 (d) 7 février 2020 à 08:52 (UTC)[répondre]


Affichage chamboulé des numéros de page pour certains textes transclus

modifier

Bonjour,

Peut-être que le sujet a été traité ou est en cours de traitement quelque part déjà (désolé du coup si c'est le cas), mais j'ai remarqué que, pour certaines pages, l'affichage des numéros de page de textes transclus qu'on peut retrouver à gauche des textes est tout chamboulé. Par exemple ici, ou encore . Le seul point commun que je leur ai trouvé est l'utilisation des modèles Bloc centré/o et Bloc centré/f mais ce n'est cependant pas forcément une bonne piste n'ayant moi-même qu'une connaissance superficielle là-dedans. Quelqu'un aurait une idée ?--Gwendal (d) 1 avril 2020 à 15:06 (UTC)[répondre]

  Gwendal : Le problème est discuté ici: Scriptorium. BrainslugClaptrap (d) 8 avril 2020 à 10:44 (UTC)[répondre]

Années précédentes

modifier

Voir ici.

Remarques : 1. Les catégories affichées au bas de la page d'archives sont fautives.

2. L'ordre chronologique inversé a cédé la place à l'ordre chronologique tout court, date incertaine.


Small caps dans le CSS mobile

modifier

Bonjour, j’utilise Firefox Android pour accéder à Wikisource. J’ai vu que le modèle {{sc|}} n’était pas rendu avec le thème mobile : les lettres apparaissent en minuscules plutôt qu’en petites capitales. Voir par exemple cette page, dont le texte « Victor Hugo » est bien rendu dans la version bureau, mais pas dans la version mobile.

La classe CSS .sc n’est pas définie dans la feuille de style mobile. Où dois-je m’adresser pour rapporter ce problème ?

(J’ai déjà ouvert ce sujet ici, mais la page n’a pas été mise à jour depuis plusieurs années et je ne sais pas si elle est active.)

--Maulor (d) 4 avril 2020 à 10:40 (UTC)[répondre]

  Maulor : bonsoir ! Je vous conseille d'ouvrir directement un sujet dans le Scriptorium, c'est le meilleur moyen de trouver un interlocuteur. Les pages plus spécialisées sont assez peu suivies. --Jahl de Vautban (d) 4 avril 2020 à 18:30 (UTC)[répondre]

Problème réglé suite au message sur le scriptorium. VIGNERON (d) 7 avril 2020 à 13:50 (UTC)[répondre]

Technical maintenance planed‬

modifier

Coolest Tool Award 2021: Call for nominations

modifier
 

The third edition of the m:Coolest Tool Award is looking for nominations!

Tools play an essential role for the Wikimedia projects, and so do the many volunteer developers who experiment with new ideas and develop and maintain local and global solutions to support the Wikimedia communities. The Coolest Tool Award aims to recognize and celebrate the coolest tools in a variety of categories.

The awarded projects will be announced and showcased in a virtual ceremony in December. Deadline to submit nominations is October 27. More information: m:Coolest Tool Award. Thanks for your recommendations! -- SSethi (WMF) for the 2021 Coolest Tool Academy team 19 octobre 2021 à 05:57 (UTC)[répondre]

Community Wishlist Survey 2022 is coming. Help us!

modifier

The Community Wishlist Survey 2022 starts in less than two weeks (Monday 10 January 2022, 18:00 UTC). We, the team organizing the Survey, need your help.

Only you can make the difference

How many people will hear and read about the Survey in their language? How many will decide to participate? Will there be enough of you to vote for a change you would like to see? It all depends on you, volunteers.

Why are we asking?

  • We have improved the documentation. It's friendlier and easier to use. This will mean little if it's only in English.
  • Thousands of volunteers haven't participated in the Survey yet. We'd like to improve that, too. Three years ago, 1387 people participated. Last year, there were 1773 of them. We hope that in the upcoming edition, there will be even more. You are better than us in contacting Wikimedians outside of wikis. We have prepared some images to share. More to come.

What is the Community Wishlist Survey?

 

It's an annual survey that allows contributors to the Wikimedia projects to propose and vote for tools and platform improvements. Long years of experience in editing or technical skills are not required.

Thanks, and be safe and successful in 2022! SGrabarczuk (WMF) (talk) 29 décembre 2021 à 03:15 (UTC)[répondre]

Save the Date: Coolest Tool Award 2021: this Friday, 17:00 UTC

modifier

<languages />

Bonjour tout le monde,

La cérémonie de Wikimedia Coolest Tool Award, récompensant les outils les plus appréciés au sein des projets Wikimédia, se déroulera en ligne le vendredi 14 janvier 2022 à 17:00 UTC.

Cette récompense met en valeur les outils logiciels qui ont été nomminés par les contributrices et contributeurs des projets Wikimédia. La cérémonie est un moment sympathique visant à remercier les personnes qui développent ces outils, et peut-être découvrir de nouveaux outils !

En savoir plus sur la diffusion en direct et les canaux de discussion.

Merci de votre participation ! andre (talk) -08:02, 6 January 2022 (UTC)

Last two days for submitting proposals

modifier
 

Tomorrow is the last day for submitting proposals for the Community Wishlist Survey 2022.

Also, everyone is welcome to translate, promote, and discuss proposals. SGrabarczuk (WMF) (talk) 22 janvier 2022 à 14:45 (UTC)[répondre]

Rollout of the new audio and video player

modifier

Aidez-nous à traduire dans votre langue

Hello,

Over the next months we will gradually change the audio and video player of Wikis from Kultura to Video.js and with that, the old player won’t be accessible anymore. The new player has been active as a beta feature since May 2017.

The new player has many advantages, including better design, consistent look with the rest of our interface, better compatibility with browsers, ability to work on mobile which means our multimedia will be properly accessible on iPhone, better accessibility and many more.

The old player has been unmaintained for eight years now and is home-brewn (unlike the new player which is a widely used open source project) and uses deprecated and abandoned frameworks such as jQuery UI. Removing the old player’s code also improves performance of the Wikis for anyone visiting any page (by significantly reducing complexity of the dependency graph of our ResourceLoader modules. See this blog post.). The old player has many open bugs that we will be able to close as resolved after this migration.

The new player will solve a lot of old and outstanding issues but also it will have its own bugs. All important ones have been fixed but there will be some small ones to tackle in the future and after the rollout.

What we are asking now is to turn on the beta feature for the new player and let us know about any issues.

You can track the work in T100106

Thank you, Amir 17 février 2022 à 17:59 (UTC)[répondre]

Cérémonie des outils les plus cools 2022 : appel à nominations

modifier

La quatrième édition de la Cérémonie des outils les plus cools attend vos nominations ! Quel est votre outil logiciel préféré pour Wikimedia ? Proposez vos outils favoris avant le 12 octobre 2022 ! Les projets récompensés seront annoncés et présentés lors d’une cérémonie virtuelle en décembre.


MediaWiki message delivery 3 octobre 2022 à 18:30 (UTC)[répondre]

Participez à la Cérémonie 2022 des outils les plus cools, le vendredi 16 décembre à 17 h UTC

modifier

La quatrième Cérémonie des outils les plus cools de Wikimedia se déroulera en ligne le vendredi 16 décembre 2022 à 17 h UTC.

Cette cérémonie met en valeur les outils logiciels qui ont été sélectionnés par les contributrices et contributeurs des projets Wikimédia. La cérémonie est un moment sympathique visant à remercier les personnes qui développent ces outils, et peut-être découvrir de nouveaux outils !

En savoir plus sur la diffusion en direct et les canaux de discussion.

Merci de votre participation ! — Komla


MediaWiki message delivery 5 décembre 2022 à 18:53 (UTC)[répondre]

Taille, couleur et graisse des titres t2, t3, t4, t5 et t6

modifier

Cette discussion fait suite à celle initiée par Canton-de-l’Est sur la page de Janvier 2023 du Scriptorium.

Constats à partir de cette page et de celle produite par Cantons-de-l’Est

modifier
  1. Après exportation en pdf ou epub, la taille des titres de niveau t3 est supérieure à celle des titres de niveau t2 ;
  2. Les titres de niveau t3 deviennent colorés en epub, PDF... ;
  3. Les titres de niveau t2 deviennent en gras en epub, PDF... ;
  4. Les titres de niveau t4 sont en gras partout ;
  5. Deux titres ayant une taille respective de 150% et de 130% se voient attribuer une taille identique de 21pt en pdf mais avec 117% on obtiendra 17 pt;
  6. De tous les titres affichés sur ws, seuls t2 et t4 ont une taille qui respecte la taille par défaut adoptée par les navigateurs ;
  7. La taille et la graisse proviennent de diverses sources comme si on avait mélangé les cartes de différents jeux ;
  8. Les modèles de la famille {{t2mp}} utilisent des balises obsolètes et ignorent h1, h2, hn...

Origine de la taille et de la graisse

modifier
Taille et Graisse (bleu : affichage sur ws (vector et minerva) ; vert affichage sur epub)
Modèle common epub.css vector-body vector.legacy minerva user-agent
h1 2em
h2 150% 1.5em — 150% normal 1.5em — 1.5em bold
h3 normal 1.67em 1.2em 128% 1.2em bold 1.17em bold
h4 100% bold 116% — — bold — bold
h5 normal 100% 108% — 100% — .83em bold
h6 90% normal 100% — 100% — 100% — .67em bold

Discussions

modifier

Constats 1 et 2

modifier
  • La taille de h3 définie dans Epub.css est 1.66667em (et la couleur, #365f91) alors que la taille de h2 est définie à 150% ou 1.5em dans le modèle t2 ;
  • Proposition : vérifier avec Tpt la raison pour laquelle epub.css a été construit ainsi à l’origine et si on peut retirer ces deux valeurs du fichier CSS ;
  1.   Pour la demande de suppression de la taille et de la couleur dans epub.css ; il semble que ce soit là ce qui pour la première casse le plus l’échelle décroissante de tailles, et pour la seconde pose le plus de problème pour les systèmes à mode inversé (cf. remarque de @Cunegonde1 et de moi sur le scriptorium). — ElioPrrl (d) 4 janvier 2023 à 12:55 (UTC)[répondre]
  2.   Pour Je préfère des valeurs plus génériques, moins personnalisées par une feuille de style liée à un format d'export. — Cantons-de-l'Est p|d|d
  3.   Pour --Acélan (d) 5 janvier 2023 à 08:53 (UTC)[répondre]

Constat 3

modifier
  • Harmonisation à considérer
  1.   Pour la suppression du gras à l’export, parce que je pense que les contributeurs ne prévoient pas son apparition à l’export quand ils utilisent le modèle sur le site web. — ElioPrrl (d) 4 janvier 2023 à 12:55 (UTC)[répondre]
  2. Il faut considérer les modèles {{t2}}, {{t3}}... comme inappropriés pour la mise en page des en-têtes de livres, de sections, de sous-sections, de chapitres, de sous-chapitres... Je préfère que nous utilisions les modèles {{m|EnteteNiveau_1}}, {{m|EnteteNiveau_2}}... (qui sont à créer ; on peut raccourcir leur titre : {{m|en1}}, {{m|en2}}...). Leur titre explique mieux leur usage et les contributeurs risquent de mieux appliquer la hiérarchie des en-têtes. — Cantons-de-l'Est p|d|d 4 janvier 2023 à 13:21 (UTC)[répondre]
    • Pour le coup, je ne suis vraiment pas d’accord : peut-être que le nom de ces modèles est mal choisi et qu’il faut étoffer les documentations, mais leur seul rôle est bien de mettre en page les titres, sous-titres, etc. C’est ce qu’indique leur documentation et le guide du nouveau contributeur. Sémantiquement, t2 introduit une balise h2, t3 une h3, etc., donc c’est bien leur sens que de hiérarchiser les titres. Esthétiquement, on peut contester les choix faits par les créateurs (et je ne m’en prive pas  ) ainsi les discordances introduites dans les diverses feuilles de style ; mais en tout cas ces modèles disposent de tous les paramètres pour mettre en forme les titres : fonte, corps du texte, graisse, interlettrage, alignement horizontal, marges verticales, etc. Le problème est que les contributeurs apportent plus d’attention à la mise en forme par défaut du modèle qu’à son sens ; aussi, je ne crois pas que le changement de nom fasse disparaître l’habitude de choisir le modèle dont l’esthétique corresponde le mieux au fac-similé, plutôt que celui dont le sens est le bon (à moins peut-être de créer des modèles de titre dont la mise en forme par défaut soit identique). D’ailleurs, à vrai dire, je pousse peut-être au noir dans la dernière phrase : je pense que le sens général des modèles est compris, car je n’ai jamais vu quelqu’un subordonner un {{t3}} à un {{t4}} ; ce qu’on voit, c’est plutôt un certain arbitraire dans le choix du titre de plus haut niveau (notamment le refus de {{t2}}, probablement à cause de la fonte à empattements), puis l’utilisation hiérarchique des modèles, avec parfois des titres de niveau différent entrés avec le même modèle (par exemple t3 pour les titres de chapitre et t3 pour les titres de section de chapitre, si les deux sont de la même taille et de la même graisse dans le fac-similé, mais, par exemple, l’un en capitales et l’autre en italiques). P.-S. : Je vais indiquer d’ailleurs dans la section du guide du nouveau contributeur le fait que la mise en forme par défaut du titre n’est pas immuable, ce qui n’est pas précisé au moment au j’écris ce message ; je vais également modifier la documentation de {{t4}} pour que vous puissiez me dire si je la rends plus claire. — ElioPrrl (d) 4 janvier 2023 à 13:58 (UTC)[répondre]
    • Si je comprends bien la proposition de Cantons-de-l'Est, les modèles tn seraient remplacés ou doublés par EnteteNiveau_n. On obtiendrait le même résultat, mais en utilisant un nom plus explicite. Je suis d’avis moi-aussi qu’on doit absolument respecter la séquence h2, h3, h4, … sans quoi l’utilisation de ces balises perd tout son sens. Notre manque de rigueur accroit notre dépendance à ws-export qui est le seul à pouvoir supporter une structure documentaire déficiente. Il vaut mieux, selon moi, maintenir une seule série de modèles. J’ai peur que l’introduction de nouveaux modèles amène davantage de confusion. --Denis Gagne52 (d) Le miraculé du 9e 4 janvier 2023 à 15:26 (UTC)[répondre]
    • Les modèles "t2" et "t3" sont bien faits pour créer des "t"itres… donc je ne vois pas de raisons d'en créer d'autres pour la même fonctionnalité… Par contre, il serait effectivement logique que le rendu du modèle "t2" soit plus gros que le modèle "t3" ce qui ne semble pas être le cas !?--Lorlam (d) 4 janvier 2023 à 16:25 (UTC)[répondre]
    • D'accord avec les objections soulevées ci-dessus ; j'ajoute qu'il reste des résidus d'autres formats de titres ({{m|t2mp}} etc.) qui n'ont pas le même comportement, et qu'on pourrait, à l'occasion, voir à remplacer ? --Acélan (d) 5 janvier 2023 à 08:53 (UTC)[répondre]
    • Oui ! Nous n’y avions pas pensé ! La famille {{m|t2mp}} utilise des balises obsolètes que ws-export doit remplacer à chaque conversion. De plus, elles ne produisent pas de vrais titres au sens de html5. Ajouté comme Constat 8. --Denis Gagne52 (d) Le miraculé du 9e 5 janvier 2023 à 14:24 (UTC)[répondre]

Constat 4

modifier
  • Discuter de l’impact de retirer le gras de h4
  1.   Pour retirer le gras, quitte à ajouter automatiquement des triples apostrophes droites ou un fw=bold aux occurrences de {{t4}} qui n’en sont pas déjà pourvus (par un bot tel celui que @Cantons-de-l'Est a créé pour supprimer les espaces avant les appels de note). — ElioPrrl (d) 4 janvier 2023 à 12:55 (UTC)[répondre]
  2. La proposition d'ElioPrrl me semble raisonnable. — Cantons-de-l'Est p|d|d 4 janvier 2023 à 13:22 (UTC)[répondre]
  3. Si on ne le fait pas, plusieurs vont continuer à utiliser t4 au lieu de t2 ou t3 uniquement pour obtenir un caractère gras. Il y a 40,000 occurrences de t4 dans l’espace page. @Cantons-de-l'Est est-ce que votre bot permettrait d’effectuer l’ajustement proposé par ElioPrrl ? Cela résoudrait notre plus grande difficulté.--Denis Gagne52 (d) Le miraculé du 9e 4 janvier 2023 à 14:50 (UTC)[répondre]
  4. Ok pour retirer le gras... Lorlam (d) 4 janvier 2023 à 16:26 (UTC)[répondre]

  Cantons-de-l'Est : Comment vas-tu t’y prendre pour faire cette modification automatique ? J’ai essayé de trouver une expression régulière pour le faire, mais c’est bien trop compliqué, à cause de la possibilité d’imbriquer les modèles. Je pense qu’on est obligé de faire une petite fonction pour trouver dans un texte une séquence du type {{t4|…}} contenant éventuellement d’autres accolades, et pour vérifier qu’il n’y a ni apostrophes triples ni fw= dans cette séquence. Du moins peut-on se limiter à l’espace Page:, et aux pages corrigées, validées ou à problème, je pense. — ElioPrrl (d) 13 février 2023 à 13:13 (UTC)[répondre]

ElioPrrl, Pywikibot permet de copier le wikicode de n'importe quelle page de Wikisource. Le traitement en Python est relativement aisé, mais je devrai faire des tests avant d'effectuer des changements massifs. — Cantons-de-l'Est p|d|d 13 février 2023 à 16:54 (UTC)[répondre]
  Cantons-de-l'Est : Je connais Python, je vais regarder de mon côté aussi  ElioPrrl (d) 13 février 2023 à 17:02 (UTC)[répondre]
Voilà une fonction, bien artisanale cependant, qui me semble faire ce que l’on veut ; elle utilise le module re :
def T4gras(str_Texte):

	# on découpe le texte d’entrée str_Texte avant chaque occurrence de t4
	li_Decoupe = re.split("(?={{t4\|)", str_Texte)

	for i in range(len(li_Decoupe)):
		str_Element = li_Decoupe[i]
		# pour chaque occurrence de t4
		if str_Element[:4] == "{{t4":
			# on repère où se trouvent les accolades fermantes du modèle
			nb_accol = 2
			k = 2
			while nb_accol > 0:
				if str_Element[k] == "{":
					nb_accol += 1
				elif str_Element[k] == "}":
					nb_accol -= 1
				k += 1
			# str_Titre contient donc {{t4|...}} en entier
			str_Titre = str_Element[:k]
            # si on ne trouve ni apostrophes triples ni fw= dans le t4…
			if "'''" not in str_Titre and "fw=" not in str_Titre:
			    # … on remplace ses accolades fermantes par |fw=bold}}
				li_Decoupe[i] = str_Element[:k-2] + "|fw=bold}}" + str_Element[k:]

	# on retourne le texte modifié
	return ''.join(li_Decoupe)
ElioPrrl (d) 13 février 2023 à 17:36 (UTC)[répondre]
ElioPrrl, Je développe un script de mon côté qui injecte des triples apostrophes droites. Je vais tester votre script puisqu'il est déjà créé (j'ignorais l'existence du paramètre fw=bold). — Cantons-de-l'Est p|d|d 20 février 2023 à 12:07 (UTC)[répondre]
J’avais effectivement commencé à vouloir injecter ces apostrophes, mais devant la complexité de la chose (il faut reconnaître s’il y a un ou des arguments, titre et numéro, à traiter, les isoler sans se laisser avoir par les potentiels modèles utilisés dans ces arguments, etc.) je me suis rabattu sur l’argument, qu’il suffit d’insérer à la fin du modèle. — ElioPrrl (d) 20 février 2023 à 12:11 (UTC)[répondre]
ElioPrrl, J'ai réfléchi aux avantages et inconvénients de votre méthode et de la mienne. La vôtre est plus générale ; j'ai découvert un bogue que j'ai facilement corrigé (appels en minuscules : {{t4 et en majuscules : {{T4). J'ai testé avec plusieurs cas de figures et les résultats sont bons jusqu'à maintenant.  Cantons-de-l'Est p|d|d 21 février 2023 à 12:37 (UTC)[répondre]
ElioPrrl et Denis Gagne52, En effectuant quelques tests en lien avec {{t4}}, j'ai découvert un truc qui exige une décision. Voyez les cinq premières lignes de Utilisateur:Cantons-de-l'Est/Test/t4. Selon mon inspection visuelle, par rapport aux paramètres par défaut de <t4>...</t4>, fw=bold réduit la quantité de graisse appliquée aux lettres (j'ai zoomé pour valider ma première perception). Ma question est : fw=900, fw=bold ou triplet d'apostrophes ? Je préfère fw=900, mais j'ignore comment seront agencées les décorations des modèles {{t. — Cantons-de-l'Est p|d|d 21 février 2023 à 12:37 (UTC)[répondre]
  Cantons-de-l'Est : Je pense que c’était un effet dû à la pixellisation sur des phrases de différentes longueurs. Sur des lignes du même texte, et assez longues pour que le moindre décalage soit amplifié par la longueur de la phrase, je ne vois aucune différence entre par défaut, bold et triples apostrophes. Le contraire aurait été très étonnant, vu le tableau de Denis Gagne52 donnant l’origine de cette graisse ; en CSS, bold est équivalent à 700. — ElioPrrl (d) 21 février 2023 à 12:46 (UTC)[répondre]
Bonjour,
  • Avec Chrome, Edge et Opera sous Windows 10, je vois trois graisses : (1) ligne 1, (2) lignes 2, 3 et 4 et (3) lignes 5
  • Avec Firefox et dérivés sous Windows 10, je vois trois graisses : (1) ligne 1, (2) lignes 2 et 3 et (3) lignes 4 et 5.
  • Avec Safari sur tablette iPad, je vois deux graisses : (1) ligne 1 et (2) lignes 2, 3, 4 et 5.
  • Dans un export en PDF, je vois deux graisses : (1) ligne 1 et (2) lignes 2, 3, 4 et 5.
Je suis satisfait, puisque ça sort correctement en PDF.   Je poursuis donc avec fw=bold.
Cantons-de-l'Est p|d|d 21 février 2023 à 19:33 (UTC)[répondre]
  Cantons-de-l'Est : Ah oui ! sur Firefox les triples apostrophes mettent la graisse au maximum. Après investigations, cela vient de ce que l’élément b est associé dans Chromium avec font-weight: bold, dans Firefox avec font-weight: bolder ; or, comme les apostrophes imbriquent un b dans un h4, et que h4 est déjà avec font-weight: bold actuellement, Firefox renchérit sur bold. Mais, si je prévois bien, le fait de préciser, comme on va le faire, font-weight: normal pour h4 dans la feuille de style globale devrait faire disparaître cette différence de Firefox. Par précaution, on pourra aussi redéfinir b dans Commons.css. — ElioPrrl (d) 21 février 2023 à 20:00 (UTC)[répondre]

┌─────────────────────────────────────────────────┘
ElioPrrl, J'ai terminé le travail de mise en gras explicite des titres « t4 » (fw=bold). — Cantons-de-l'Est p|d|d 27 février 2023 à 02:38 (UTC)[répondre]

  Cantons-de-l'Est : Un immense merci, ça c’est du travail collaboratif ! — ElioPrrl (d) 27 février 2023 à 16:24 (UTC)[répondre]

Constats 5 et 6

modifier
  • Envisager la conformité avec les valeurs par défaut des navigateurs, ce qui assure une cohérence ws vs pdf ;
  1. À la lumière des tests menés par Denis puis par moi-même (cf. ci-dessous), je pense qu’il est plus sage de conserver l’échelle de taille actuelle de Vector (150 % — 120 % — 100 %). Ceci m’apparaît avoir deux avantages : 1o ces tailles seront bien exportées sous trois tailles décroissantes en PDF ; 2o on ne modifierait pas la mise en page des textes déjà transclus. Bien entendu, je sous-entends que l’on applique cette échelle de taille à Epub.css (cf. constat 1). — ElioPrrl (d) 4 janvier 2023 à 16:35 (UTC)[répondre]

Constat 7

modifier
  • La taille et la graisse proviennent de diverses sources comme si on avait mélangé les cartes de différents jeux.
  1.   Pour une harmonisation de toutes les feuilles de style qui président à l’affichage du site web, du site mobile et à l’export. Reste à définir sur quelle base ; les arguments de @Lorlam et ceux que j’avance pour le constat précédent laissent à penser qu’il vaut mieux généraliser Vector, le plus utilisé par les contributeurs lors de la transcription. — ElioPrrl (d) 4 janvier 2023 à 12:55 (UTC)[répondre]
  2.   Pour une harmonisation également Lorlam (d) 4 janvier 2023 à 21:30 (UTC)[répondre]
  3.   Pour une harmonisation, peu importe l'appareil de lecture. — Cantons-de-l'Est p|d|d 6 janvier 2023 à 02:41 (UTC)[répondre]

Constat 8

modifier
  • Problème rapporté par Acelan. Proposition : actualiser le code des modèles de la famille t2mp, mais l’idéal serait de les faire disparaître dans les pages concernées et de détruire tous ces modèles, car ils sont encore utilisés par certains malgré leur non-conformité avec html5. Qu’en pensez-vous ? Surtout @Cantons-de-l’Est car cela pourrait impliquer 10000 remplacements supplémentaires à effectuer avec le bot déjà très sollicité. À suivre ! --Denis Gagne52 (d) Le miraculé du 9e 5 janvier 2023 à 14:40 (UTC)[répondre]
  • Tableau retiré car il n’est plus utile
Denis Gagne52, Aucun souci pour le temps bot. Consommation d'octets et d'énergie électrique exceptées, son temps de travail est gratuit. — Cantons-de-l'Est p|d|d 6 janvier 2023 à 02:43 (UTC)[répondre]
  Denis Gagne52 et Cantons-de-l'Est : J'ai commencé à remplacer ces modèles, et je pense qu'il vaut mieux ne pas se précipiter : dans certains cas, un bot sera adéquat, mais le remplacement est aussi l'occasion d'introduire un peu de cohérence là où il n'y en a pas toujours. Par exemple, on voit fréquemment {{t3mp|III}} :{{t4mp|Titre du chapitre}} au lieu de {{t3mp|Texte t3mp|III}}
donc il est difficile de parler en terme de remplacement strict, il vaut mieux voir volume par volume. Je propose de commencer à m'en charger, au moins pour faire le point et commencer à voir ce qu'on peut automatiser le plus facilement. Acélan (d) 6 janvier 2023 à 07:19 (UTC)[répondre]
  Acélan, Cantons-de-l'Est, ElioPrrl et Lorlam : Après quelques centaines de remplacements faits à la main, je retire ma proposition. Je constate que les modèles de la famille {{m|t2mp}} sont utilisés à toutes les sauces. On en retrouve beaucoup dans les pages de titres, les tdm, les bibliographies, etc. On ne peut donc pas tous les remplacer par des modèles de la famille {{T2}}. Cette incursion m’a permis de mieux comprendre la proposition de Cantons-de-l'Est (Constat 3). T2 sert en effet à produire un entête de niveau 2, T2mp sert à produire n’importe quoi sauf un entête de niveau 2. La notion de niveau n’aurait jamais dû apparaître dans la documentation de {{m|t2mp}} et al. car elle fait référence au headers CSS : h1, h2, ... qui ne sont nullement présents dans leur wikicode. J’ai ajouté une mise en garde à la doc de {{m|t1mp}} et {{m|t2mp}} et vous laisse regarder avant de poursuivre avec les deux autres modèles. --Denis Gagne52 (d) Le miraculé du 9e 7 janvier 2023 à 18:53 (UTC)[répondre]
Cela me convient tout à fait. — ElioPrrl (d) 7 janvier 2023 à 19:04 (UTC)[répondre]
Oui @Denis Gagne52, c'est parfait. Lorlam (d) 7 janvier 2023 à 20:01 (UTC)[répondre]
J'ai effectué plusieurs centaines de remplacement, et on ne peut effectivement rien généraliser. Juste effectuer des remplacements avec AWB dans certains volumes. Ça va être long, mais le nombre de pages concernées est maintenant à moins de 10000... J'ai alerté un utilisateur qui utilise toujours ces modèles ; mais je pense que la majorité des cas concerne des pages remontant à plusieurs années. Acélan (d) 7 janvier 2023 à 21:47 (UTC)[répondre]
  Cantons-de-l'Est, Denis Gagne52, ElioPrrl et Lorlam : Le modèle {{m|t4mp}} est proposé à la suppression ; je continue à supprimer les autres. C'est assez long, mais ça permet d'introduire davantage de cohérence dans certains volumes. Acélan (d) 14 janvier 2023 à 12:40 (UTC)[répondre]
Oui, Merci   @Acélan Lorlam (d) 14 janvier 2023 à 16:16 (UTC)[répondre]
  • Sujets libres

Denis Gagne52 (d) Le miraculé du 9e 4 janvier 2023 à 03:06 (UTC)[répondre]

Tableau de comparaison

modifier

Merci   beaucoup Denis pour ce tour de vue, et notamment le tableau de comparaison ! À son sujet, deux questions :

  1. je pense qu’il serait bon d’ajouter à la comparaison une colonne pour le thème Minerva, qui correspond à la consultation sur mobile.
  2. que signifient les colonnes vector.legacy et user-agent ?

ElioPrrl (d) 4 janvier 2023 à 13:00 (UTC)[répondre]

Désolé. Je ne sais pas comment lire les informations pour Minerva. vector.legacy est probablement tiré de l’habillage que nous avons choisi dans notre profil. User-agent : ce sont les valeurs qui seront utilisées par notre navigateur à défaut de les avoir précisés. --Denis Gagne52 (d) Le miraculé du 9e 4 janvier 2023 à 14:39 (UTC)[répondre]
  Denis Gagne52 : Donc user-agent ne correspond à rien de ce qu’on voit, si je comprends, puisque tout cela est « nié » par les feuilles de style. Pour avoir une page avec le thème Minerva, il suffit d’ajouter ?useskin=MINERVA après l’adresse URL ; cela permet par exemple de vérifier qu’une mise en page complexe satisfaisante dans Vector passe bien sur mobile. — ElioPrrl (d) 4 janvier 2023 à 15:11 (UTC)[répondre]
P.-S. 1 : Je viens de faire la recherche, et j’ai complété le tableau. Il appert qu’au total, on voit la même chose avec Vector et Minerva, les rares différences entre les deux étant neutralisées par les propriétés directement inscrites dans le code du modèle. — ElioPrrl (d) 4 janvier 2023 à 15:36 (UTC)[répondre]
P.-S. 2 : Il semble que vector.legacy code l’ancienne version du thème Vector (2010). Comme je suis resté avec cette ancienne version, je n’avais pas cet élément. La nouvelle version a des éléments étranges, probablement dus à la « fossilisation » de Vector 2010 dans Vector 2022 : l’inspecteur indique par exemple qu’il y a dans la même feuille de style (vector-2022) deux indications contradictoires : h4 à 116% et .vector-body h4 à 100% ; c’est cette dernière qui l’emporte. On fera mieux au total de tout coder en dur dans Common.css, Mobile.css et Epub.css à mon avis pour éviter des modifications trop brutales si quelqu’un s’avise de faire le ménage dans Vector 2022. — ElioPrrl (d) 4 janvier 2023 à 15:42 (UTC)[répondre]
  ElioPrrl : Quand, à l’intérieur de Calibre, j’examine les fichiers convertis, je ne vois aucune trace de Vector. Les valeurs par défaut du navigateur ou celles de Calibre doivent sûrement intervenir pour que t2 soit en gras, une fois le fichier exporté. Tant qu’à coder en dur, la solution la plus pratique ne serait-elle pas de forcer les valeurs que nous souhaitons en utilisant directement les modèles t2, t3, tn ? Il y a trop d’intervenants sur lesquels nous n’avons pas de contrôle à moins qu’on te donne accès aux différentes feuilles de style. Qu’en penses-tu ? --Denis Gagne52 (d) Le miraculé du 9e 4 janvier 2023 à 17:01 (UTC)[répondre]
  Denis Gagne52 : Je préfèrerais passer par les feuilles de style, parce qu’elles sont moins susceptibles d’être modifiées que les modèles et parce que cela allègerait peut-être un peu les fichiers exportés. Les modifications faites par plus haut que nous m’inquiètent peu : les modifications faites par les développeurs devraient être contrées par nos feuilles de style, à moins qu’ils ne décident de bouleverser les priorités, ce qui me paraît très peu probable. Cela fait plusieurs fois que sur ma page de discussion on me suggère de devenir administrateur d’interface ; je considère qu’il y a des gens plus capables que moi pour cela (suivez mon regard  ), mais si cela peut arranger tout le monde, je veux bien soumettre ma demande. — ElioPrrl (d) 4 janvier 2023 à 17:18 (UTC)[répondre]
  ElioPrrl : Si tu te présentes, alors là uniquement, je serai réceptif à ta proposition  . Plus sérieusement, on ne devrait pas avoir à retoucher à cela bien souvent, ne te sens pas obligé. Alors va pour les feuilles de style et hourra pour ta candidature  ! --Denis Gagne52 (d) Le miraculé du 9e 4 janvier 2023 à 21:30 (UTC)[répondre]
Je suis en train de rédiger ma candidature au statut d’administrateur d’interface, et je compte la rendre officielle très prochainement. — ElioPrrl (d) 13 janvier 2023 à 12:45 (UTC)[répondre]
Ma candidature est proposée au vote ici. — ElioPrrl (d) 1 février 2023 à 10:08 (UTC)[répondre]

Source des calculs du constat 5

modifier

  Denis Gagne52 : Quel est le calcul qui te permet de prévoir la taille du texte exporté en PDF ? Cela permettra de choisir une échelle de taille qui reste décroissante en PDF, même si elle n’est pas strictement égale à celle utilisée par Vector. Merci d’avance ! — ElioPrrl (d) 4 janvier 2023 à 13:10 (UTC)[répondre]

  ElioPrrl : Je n’ai pas trouvé la formule encore. Tout cela est paramétrable dans Calibre mais ws-export n’exploite pas cette possibilité. Avec la police LiberationSerif, 15pt est attribué pour la taille qu’on retrouve le plus souvent dans le texte. Je ne sais pas si on tient compte de la taille la plus grande et de la plus petite pour la répartition. J’ai simplement produit un échantillon à partir des tailles par défaut utilisées dans nos navigateurs. En copiant du pdf vers Word, on obtient ceci quand on conserve la clé et la police de base assignés par défaut :
Taille des titres — wikisource vs pdf issus de ws-export
Titre taille par défaut du navigateur taille pdf pour LiberationSerif
t2 150% 21pt
t3 117% 17pt
t4 100% 15pt
t5 83% 11.5pt
t6 67% 8.5pt

--Denis Gagne52 (d) Le miraculé du 9e 4 janvier 2023 à 14:34 (UTC)[répondre]

J’ai essayé de compléter le tableau précédent de manière systématique : voici mes résultats. Les tests ont été menés en exportant la page Test d’affichage en A4, A5 et A6 ; on obtient les mêmes résultats pour les trois formats. N’ayant pas Word, j’ai ouvert les PDF avec LibreOffice Draw (ce qui peut expliquer les divergences mineures avec le tableau de Denis).
Taille du texte
sur WS en PDF
(taille absolue)
en PDF
(taille relative)
de 200 % à 192 % 30 pt 200 %
de 191 % à 175 % 27,5 pt 183,33 %
de 174 % à 153 % 25 pt 166,67 %
de 152 % à 123 % 21,2 pt 141,33 %
de 122 % à 106 % 16,8 pt 112 %
de 105 % à 93 % 15 pt 100 %
de 92 % à 68 % 11,3 pt 75 %
de 67 % à 51 % 8,8 pt 58,67 %
50 % 6,3 pt 42 %
On voit que le choix actuel (150 % — 120 %) est celui qui, pour des chiffres ronds, permet d’avoir les corps de h2 et h3 les plus gros tout en restant différents. — ElioPrrl (d) 4 janvier 2023 à 16:23 (UTC)[répondre]
  ElioPrrl : Super ! Ça me va ! 150% pour h2, 120% pour h3, 100% pour h4, 90%? pour h5 (utilisé 5000 fois dans l’espace page), 80%? pour h6 (utilisé 1000 fois) ; h5 et h6 aurait alors la même taille en pdf soit 11.5pt. Je ne me souviens pas t’avoir dit que ces difficultés résultent de la commande placée par ws-export qui ne précise pas qu’on souhaite désactiver le redimensionnement de la taille de la police. Alors Calibre utilise par défaut la clé de conversion. Dommage ! --Denis Gagne52 (d) Le miraculé du 9e 4 janvier 2023 à 17:22 (UTC)[répondre]
  Denis Gagne52 : D’accord pour le début : ça reste proche des valeurs du PDF, et ça ne modifie pas le travail déjà fait. Par contre je laisserai h5 à 100% pour ne pas trop modifier les pages déjà transcrites (je pense que, comme nous prévenait @Lorlam, les gens ayant utilisé {{t5}} s’attendaient à avoir un texte de la même taille que le texte courant, pas un texte plus petit) ; h6 à 90% ou 80% m’est assez indifférent, ça reste plus petit que le texte courant, et peut-être que 80% est mieux parce qu’il se rapproche plus de la valeur (75 %) en PDF. Quant au fonctionnement de Calibre, tu me l’avais déjà exposé quand j’essayais de faire mes lettrines, mais nous étions d’accord qu’ignorer la clef de conversion ne nous serait pas accordé ¯\_(ツ)_/¯ — ElioPrrl (d) 4 janvier 2023 à 17:32 (UTC)[répondre]
Alors on s’en tient au statu quo en ce qui concerne h5 à 100% et h6 à 90%.   Lorlam, ElioPrrl et Cantons-de-l'Est : est-ce qu’on a fait consensus sur les solutions à proposer. Y aurait-il des points à préciser ? --Denis Gagne52 (d) Le miraculé du 9e 4 janvier 2023 à 21:43 (UTC)[répondre]
Oui OK pour moi   Lorlam (d) 4 janvier 2023 à 21:52 (UTC)[répondre]
Ok pour moi aussi ! et puis, rétrospectivement, ça a une forme de cohérence : dans chaque catégorie de tailles, on a pris le nombre rond le plus gros. Seul hic que je comprends, t4 et t5 auront peu ou prou le même aspect par défaut (peut-être des différences de marges, cependant), mais l’argument que j’avance ci-dessus, emprunté à Lorlam, me semble plus important. — ElioPrrl (d) 5 janvier 2023 à 00:06 (UTC)[répondre]
Ça me va. Les tailles des modèles t2, t3... sont plus cohérentes. Pour {{t4}} et {{t5}}, on peut appliquer des line-height distinctes par défaut : 1.5em et 1.25em par exemple. — Cantons-de-l'Est p|d|d 6 janvier 2023 à 02:51 (UTC)[répondre]

Conclusion

modifier

  Acélan, Cantons-de-l'Est, Denis Gagne52 et Lorlam : Si je résume, une harmonisation provisoire consisterait à préciser dans les trois feuilles de style commons, mobile et epub (pour les deux premières, je rajouterai la condition que le titre soit dans un élément #text ou .text, de manière à n’affecter que les titres des transclusions) :

h2 {
   text-align: center;
   font-size: 150%;
   font-weight: normal;
   line-height: inherit;
}
h3 {
   text-align: center;
   font-size: 120%;
   font-weight: normal;
   line-height: inherit;
}
h4 {
   text-align: center;
   font-size: 100%;
   font-weight: normal;
   line-height: inherit;
}
h5 {
   text-align: center;
   font-size: 100%;
   font-weight: normal;
   line-height: inherit;
}
h6 {
   text-align: center;
   font-size: 90%;
   font-weight: normal;
   line-height: inherit;
}

Les tailles et les graisses sont celles choisies ci-dessus, l’interligne et l’alignement au centre sont les paramètres par défaut des modèles {{t2}} et suivants. Les modèles seront allégés des instructions redondantes avec les nouvelles feuilles de style. Auparavant, pour le cas particulier de {{t4}}, Cantons-de-l’Est se charge de rajouter automatiquement la graisse aux titres qui ne sont pas déjà en gras ou dont le paramètre fw= n’est pas précisé.

Il restera enfin à se poser la question des marges par défaut autour de ces titres, qui sont différentes selon que l’on consulte la page sur Internet, sur mobile, ou en ePub, ainsi que de la différence de police d’écriture entre {{t2}} et les autres niveaux ; mais chaque chose en son temps  ElioPrrl (d) 13 février 2023 à 13:08 (UTC)[répondre]

ça me convient comme ça : sur le principe, je suis pour qu'on ait davantage de cohérence, et dans la pratique, ça me semble convenir. --Acélan (d) 13 février 2023 à 17:48 (UTC)[répondre]
  ElioPrrl : Cela correspond bien à ce que nous avions convenu. Du moins je pense. Une question pour satisfaire ma curiosité : Est-ce nécessaire de préciser font-weigth, line-height, … quand la valeur est identique à ce que nous aurions obtenu par héritage ? Un commentaire : si j’ai forcé une largeur de 100% dans différents modèles, c'est que le texte n’était pas toujours centré sur certains mobiles. Je me demande s’il ne serait pas préférable de passer par mobile.css. Tu auras p-e une autre idée. Je te laisse en juger. Merci ! --Denis Gagne52 (d) Le miraculé du 9e 13 février 2023 à 18:53 (UTC)[répondre]
  Denis Gagne52 : Sauf erreur de ma part, font-weight est nécessaire pour annuler la valeur par défaut, bold, des navigateurs. Elle évitera aussi que les titres ne changent de graisse lors d’une mise à jour de Vector ou de Minerva.
Quant à line-height, je l’ai gardé parce qu’elle est en dur dans les modèles, et qu’elle est différente de la valeur commune, à savoir 1.6 en Vector et 1.65 en Minerva. Mais si tout le monde est d’accord, je pense que mettre line-height: inherit, i.e. à la même valeur que le texte courant, serait le mieux (de 1.5 à 1.6/1.65, la différence n’est pas bien grande).
Enfin, pour width, je le rajouterai à mobile.css. Étrangement, en testant avec Test d’affichage sur mon portable, je ne vois aucune différence entre t4, qui a width:100%, et t5, qui ne l’a pas, ni même entre t4 avec et t4 sans (quand je désactive la propriété dans l’inspecteur). Après, tu dis certains mobiles, c’est peut-être la raison pour laquelle je ne vois pas d’effet sur mon portable. — ElioPrrl (d) 13 février 2023 à 19:28 (UTC)[répondre]
Bonne réponse !   et oui à tout ce que tu proposes. C’est sur IOS (Ipad) que je notais une différence d’alignement horizontal, je pense que cela dépendait de la ligne où le modèle se situait en début de paragraphe ou pas, probablement que h2 et autres y adoptent une structure davantage similaire au span en mode bloc. Je n’ai jamais pu élucider avec certitude, mais avec width à 100%, le problème est résolu. --Denis Gagne52 (d) Le miraculé du 9e 13 février 2023 à 20:44 (UTC)[répondre]
Fait   et merci à tous pour votre collaboration !   Si vous voyez des problèmes (à cause des règles ci-dessus, ou à cause du width:100% demandé par Denis ou du break-inside:avoid par Lorlam que j’ai également rajoutés), je suis encore là  ElioPrrl (d) 27 février 2023 à 16:26 (UTC)[répondre]
ElioPrrl, On a bien noté votre pseudo.  Cantons-de-l'Est p|d|d 28 février 2023 à 12:48 (UTC)[répondre]
@ElioPrrl Tout me semble correct si ce n’est cette ligne présente dans tous les modèles : -->{{#if: {{{align|}}} | text-align: {{{center|}}}; }}<!--. Je pense qu’il aurait fallu retirer center et non align. De plus, les images sont bient positionnées en pdf. Il suffisait de purger le cache de ws-export. La commande est indiquée au haut de Epub.css. Beau travail ! Merci   --Denis Gagne52 (d) Le miraculé du 9e 28 février 2023 à 15:09 (UTC)[répondre]
@ElioPrrl   pour tout ce travail. Je constate un effet de bord qui ne me dérange pas particulièrement, mais qui pourra peut-être en gêner certains : les modèles {{acte}} (h3) et {{scène}} (h4) sont en maigre à l'export.
Je retourne traquer les t2mp et t3mp (plus que 1600 pages) --Acélan (d) 28 février 2023 à 17:32 (UTC)[répondre]
Bon courage @Acélan ! — ElioPrrl (d) 28 février 2023 à 17:36 (UTC)[répondre]
Merci :) C'est un peu fastidieux dans certains cas, mais ça permet de faire du ménage dans des ouvrages pris en charge par des personnes différentes n'ayant pas les mêmes pratiques et qui traitent une partie comme si elle ne faisait pas partie d'un tout. Acélan (d) 28 février 2023 à 17:39 (UTC)[répondre]


Colonnes

modifier

En modifiant un texte en m'appuyant sur Aide:Deux Colonnes, je me suis aperçu que sur les modèles ColG et ColD, le texte revient automatiquement à la ligne à chaque changement de page. Et cela dès le texte Quelques considérations sur la cautérisation actuelle, qui justement sert d'exemples. Je ne sais pas si ça concerne tous les modèles mais le problème est que cela touche des textes validés. --Favete linguistis (d) 9 mars 2023 à 14:14 (UTC)[répondre]

  Favete linguistis : Je n’ai jamais utilisé les modèles {{ColG}} et {{ColD}} mais en regardant le code, je peux vous assurer que ces deux modèles n’ont pas été construits pour maintenir la fluidité d’un paragraphe qui chevauche deux pages. Il ne le faisait pas en 2012 quand ces pages ont été transcrites et ne le fait pas davantage aujourd’hui. La meilleure façon de résoudre ce problème est selon moi de regrouper sur la première page tout le contenu d’un titre (colonne gauche et colonne droite séparément) avant de procéder à la transclusion. Je vous donne un aperçu avec INFLAMMATION ÉLIMINATRICE où j’ai réussi à faire disparaître les sauts de ligne indésirables. En exploitant les sections, il est possible d’obtenir le résultat que vous cherchez. --Denis Gagne52 (d) Le miraculé du 9e 10 mars 2023 à 04:18 (UTC)[répondre]

Global RfC filled to enable global abuse filters on large Wikimedia projects by default

modifier
Bonjour!

Apologies for writing in English. Aidez-nous à traduire dans votre langue.

On Meta-Wiki, a set of global abuse filters is maintained by Meta-Wiki's administrators and the stewards. Global abuse filters are a powerful tool designed to fight against long-term abusers that operate cross-wiki. It is especially useful (and often irreplaceable by other means) when a cross-wiki LTA starts to rapidly change IP addresses (when that happens, regular blocks are significantly limited due to the IP hopping).

As of today, all small/medium Wikimedia projects (as-determined by number of articles) are automatically subscribed to global abuse filters. They are not, however, enabled on several Wikimedia projects classified as large (except several large Wikimedia projects who opted-in, such as Wikidata). This makes it possible for global long-term abusers to vandalize a project with no global filters enabled, which makes it significantly more difficult for the Stewards to fight against the abuse.

By this message, I'd like to let you know I submitted a global RfC (request for comments), where I propose enabling global abuse filters on large Wikimedia projects as an opt-out feature. This change will make global abuse filters an even more effective tool for combating long-term abuse at the global level. Please feel free to participate in the discussion, which happens at Meta-Wiki.

Thank you for your time.

Sincerely,
--Martin Urbanec (discussion) 12 mars 2023 à 17:15 (UTC)[répondre]

Extension Graph désactivée

modifier

Hier, la Wikimedia Foundation a indiqué que dans l'intérêt de la sécurité de nos utilisateurs, l'extension Graph a été désactivée. Cela signifie que les pages qui affichaient auparavant des graphiques afficheront désormais une petite zone vide. Pour aider les lecteurs à comprendre cette situation, les communautés peuvent désormais définir un bref message qui peut être affiché aux lecteurs à la place de chaque graphique jusqu'à ce que cela soit résolu. Ce message peut être défini sur chaque wiki ici : MediaWiki:Graph-disabled. Le personnel de la Wikimedia Foundation examine les options disponibles et les délais prévus. Pour les mises à jour, suivez la tâche publique de Phabricator concernant ce problème : T334940.

--MediaWiki message delivery (d) 19 avril 2023 à 17:36 (UTC)[répondre]

Retour à la ligne

modifier

Bonjour, En utilisant le modèle {{Musique|dièse}} dans cette page (tableau en bas de page), il me fait des retours à la ligne non désirés. Comment faire pour les enlever ? Merci d’avance. --Tambuccoriel (d) 24 juillet 2023 à 09:20 (UTC)[répondre]

Je viens de corriger le modèle, mais on peut aussi utiliser directement les symboles Unicode. En cas de besoin, on pourrait faire des modèles {{dièse}} ou {{bémol}} comme sur Wikipédia, afin de gérer les espaces insécables. Seudo (d) 7 septembre 2023 à 12:26 (UTC)[répondre]

Temporary accounts for unregistered editors

modifier

Read this in your languageAidez-nous à traduire dans votre langue • Please tell other users about these changes

 
Next year, unregistered editors will start using temporary accounts.

In 2024, editors who have not registered an account will automatically begin using temporary accounts. These editors are sometimes called "IP editors" because the IP address is displayed in the page history.

The Trust and Safety Product team gave a presentation at Wikimania about this change. You can watch it on YouTube.

There is more information at m:IP Editing: Privacy Enhancement and Abuse Mitigation.

SGrabarczuk (WMF) (discussion) 30 septembre 2023 à 02:05 (UTC)[répondre]

Lien "Qualité des pages" mal rendu

modifier

Bonjour,

Dans le bas de [1] par exemple, je lis "<a href="/wiki/Aide:Qualit%C3%A9_des_pages" title="Aide:Qualité des pages">Qualité des pages</a>" et pas le lien habituel.

Challwa (d) 5 octobre 2023 à 22:54 (UTC)[répondre]

  Challwa : Effectivement, c’est le cas pour tout le monde depuis deux jours environ. Probablement une étourderie des développeurs lors de la dernière mise à jour de MediaWiki, qui a été déployée entre le 4 et le 5 octobre. Comme ce n’est pas bien grave, je pense qu’il suffit d’attendre la prochaine mise à jour. — ElioPrrl (d) 6 octobre 2023 à 10:06 (UTC)[répondre]

Ligne horizontale ondulée

modifier

Bonjour,

Y a-t-il un moyen d’afficher une ligne horizontale ondulée ? J’ai essayé de bricoler avec du CSS ou de trouver un modèle mais j’ai rien trouvé. Il s’agit de la ligne tout en bas de cette page. Darmo117 (Viendez parler !) 6 novembre 2023 à 10:52 (UTC)[répondre]

Bonjour   Darmo117 :, on peut combiner le modèle {{loop}} avec un fichier svg :
Il y a de nombreux svg de vaguelettes sur Commons : https://commons.wikimedia.org/w/index.php?search=rule+segment+wave.svg&title=Special:MediaSearch&go=Lire&type=image. Cunegonde1 (d) 6 novembre 2023 à 12:06 (UTC)[répondre]
Merci, je vais tester ça. Darmo117 (Viendez parler !) 6 novembre 2023 à 12:09 (UTC)[répondre]
  Darmo117 et Cunegonde1 : Il y a aussi ce modèle {{SVague}} que j’ai découvert récemment et que je viens d’ajouter à la catégorie Modèles de séparateurs Catégorie:Modèles de séparateur pour qu’il soit plus facile à retracer.--Denis Gagne52 (d) Le miraculé du 9e 6 novembre 2023 à 14:20 (UTC)[répondre]
Merci @Denis Gagne52, je découvre cette série de séparateurs, bien intéressants et sans doute plus efficaces que la proposition que j'ai faite. Cunegonde1 (d) 6 novembre 2023 à 16:00 (UTC)[répondre]
  Cunegonde1 :Je t’avoue que je ne l’ai pas utilisé encore. Voici comment je procédais jusqu’à présent :
Tu remarqueras l’absence de décalage dans l’ondulation.
Et avec le modèle on obtient :
                                                            
--Denis Gagne52 (d) Le miraculé du 9e 6 novembre 2023 à 18:33 (UTC)[répondre]

Mot magique NOTOC qui se fait retoquer

modifier

Bonjour, je ne comprends pas pourquoi malgré la présence de la balise NOTOC dans l'en-tête, une table des matières persiste à s'afficher juste avant la transclusion latine sur cette page ? J'ai l'impression que sur certaines autres pages, le fait d'éditer sans changement casse ou bien répare la chose... C'est mystérieux ! syb~anicium 19 janvier 2024 à 20:52 (UTC)[répondre]

Problème résolu ! Cela venait de la page latine, qui avait besoin d'un NOTOC dans le corps de page, et non dans l'en-tête... syb~anicium 21 janvier 2024 à 18:53 (UTC)[répondre]

Une extension CropTool sur la page d'édition ?

modifier

Bonjour à tous, en particulier les admins interface, je re produit ma proposition et demande dans les questions techniques.

  1. Serai-ce possible de mettre l'extension Croptool dans l'onglet outils dans la page édition ?

Cela aiderai grandement les débutants pour extraire des images sans passer par des modifications, des copier coller etc... L'extension est déjà intégrée sur l'espace Fichier: elle devrais pouvoir être aussi dans l’espace Page: sans trop de difficulté.

  1. En tout cas cela rendrai un bon service pour les débutants et un gain de temps pour les nombreuses images à extraire pour des encyclopédies.

Merci pour votre réponse, ou le renvoie vers une personne capable de cela. Sicarov (d) 25 mars 2024 à 22:14 (UTC)[répondre]

Moi je vote   Pour, c'est une bonne idée je trouve ! M0tty (d) 26 mars 2024 à 11:56 (UTC)[répondre]
Effectivement cela pourrait être une bonne idée, l’extraction d’image n’est pas la plus simple des manipulations à prendre en main.
Cela me semble soulever quelques questions auxquelles, n’ayant pas assez manipulé CropTool, je n’ai pas les réponses. Notamment :
  1. Ne devrait-on pas également ajouter CropTool aux gadgets Wikisource pour parfaire son intégration ? Actuellement il faut l’importer par javascript pour le retrouver dans l’espace Fichier.
  2. Dans le cas d’une utilisation de CropTool depuis Wikisource, où sont stockées les images ? Sur Wikisource, sur Commons, ou au même endroit que le fichier source ? Je n’ai jamais eu l’occasion d’essayer autrement que directement sur Commons. Mais avoir le gadget sur Wikisource pourrait poser des soucis de droits d’auteur si des images extraites de fichiers sur Wikisource (qui sont locaux justement parce qu’ils ne sont pas aux conditions de Commons) étaient déposées sur Commons.
Nivopol (d) 9 mai 2024 à 21:51 (UTC)[répondre]

Gadget Croptool accessible à partir de l’espace Page

modifier

En réponse à la demande de @Sicarov, j’ai adapté le script Gadget-CropTool.js pour qu’il soit utilisable directement de Wikisource fr.

Ce qu’il permet :

modifier
  1. Lancer directement Croptool en le sélectionnant dans la liste d’outils attachés à l’espace Page ;
  2. Charger la page courante en édition dans Croptool afin de la découper selon la taille de l’image qui s’y retrouve ;
  3. Inscrire le détail de l’opération dans le champ résumé au bas de la page en édition sur Ws.
  4. Possibilité aussi d’insérer un modèle {{Image}} ou autre dans la page d’édition (les lignes 38 à 43 du script ont été commentées pour désactiver cette option car le modèle Image n’est pas utilisé par tous les utilisateurs).

Installation

modifier
  1. Ajouter cette ligne à votre common.js personnel : importScript('User:Denis Gagne52/Gadget-CropTool-Ws.js'); corrigé

Limitations

modifier
  1. Le fac-similé doit se retrouver sur Commons ;
  2. Si plusieurs images sont présentes sur une même page, il est conseillé de les nommer ainsi …(page xx crop).jpg, …(page xx crop 2).jpg, …(page xx crop 3).jpg, etc.

Discussions à prévoir

modifier
  1. Opportunité de rendre l’outil disponible à partir des paramétres personnels comme tous les autres Gadgets.
--Denis Gagne52 (d) Le miraculé du 9e 14 mai 2024 à 01:01 (UTC)[répondre]
Bonjour @Denis Gagne52, un grand merci pour cette réponse à une de mes demande.
J'ai testé, mais l'adresse qui renvoie à l'outil avec le fichier en question, ne marche plus de mon côté, que ce soit avec le lien généré par le bouton, (https://croptool.toolforge.org/?title=Dictionnaire_de_la_Bible_-_F._Vigouroux_-_Tome_II.djvu&page=815) ou bien avec un lien croptool enregistré dans mon historique. https://croptool.toolforge.org/?title=Dictionnaire_de_la_Bible_-_F._Vigouroux_-_Tome_I.djvu&page=220&site=fr.wikisource.org. J'ai l'impression que le problème est hors de mon champ d'action... es ce que ça marche de votre coté ?
2. Limitation : je préciserai qu'il est conseillé de donné un titre explicite à l'image (page xx titre crop).jpg pour facilité une réutilisation ailleurs. Sicarov (d) 14 mai 2024 à 12:29 (UTC)[répondre]
Bonjour @Sicarov, J’ai modifié le nom du script pour User:Denis Gagne52/Gadget-CropTool-Ws.js et purgé. J’ai l’impression que Mediawiki conservait les deux scripts en cache à la même adresse. Actuellement les deux scripts fonctionnent chez moi. Peux-tu vérifier de ton côté ? Merci ! N-B : Le titre de l’image est celui proposé par Croptool. Je n’ai indiqué que la fin précédée par trois petits points. Denis Gagne52 (d) Le miraculé du 9e 14 mai 2024 à 13:26 (UTC)[répondre]
cela fonctionne, merci, le lien fonctionne bien.
  • Serait-ce possible de mettre le lien crooptooll dans l'onglet "Action" et non dans l'onglet général ? c'est le cas des actions renommer, luminosité, contraste ?
  • 4. L'insertion du modèle est une bonne idée si on peux choisir de le mettre ou non ? je n'ai pas pu tester. par exemple, j'ai déjà mis un modèle image dans les pages grâce à AWB : Page:Dictionnaire de la Bible - F. Vigouroux - Tome I.djvu/378
Sicarov (d) 14 mai 2024 à 14:01 (UTC)[répondre]
  • Lien déplacé dans Action : Fait   ; c’est mieux ainsi en effet
  • L’insertion auto d’un modèle va devenir un irritant à moins de le faire dans son espace personnel. Considérant le risque de collision entre deux scripts du même nom, comme ce fut le cas ce matin, il vaudrait mieux s’en tenir pour le moment aux 3 possibilités offertes actuellement.
--Denis Gagne52 (d) Le miraculé du 9e 14 mai 2024 à 19:47 (UTC)[répondre]

Bientôt : une nouvelle fonctionnalité de sous-référence – ​​essayez-la !

modifier
 

Bonjour,

Depuis plusieurs années, des membres de la communauté demandent une façon simple de réutiliser des références en précisant certains détails. Aujourd’hui, une solution pour MediaWiki arrive : la nouvelle fonctionnalité de sous-référence fonctionnera en wikicode et avec l’éditeur visuel en améliorant le système de notes de bas de page existant. Vous pourrez continuer à utiliser les différentes manières d’ajouter une note, mais vous rencontrerez surement des sous-références ajoutées par d’autres dans des articles. Plus d’informations dans la page du projet.

Nous aimerions avoir vos retours pour nous assurer que cette fonctionnalité fonctionne bien pour vous :

L’équipe des souhaits techniques de Wikimedia Allemagne prévoit de doter les wikis Wikimedia de cette fonctionnalité cette année. Nous contacterons auparavant les personnes créant et maintenant des outils et modèles liés aux notes de bas de page.

Votre aide est la bienvenue pour diffuser le message ! --Johannes Richter (WMDE) (talk) 10:36, 19 August 2024 (UTC)


modifier
Apologies for cross-posting in English. Please consider translating this message.

Hello everyone, a small change will soon be coming to the user-interface of your Wikimedia project. The Wikidata item sitelink currently found under the General section of the Tools sidebar menu will move into the In Other Projects section.

We would like the Wiki communities feedback so please let us know or ask questions on the Discussion page before we enable the change which can take place October 4 2024, circa 15:00 UTC+2. More information can be found on the project page.

We welcome your feedback and questions.
MediaWiki message delivery (d) 27 septembre 2024 à 18:57 (UTC)[répondre]

modifier

Hello everyone, I previously wrote on the 27th September to advise that the Wikidata item sitelink will change places in the sidebar menu, moving from the General section into the In Other Projects section. The scheduled rollout date of 04.10.2024 was delayed due to a necessary request for Mobile/MinervaNeue skin. I am happy to inform that the global rollout can now proceed and will occur later today, 22.10.2024 at 15:00 UTC-2. Please let us know if you notice any problems or bugs after this change. There should be no need for null-edits or purging cache for the changes to occur. Kind regards, -Danny Benjafield (WMDE) 22 octobre 2024 à 11:29 (UTC)[répondre]