Wikisource:Scriptorium/Janvier 2023

Questions
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

Lancer une nouvelle discussion Aller à la fin de la page

Janvier 2023

Petit nombre de pages à corriger et à valider (Épisode 31)

En décembre 2022, 42 textes ont été corrigés, validés et rattachés à un fac-similé.

Un grand merci à :

• Havang(nl)
• JLTB34
• Lorlam
• Poslovitch
• ‎ EijiroSaito
• Cunegonde1
• M-le-mot-dit
• Hektor
• SyB~Anicium
• Stamlou
• Raymonde Lanthier
• George2etexte
• F0x1
• Newnewlaw
• Acélan
• VIGNERON en résidence
• Chrisric
• Viticulum
• Toto256

En 2022 ce sont 774 textes courts qui ont été traités voir les statistiques ici

La liste des textes à travailler pour janvier se trouve ici

N’hésitez pas à contribuer !

Quand la correction ou la validation est faite, n’oubliez pas de l’indiquer en face du titre avec le modèle {{fait}}.

Joyeuse année à tous et Merci pour votre collaboration.

Kaviraf, *j*jac et Le ciel est par dessus le toit 31 décembre 2022 à 10:19 (UTC)

Fichiers à déplacer sur Commons

Bonjour, Il y a un certain nombre de fichiers qui peuvent être déplacés sur Commons, notamment Catégorie:Gravures de la Bhagavadgita, Senart, 1922 et Catégorie:Images de L’Art bouddhique. J'ai un message d'erreur quand j'essaie de les exporter. Bonne année à tous ! Yann (d) 1 janvier 2023 à 13:41 (UTC)

Yann, Si j'ai bien analysé, la Catégorie:Gravures de la Bhagavadgita, Senart, 1922 se trouve présentement sur Commons ([1]) et vous êtes le créateur des fichiers là-bas. Est-ce que le moteur de Commons a accepté vos commandes de déplacement ? — Cantons-de-l'Est ^p|d|d 2 janvier 2023 à 12:54 (UTC)

Il reste des fichiers à déplacer. Yann (d) 2 janvier 2023 à 15:56 (UTC)

Et à supprimer de Wikisource une fois sur Commons. Hektor (d) 4 janvier 2023 à 08:32 (UTC)

Export de pièces de théâtre

Bonjour,

En testant l'export de pièces de théâtre, j'ai constaté la persistance d'un problème agaçant, auquel mes capacités limitées en css ne me permettent pas de remédier sans risque. Que ce soit en pdf ou en epub, les sauts de page interviennent n'importe où, alors que, pour bien faire, il faudrait qu'il ne puisse pas y avoir de saut de page entre les modèles {{personnage}} et {{personnageD}} et le début au moins de la réplique ; de même, il faudrait absolument éviter qu'il y ait un saut de ligne après le modèle scène, et même après le modèle acteurs. Est-ce possible d'ajouter une propriété page-break-after:avoid au css qui commande l'export ? ou est-ce que ça pose un problème dont mes connaissances trop limitées ne me permettent pas de me rendre compte ?

J'en profite pour souhaiter une très bonne année à tous les Wikisourciens, à ceux qui aident la communauté en inventant des modèles pratiques, en réglant des problèmes plus ou moins techniques, ou qui contribuent de quelque façon constructive que ce soit. Acélan (d) 2 janvier 2023 à 08:42 (UTC)

Bonjour à tous. En effet, j'ai beaucoup édité et exporté des pièces de théâtre (en pdf), et je suis d'accord avec @Acélan sur le fait qu'il n'est pas esthétique d'avoir le numéro d'une scène sur une page et la liste des intervenants donnée par le modèle "acteurs" sur la page suivante... de même avec le nom d'un "personnage" et la réplique correspondante... Je m'étais habitué à cet état de fait ; mais c'est clair qu'il serait sympa de pouvoir corriger ça ! Lorlam (d) 2 janvier 2023 à 09:55 (UTC)

Acélan et Lorlam : On ne peut plus d’accord. Mais en réalité tout ce qu’on peut faire est déjà fait : le break-after est déjà ajouté (directement dans le modèle {{Personnage}}, et via la feuille de style commune pour les titres de scènes et d’actes). Le problème vient au moins de calibre, par qui passe l’export, qui semble ne pas reconnaître cette propriété. Il semble même qu’aucun dispositif de lecture (calibre, donc, mais aussi Kindle, MobiReader, etc.) n’appliquent ces propriétés. Dans cette famille de propriétés, et selon mes tests, seule la valeur break-blabla: always semble être vraiment reconnue : c’est évidemment la plus simple à implémenter.

Dernière remarque : pour que ces propriétés puissent avoir un effet, ne pas faire suivre ces modèles d’un bloc vertical vide comme peut le faire {{Interligne}} ou de plus de deux retours à la ligne (je veux dire de plus de retours à la ligne que nécessaires pour créer un nouveau paragraphe) ; autrement dit, les espaces verticaux après ces modèles doivent être contrôlés uniquement via le paramètre de marge m (pour {{Personnage}}) ou mb (pour {{t2}} et consorts). — ElioPrrl (d) 2 janvier 2023 à 11:17 (UTC)

Flûte... Mais merci @ElioPrrl pour la réponse. Y a-t-il un espoir d'évolution du côté de Calibre ? Acélan (d) 2 janvier 2023 à 11:21 (UTC)

Acélan : Honnêtement, je ne sais pas ; seulement je n’ai rien trouvé sur Internet qui indique clairement une volonté d’amélioration de ce côté-là. — ElioPrrl (d) 2 janvier 2023 à 11:31 (UTC)

Acélan :, J'ai fait plusieurs tests avec du code CSS. Voici deux possibilités qui fonctionnent chez moi.

<p style="display:block; page-break-inside:avoid;">texte texte...</p>

ou

{| style=page-break-inside:avoid;

|----

| texte texte...

|}

Toutefois, la granularité de {{personnage}} et de {{personnageD}} est trop fine pour pouvoir envisager de les modifier de façon utile. Je ne connais pas suffisamment les pièces de théâtre pour déterminer ce qui est le mieux.

Bonne chance pour la suite.

— Cantons-de-l'Est ^p|d|d 2 janvier 2023 à 22:58 (UTC)

On ne peut pas à mon avis utiliser break-inside (les propriétés page-break-blabla sont normalement obsolètes), parce qu’il ne faut pas empêcher les sauts de page dans la réplique qui suit l’indication de personnage. Ce point d’ailleurs avait été abordé lors de la consultation sur l’amélioration de WsExport, et Denis Gagne52 avait proposé cette solution, et on était tombé d’accord qu’elle n’était pas appropriée. Les développeurs ont négligé la question, en disant que cela devrait se régler en modifiant les modèles sur chaque Wiki, ce qui est apparu tout à fait insuffisant, donc. — ElioPrrl (d) 2 janvier 2023 à 23:10 (UTC)

Besoin d'aide pour créer et déposer un fac-similé

Bonjour, j'aimerais importer sur Wikisource un nouveau texte (Le nouveau Panurge de Guillaume de Reboul) mais je n'ai jamais importé de nouveau livre auparavant. Je souhaitais donc savoir si quelqu'un aurait le temps de bien vouloir s'en occuper et merci d'avance.

Lien vers le texte sur Gallica : https://gallica.bnf.fr/ark:/12148/bpt6k1522233m/f27.item.r=guillaume%20reboul# Rafavannay (d) 2 janvier 2023 à 11:06 (UTC)

Rafavannay : C’est Fait  : Livre:Reboul - Le nouveau Panurge, 1614.djvu. L'OCR n’est pas bon car le texte comporte beaucoup d'ajouts manuscrits (soulignements etc.) Cunegonde1--Cunegonde1 (d) 2 janvier 2023 à 18:17 (UTC)

Merci beaucoup @Cunegonde1, je me débrouillerai pour la retranscription avec l'OCR...

Comme le texte est assez ancien, je me demandais si je devais laisser la graphie ancienne, c'est-à-dire les s long ( ſ ) et les v pour les u ainsi que les i pour les j, ou bien est-ce que je le modernise pour qu'il soit plus facilement lisible par les autres utilisateurs ? Rafavannay (d) 3 janvier 2023 à 07:40 (UTC)

Rafavannay :, l’usage sur wikisource est de respecter entour point le fac-similé, donc pas de modernisation ; pour la modernisation, il y a un modèle à ajouter quand le texte est corrigé et transclus, n’hésitez pas à revenir vers moi à ce moment là. --Le ciel est par dessus le toit ^Parloir 3 janvier 2023 à 07:52 (UTC)

Rafavannay :Pour l'OCR, vous pouvez essayer les outils de WS (Tesseract et Google) pour voir si c'est moins mauvais. Pour la transcription, je préfère garder la graphie originale stricte avec un modèle {{abr|abreviatiõ|abréviation}} pour les abréviation avec tilde, comme dans Le Premier acte du Synode nocturne des Tribades, Lémanes, Unelmanes, Propétides à la ruine des biens, vie & honneur de Calianthe, du même auteur que j'ai corrigé il y a quelques temps. Vous pouvez également utiliser l'option de {{modernisation}} pour laisser le choix au lecteur. Cunegonde1 (d) 3 janvier 2023 à 07:52 (UTC)

Livre:Dictionnaire analytique d’économie politique.djvu

Il reste une page à corriger sur ce livre signalé comme à problème , en fait le fs est bon, il s’agit seulement d’établir un petit tableau. Merci déjà à celui qui s’en chargera, pour passer le livre en "à valider". Le ciel est par dessus le toit ^Parloir 2 janvier 2023 à 14:12 (UTC)

Fait — Cantons-de-l'Est ^p|d|d 2 janvier 2023 à 19:55 (UTC)

Cantons-de-l'Est : Merci --Le ciel est par dessus le toit ^Parloir 3 janvier 2023 à 12:42 (UTC)

Aéronautique et/ou Aviation ???

Bonjour,

Il existe actuellement deux catégories très proches : la Catégorie:Aéronautique et la Catégorie:Aviation...

La Catégorie:Aéronautique est référencée dans la Catégorie:Aviation, et la Catégorie:Aviation est référencée dans la Catégorie:Aéronautique !... et... les deux sont reliées à la Catégorie:Transport...!!!

A mon sens, ces deux catégories sont redondantes... Déjà la différence de signification entre les deux est assez subtile (voir pour info la page https://fr.wikipedia.org/wiki/Aviation), et le classement des documents dans l'une ou l'autre de ces catégories n'est pas toujours logique et semble assez aléatoire... sans dire que beaucoup de documents sont carrément classés dans les deux !

S'il fallait n'en garder qu'une, je préférerais la Catégorie:Aéronautique, car beaucoup de textes du domaine public concernent les aérostats ou ballons dirigeables, qui peuvent faire partie de cette catégorie plus large, alors que "normalement" le terme d'"Aviation" ne devrait concerner que les avions... D'ailleurs, actuellement, plusieurs textes sur les aérostats sont classés par "erreur" dans la catégorie "Aviation"...

Qu'en pensez-vous, faut-il :

• ne garder qu'une seule catégorie : c'est ma préférence et personnellement je pencherais pour la Catégorie:Aéronautique…
• garder les deux (éventuellement en mettant la Catégorie:Aviation en dessous de la Catégorie:Aéronautique) mais en mettant une règle pour s'y retrouver ?
• renommer la catégorie "Aviation" en "Aéronefs" et garder "Aéronautique" ???

Je suis prêt à faire les changements de référencement des textes pour unifier le classement, selon l'avis majoritaire... a+ Laurent Lorlam (d) 2 janvier 2023 à 18:24 (UTC)

Lorlam, Selon mon interprétation, la catégorie Aéronautique est complémentaire à la catégorie Aviation. La première se rapporte à l'art de naviguer, alors que la deuxième se rapporte aux avions. Les aéronefs sont tous les objets qui peuvent soutenir un vol atmosphérique pendant une longue période : ballons, dirigeables, aérostats, hélicoptères, gyroptères, planeurs, deltaplanes, ULM, avions... Les avions forment un vaste ensemble d'aéronefs : avions à une aile, avions à deux ailes, avions à réaction, avions à turbopropulseur, avions à hélices, hydravions... Selon moi, il faudrait plutôt une catégorie Aéronefs qui englobe la catégorie Aviation et sous laquelle il faudrait classer tous les autres aéronefs. Pour la catégorie Aéronautique, je doute : sous Aéronefs ou indépendante ? — Cantons-de-l'Est ^p|d|d 2 janvier 2023 à 19:08 (UTC)

Exports de {{t2}}, {{t3}}, {{t4}}, {{t5}} et {{t6}}

Bonjour,

Quelques personnes ont observé que je tente d'améliorer les exports de livres validés depuis quelques semaines. En lien avec ces travaux, trois trucs m'ennuient depuis un bon moment.

Tailles relatives

Les tailles relatives des textes inscrits dans {{t2}}, {{t3}}, {{t4}}, {{t5}} et {{t6}} sont cohérentes dans les pages Wikisource et dans les pages epub, mais pas dans les PDF.

On peut forcer les tailles relatives ; WsExport les reconnaît. Dans cette page, vous pouvez comparer mes propositions avec les tailles par défaut. Demandez également un export en PDF pour observer ce que je mentionne. Que pensez-vous de la proposition de forcer les tailles relatives ?

— Cantons-de-l'Est ^p|d|d 2 janvier 2023 à 18:54 (UTC)

Ok : Je suis  Pour les nouvelles propositions... et en tout cas il serait bien que le rendu à l'export "pdf" soit proche de celui en "epub" Lorlam (d) 2 janvier 2023 à 21:31 (UTC)

... par contre il serait bien de pouvoir paramétrer la taille, car il arrive qu'il y ait plusieurs tailles de caractères dans le même titre (par exemple sur cette Page:La Saga de Nial, trad. Dareste, 1896.djvu/9... mais la différence de taille qui est visible à l'écran ne l'est plus à l'export :-( Lorlam (d) 2 janvier 2023 à 21:46 (UTC)

Pour moi, je pense qu’il n’est pas nécessaire de faire de changements en réalité, parce que l’échelle actuelle me paraît très satisfaisante, et déjà surestimée par rapport à la moyenne des fac-similés ; s’il devait y avoir changement, pour rassurer Lorlam, je pense que Cantons-de-l’Est n’avait pas l’intention d’abolir la possibilité de choisir le corps du texte via fs=. Je le précise systématiquement d’ailleurs, ayant pour habitude de mesurer le corps de texte sur le fac-similé, qui est quasiment toujours inférieur au corps de texte par défaut. Quant au problème de taille en PDF, Denis Gagne52 : avait déjà expliqué que cela venait du plus profond de Calibre, et que tous nos ajustements sur Wikisource seraient de toute façon modifiés lors de l’export PDF. — ElioPrrl (d) 2 janvier 2023 à 22:59 (UTC)

ElioPrrl, Calibre reconnaît les tailles inscrites dans le code CSS ; téléchargez cette page en epub et PDF.

Non, non, je vous assure : prenez un double-décimètre, vous constaterez par exemple qu’il n’y a aucune différence de taille entre la ligne à 150% et la ligne à 130%. Plus précisément, Calibre impose une échelle de taille, et si la taille entrée par l’utilisateur ne correspond pas à l’une des valeurs de cette échelle, Calibre arrondit à la valeur de l’échelle la plus proche. Je renvoie à la discussion que je mentionne ci-dessus pour un exemple flagrant de la distorsion en PDF : au-dessus d’une certaine taille, tout apparaît en PDF au même corps. Donc il faudrait, pour bien faire, connaître les valeurs utilisées par Calibre pour les utiliser comme valeurs par défaut, pour être sûr que l’export PDF ne modifie rien. Quant à l’export ePub, en effet il ne pose aucun problème ; ce que je disais plus haut ne s’applique qu’au PDF. — ElioPrrl (d) 3 janvier 2023 à 16:24 (UTC)

Couleur

Dans les exports (epub et PDF), la couleur des textes inscrits dans {{t3}} est bleu royal pastel, alors que les couleurs de {{t2}}, {{t4}}, {{t5}} et {{t6}} est noir.

Il est facile d'uniformiser la couleur de {{t2}}, {{t3}}, {{t4}}, {{t5}} et {{t6}}. On peut indiquer la couleur noir dans les modèles (code CSS : color:black;) ; WsExport la reconnaît. Demandez l'export en PDF de cette page pour comparer. Qu'en pensez-vous du projet de forcer la couleur ?

— Cantons-de-l'Est ^p|d|d 2 janvier 2023 à 18:54 (UTC)

Je n'ai pas vraiment d'avis marqué, mais je trouve l'export en bleu royal pastel plutôt esthétique... après on peut se demander pourquoi le "t2" n'est pas bleu aussi. J'aurais plutôt tendance à faire "t2" et "t3" en bleu (comme les Actes et Scènes du théâtre) et les autres en noir... Lorlam (d) 2 janvier 2023 à 21:38 (UTC)

Je suis pour harmoniser, comme Cantons-de-l’Est, mais sans préciser la couleur de remplacement. Je propose donc de supprimer toute mention de couleur. Cela harmonisera les différents titres, qui seront par défaut de la même couleur que le texte ; mais cela permettra en plus à l’utilisateur qui le souhaite de régler lui-même la couleur du texte selon son dispositif de lecture, ce qui affectera le corps du texte et les titres en même temps, alors qu’en imposant aux titres une couleur dans les feuilles de style (ici black) seul le corps du texte sera affecté par le changement voulu par l’utilisateur. Par exemple, préciser black peut conduire en mode sombre à ne plus voir le titre en passant en mode sombre ; pour que sa couleur s’adapte, il vaut mieux ne pas la préciser. La même remarque d’ailleurs vaut pour les modèles Acte/Scène au théâtre, qui seraient avantageusement remplacés par t2 et consorts. Je suis personnellement contre le bleu parce qu’il me semble diminuer le contraste pour les personnes mal-voyantes, ne ps être appuyé par un parallèle avec aucun fac-similé, et pour tout dire, sentir son Word à plein nez.

Par parenthèse, au fond, je suis persuadé que l’idée qu’un titre doit toujours être plus gros que le corps du texte, et souvent en gras ou en couleur, vient de la diffusion de Word et de ses titres préformatés ; si l’on considère nos fac-similés, et si l’on lit un livre en Folio, GF ou toute autre collection de diffusion importante, à vue de nez, l’immense majorité des titres, sauf ceux en pleine page, sont noirs, d’une graisse normale et d’une taille égale ou à peine supérieure (120% au maximum) au texte courant. — ElioPrrl (d) 2 janvier 2023 à 22:45 (UTC)

Bonjour, personnellement, je lis beaucoup de nuit sur tablette en mode inversé (écran noir, caractères blancs) avec un contraste très faible pour ne pas déranger. C'est très confortable, si ce n'est que que les caractères colorés et en particulier les appels de note ne sont pas visibles. Je suis par conséquent réticent à toute coloration des caractères dans les titres ou le corps du texte. Cunegonde1 (d) 3 janvier 2023 à 06:19 (UTC)

Il me semble d’ailleurs que dans les feuilles de style, au moins pour l’export, le modèle {{Personnage}} est affecté d’une couleur gris très foncée, qu’il serait judicieux d’enlever pour les mêmes raisons, afin que les mentions de personnage soient de même couleur que le texte courant. — ElioPrrl (d) 3 janvier 2023 à 11:16 (UTC)

Graisse

J'observe que les textes passés à {{t2}} sont en gras partout (Wikisource et exports). J'observe que les textes passés à {{t4}} sont en gras dans les exports (epub et PDF). Demandez l'export en PDF de cette page pour comparer.

Je suggère que les textes passés à {{t2}}, {{t3}}, {{t4}}, {{t5}} et {{t6}} soient sans graisse ; WsExport la reconnaît. Que pensez-vous de supprimer la graisse ?

— Cantons-de-l'Est ^p|d|d 2 janvier 2023 à 18:54 (UTC)

Je préfère garder la graisse au moins jusqu'à "t4" pour que les titres ressortent par rapport à du texte "normal"... et à partir de "t5" on peut enlever la graisse car se sont des "tout petits titres". Lorlam (d) 2 janvier 2023 à 21:42 (UTC)

J’appuie la proposition de Cantons-de-l’Est : les titres ne devraient être en gras que s’ils le sont dans le fac-similé, c’est-à-dire quasiment jamais. À noter : on peut d’ores et déjà aller contre le comportement standard en précisant fw=normal, qui supprime toute graisse. — ElioPrrl (d) 2 janvier 2023 à 22:50 (UTC)

• De mon côté la graisse des titres de niveau h2 correspond à celle définie par vector : font-weight: normal;, alors que pour h4, je retrouve bien : font-weight: bold;.
• Je ne suis pas convaincu qu’il faille modifier ces modèles après tant d’années. Normalement, ils auraient dû nous servir à établir la hiérarchie des titres, mais comme cette notion de hiérarchie à partir des balises n’est pas pleinement supportée dans Wikisource ni dans ws-export, certains usagers ont utilisé {{t4}} uniquement parce que l’habillage gras leur convenait mieux ou encore {{t3}} au lieu de {{t2}} simplement pour réduire la taille du titre. Il est p-e un peu tard pour modifier le comportement de ces modèles. En ce qui concerne la couleur bleue, cette portion de css semble provenir de Calibre. Je m’y suis habitué, mais le noir me conviendrait bien aussi. --Denis Gagne52 (d) ^{Le miraculé du 9e} 3 janvier 2023 à 03:59 (UTC)

  Oui. Je suis d'accord avec @Denis Gagne52 dans la mesure ou, moi aussi, je choisis souvent entre "t2" et "t3", d'avantage par rapport au rendu à l'écran et à l'export, que par rapport à la hiérarchie des titres... donc, effectivement, modifier notablement la taille des polices amènerait certainement à perturber une mise en page qui a souvent été ajustée par les contributeurs qui éditent les textes... précisément pour que la mise en page soit correcte à l'export. Après, il reste possible de faire des ajustement "mineurs" s'il y a un réel intérêt. Lorlam (d) 3 janvier 2023 à 07:25 (UTC)

Vous mettez le doigt sur un gros problème : ces modèles ont, au début surtout, été utilisés contre leur sens. C’est quelque chose qu’il faudrait peut être plus clairement expliquer, en mettant plus en avant tous les paramètres de mise en forme fs, fw, mt, mb, etc. Personnellement, je précise systématiquement au moins ces quatre paramètres, parce que, comme la discussion sur la graisse de t2 semble le montrer, en réalité la mise en forme par défaut de ces titres varie selon le thème du site et le format exporté ; tout préciser permet d’unifier la mise en forme sur tous les dispositifs de lecture (sauf en ce qui concerne le corps du texte en PDF, cf. la conversation citée plus haut avec Denis Gagne52). Cela ne fait pas perdre beaucoup de temps, car une fois le réglage fait pour un titre de niveau donné, il suffit de copier-coller pour tous les autres. — ElioPrrl (d) 3 janvier 2023 à 11:22 (UTC)

C'est vrai, mais l'utilisation fine des modèles avec tous les paramètres est plus difficile et contraignante pour des contributeurs "non experts", qui s'intéressent d'avantage au contenu qu'à la mise en forme détaillée... Par ailleurs, vu le nombre déjà important de modèles à connaitre pour éditer des textes sur WS, même la plupart des contributeurs "expérimentés" (je suppose) doivent utiliser des modèles simplement, en recopiant d'un livre sur l'autre une présentation qui leur va bien (c'est aussi mon cas de temps en temps pour certaines mises en forme). Et augmenter la complexité d'utilisation des modèles viendrait à mon sens d'avantage décourager les déjà rares contributeurs, pour n'en satisfaire qu'une poignée... / on peut d'ailleurs constater le peu de personnes intéressées ayant répondu sur le sujet / Donc, modifier notablement le rendu à l'export des modèles ferait à mon sens plus de mal que de bien, et risquerait de "casser" le rendu qui a été délibérément sélectionné par les contributeurs éditeurs ou valideurs des textes. Bon, après, comme je le disais plus haut, je ne suis pas contre quelques ajustement "mineurs" s'il y a un "réel intérêt"... mais le jeu en vaut-il vraiment la chandelle ??? je n'en suis pas sûr... Lorlam (d) 3 janvier 2023 à 15:44 (UTC)

Taille des appels de note

J’ouvre un nouveau front sur la question : je propose de limiter automatiquement la taille des appels de note, qui deviennent démesurément grands dans les titres (par exemple ici). À la main, on peut encadrer par un {{t}}, mais je propose de l’automatiser via la feuille de style commune avec font-size: min(.8em, 12px). Selon mes calculs, cela ne réduirait pas la taille de l’appel de note dans le corps du texte, mais seulement dans les textes composés en plus gros corps. Cela nécessitera peut-être cependant d’ajuster la valeur de top (testé). — ElioPrrl (d) 2 janvier 2023 à 22:59 (UTC)

 Pour.

Pour ce qui est des autres propositions, je n'ai plus de liseuse, alors je n'ai pas tellement d'avis sur tous les aspects purement esthétiques liés à l'export (le point que je soulevais plus haut ne relève pas de l'esthétique, mais j'ai bien compris qu'il n'est pas près d'être résolu). Acélan (d) 3 janvier 2023 à 15:29 (UTC)

 Pour aussi. Lorlam (d) 3 janvier 2023 à 15:57 (UTC)

 Pour --Raymonde Lanthier (d) 3 janvier 2023 à 16:45 (UTC)

 Pour Bonne idée et ce serait bien de s’assurer que le résultat escompté soit atteint en pdf pour tous les niveaux de titre.--Denis Gagne52 (d) ^{Le miraculé du 9e} 4 janvier 2023 à 03:12 (UTC)

Proposition

Plusieurs idées intéressantes ont été émises ici. Malheureusement on n’a pas beaucoup progressé si ce n’est pour les appels de notes dont l’application demeure assez réduite. Je propose que nous reprenions chaque sujet séparément sur la page Wikisource:Questions techniques. Nous pourrions revenir ici si nous réussissons à faire consensus quant à la faisabilité et à l’opportunité d’apporter des changements. Une invitation est lancée aux intéressés à me rejoindre sur Questions techniques#Taille, couleur et graisse des titres t2, t3, t4, t5 et t6... ! --Denis Gagne52 (d) ^{Le miraculé du 9e} 4 janvier 2023 à 03:12 (UTC)

Demande de retrait de mes droits d'administrateur

Bonjour ! N'étant pratiquement plus actif sur Wikisource (j'ai délocaliser toute mon activité sur Wikidata), je demande publiquement à nos bureaucrates Zyephyrus et Le ciel est par dessus le toit : de bien vouloir me retirer mes droits d'administrateur dont je n'ai plus guère l'utilité. J'encourage d'autres personnes à candidater au statut d'administrateur si elles souhaitent s'investir plus au sein de cette communauté. --Jahl de Vautban (d) 3 janvier 2023 à 13:50 (UTC)

Jahl de Vautban : C’est bien dommage… Les bureaucrates ne peuvent pas retirer les droits d’administrateur, il faut faire la demande auprès des Stewards, ne parlant pas l’anglais, j’espère qu’il y a une info ici pour t’aiguiller. Bon vent… --Le ciel est par dessus le toit ^Parloir 3 janvier 2023 à 15:08 (UTC)

IMPORTANT : Rapport d'activité des administrateurs

Bonjour.
En 2013, une politique concernant la suppression des « droits avancés » (administrateur, bureaucrate, administrateur d'interface, etc.) a été adoptée par consensus de la communauté mondiale. Selon cette politique, les stewards examinent l’activité des administrateurs sur tous les wikis de la fondation Wikimedia sans politique d’inactivité. À notre connaissance, votre wiki n’a pas de processus formel pour supprimer les « droits avancés » des comptes inactifs. Cela signifie que les stewards s’en chargeront conformément à la Vérification de l’activité des administrateurs.

Nous avons constaté que les utilisateurs suivants étaient inactifs au regard des critères fixés (pas de modification ni d’action journalisée pendant plus de 2 ans) :

1. Rical (administrateur)

Ces utilisateurs vont bientôt recevoir une notification leur demandant de démarrer une discussion avec la communauté s’ils souhaitent conserver quelques-uns ou la totalité de leurs droits. Si les utilisateurs ne répondent pas, alors leurs droits leurs seront retirés par les stewards.

Cependant, si votre communauté souhaite établir son propre système de vérification de l’activité à la place du système commun, prendre d’autres décisions au sujet de ces comptes inactifs détenteurs de droits, ou possède déjà ses propres règles, dont nous n’avions pas connaissance, alors signalez-le aux stewards de Meta-Wiki pour que nous sachions que nous ne devons plus procéder à ces vérifications sur votre wiki. Merci, Stanglavine (d) 4 janvier 2023 à 10:40 (UTC)