Bonjour @ElioPrrl j'ai transcrit un livre contenant le mot "tarabiscotés", qui est surligné en rose, peut-être qui faudrait-il mettre "coté" entre balises \b pour éviter qu'il soit surligné lorsqu'il est inclus dans un mot plus long ?
Discussion utilisateur:ElioPrrl
Bonjour,
Pourquoi avoir remis ce Livre:Planck - Initiations à la physique, trad. du Plessis de Grenédan, 1941.djvu en "à corriger" alors que les pages sont toutes en jaune ou en gris ?
pardon une erreur, j'ai lu "validé" au lieu de "à valider"
pas de soucis merci
ElioPrrl : C’est un peu dommage que l’esperluette (&) soit considéré comme une erreur, car maintenant elle apparaît sur tous les textes du moyen-âge au XVIe siècle comme ici
Mince ! chez moi aucune esperluette ne se trouve surlignée. Je ne sais pas expliquer pourquoi nous voyons deux choses différentes. Cela date de longtemps ?
je viens de m’apercevoir de ça juste avant de te mettre le message
Tu es sur quel navigateur ? et avec quel habillage (ça se voit dans la section Apparence des Préférences) ?
En tout cas, je ne vise pas les esperluettes dans le gadget, sauf lorsque les espaces autour ont été oubliés, donc cela ne doit pas arriver. As-tu toi-même un complément personnel au gadget ?
Vector ancienne version 2010 et sou Safari (mac) ; et je n’ai aucun complément au gadget.
Je dois parti, je ne serai de retour que demain.
Merci de t’intéresser à la question.
Après avoir essayé sur plusieurs navigateurs, avec plusieurs habillages différents, je ne suis toujours pas parvenu à reproduire ton problème. Cette semaine avait lieu une mise à jour de Mediawiki ; je me suis dit que cela pouvait peut-être en être un effet secondaire. Mais visiblement la mise à jour épargnait Wikisource cette fois-ci, donc cela ne doit pas venir de là. Je ne sais vraiment pas quoi dire, désolé 
@Acélan et @Cunegonde1, vous qui me remontez souvent des problèmes de surlignage sur cette page de discussion, désolé de vous déranger, mais avez-vous les mêmes problèmes que Le ciel est par dessus le toit ?
Pourrais-tu me donner plus de détails : par exemple, est-ce que cela a lieu spécifiquement sur certaines pages (je ne sais pas : les poèmes et pas la prose, uniquement les pages avec {{Modernisation}}, etc.) ? sont-ce toutes les esperluettes sans qui sont surlignées, ou y a-t-il des exceptions ? le surlignage est-il bien exactement de la même couleur que les autres scanilles ? les esperluettes sont-elles décomptées dans le petit onglet Erreurs possibles quand on clique dessus, ou bien est-ce encore un nouveau lien dans la rubrique rubrique Outils qui les répertorie ? etc. Le mieux même serait de me fournir une capture de ton écran.
Aucun problème constaté sur l’esperluette dans plusieurs textes vérifiés dans l'espace principal comme dans l'espace page. Je précise que je suis sur vector 2010, j'ai vérifié sur linux, mac-os, et windows 11.
Non, aucun problème de ce genre.
Merci à vous deux ! Bon, le mystère reste entier.
ben je ne sais pas, j’essaierai de répondre à ta longue liste de questions prochainement, peut-être que ça vient de chez moi, je vais regarder ça de plus près.
J'ai trouvé un seul cas où l'esperluette était surlignée : quand elle se trouve juste après une parenthèse ouvrante (cf. cette page). Je précise que je corrige en ce moment essentiellement des pages où on trouve des esperluettes.
Bonjour,
J'ai eu une idée pour faciliter l'entrée des caractères spéciaux. Je ne sais pas si elle est facile ou non à mettre en place, je viens donc demander ton avis.
Le problème des caractères spéciaux est qu'ils sont très nombreux (quasiment 100 000 en Unicode) et que l'on a souvent besoin que d'une poignée d'entre-eux. Actuellement, l'interface (plus précisément la toolbar du Wikieditor) les groupe par langues ce qui permet de ne pas trop en avoir (201 pour le latin par exemple) mais cela fait encore beaucoup et surtout beaucoup dont on a généralement pas besoin (et inversement, certaines lettres sont encore manquantes). Pour moi qui travaille sur des ouvrages comme Lexique étymologique du breton moderne (qui contient des ḷ et des ṅ qui sont exotiques à côté de voyelles à macron plus courantes) l'interface m'oblige à passer constamment du latin au latin étendu (en général, je finis par faire des copier-coller et ne plus utiliser les caractères spéciaux...).
Du coup, je me suis demandé si on ne pouvait pas avoir un groupe en plus pour les caractères couramment utilisés par l'utilisateur, un peu comme la saisie prédictive des téléphones portables. Qu'en penses-tu ? Possible ou non ? et facilement ou non ?
Et sinon, sans aller dans le prédictif, sais-tu si je peux créer et ajouter mon propre groupe ?
Cdlt
Alors, franchement, ça dépasse beaucoup mes compétences. Par contre, je peux proposer quelque chose dont je tire profit tous les jours : le gadget caractères spéciaux. Il permet de remplacer automatiquement une séquence de caractères par une autre. Par exemple, on tape : ^oe, et cela donne : œ. Ayant corrigé des textes indianistes, avec leurs lots de lettres diacritées, je suis allé disséquer le gadget, et ai essayé de lui ajouter de nouveaux caractères. Ainsi, en rajoutant _. je rajoute un point souscrit, et avec ^. un point suscrit (syntaxe imitée de LaTeX). Est-ce que ça serait intéressant pour toi ?
Dommage, mais cela répond déjà à ma question, merci.
Oui, je connais ce gadget et je l'utilise régulièrement mais pas sûr que cela réponde complètement à mon besoin. Je suis tout de même intéressé (et si tu pouvais ajouter ^_ pour le macron ◌̄ ce serait super).
Je peux le faire, mais peut-être devrais-je consulter le Scriptorium auparavant ?
Par contre, je mettrais plutôt un tiret haut dans le code, pour conserver au tiret bas sa signification de « souscrit » : comme ça on peut avoir ^- pour le macron suscrit et _- pour le macron souscrit. En remplaçant le tiret haut par un point, une virgule, un tilde, un o, un u, un v, un ç, etc., on pourrait avoir les points, virgules, tilde, rond, brève, caron, cédille, etc. suscrits ou souscrits.
En attendant, si tu veux, tu peux créer une sous-page Spécial:MaPage/CaracteresSpeciaux.js (ou tout autre titre que tu préfères) et y copier :
function keycheck() {
tb = document.getElementById("wpTextbox1");
if(tb && mw.config.get('wgNamespaceNumber')!=8) {
tb.onkeyup = function(e) {
var key = (window.event) ? event.key : e.key;
var charCode = key.charCodeAt(0);
startPos = tb.selectionStart;
endPos = tb.selectionEnd;
if(endPos == startPos && ((charCode >= 65 && charCode <= 90) || (charCode >= 97 && charCode <= 122) || charCode == 39 || charCode == 45 || charCode == 46) ) {
m2 = tb.value.substring(startPos - 2, startPos);
m3 = tb.value.substring(startPos - 3, startPos);
m2_pre = tb.value.substring(startPos - 1, startPos+1);
f = tb.value.substring(startPos);
todo = false;
// Raccourcis de trois caractères
if(!todo) {
i = 3;
m = m3;
todo = true;
switch(m) {
case "a^-" : m = "ā"; break;
case "e^-" : m = "ē"; break;
case "i^-" : m = "ī"; break;
case "o^-" : m = "ō"; break;
case "u^-" : m = "ū"; break;
case "A^-" : m = "Ā"; break;
case "E^-" : m = "Ē"; break;
case "I^-" : m = "Ī"; break;
case "O^-" : m = "Ō"; break;
case "U^-" : m = "Ū"; break;
default : todo = false;
}
}
if(todo) {
var textScroll = tb.scrollTop;
h = tb.value.substring(0, startPos - i);
tb.value = h + m + f;
tb.selectionStart = startPos - i + m.length;
tb.selectionEnd = tb.selectionStart;
tb.scrollTop = textScroll;
}
}
}
}
}
$(document).ready(keycheck);
et importer cette sous-page dans ton Spécial:MaPage/common.js. Si je ne me trompe pas, cela devrait suffire pour les macrons. Si tu veux rajouter des caractères, ajoute-les juste avant le default.
Je tombe par hasard sur votre discussion et je m'incruste car cela m'intéresse :p Pour ma part, j'ai souvent besoin des æ, ſ et autres ligatures, ici et sur Vicifons où beaucoup de gadgets font défaut. J'ai néanmoins trouvé une parade, en installant l'application Clavier+ (Windows 7, mais il doit exister des équivalents).
Du coup, on peut facilement lui créer des raccourcis ! Alt+a me donne æ, Alt+s me donne ſ, etc. On peut même lui faire recopier des formules complètes (texte libre) : très pratique pour insérer des balises de façon rapide !
En plus ton idée a cet avantage que le logiciel fonctionne aussi hors de Wikisource !
Ton logiciel me rappelle par ailleurs une idée connexe à laquelle je pense depuis quelque temps : il faudrait que je trouve un moyen de permettre des raccourcis claviers comme Ctrl+I pour faire des italiques, Ctrl+Espace pour faire une espace insécable, et ainsi de suite — cela permettrait de gagner beaucoup de temps à mon avis.
L'article sur Framalibre pour ce logiciel qui se paie le luxe d'être distribué en GNU :)
Salut, Je pense que ceci n'est pas correct : en typographie française, on sépare les dates par un trait d'union (celui du 6), pas par un tiret... Voir par exemple w:Trait d'union#Dates et intervalles d'années, ceci ou cela.
Bonjour ! À strictement parler, je suis du même avis que toi. Seulement, dans notre cas, le tiret est encadré de deux espaces : cela impose un tiret cadratin (le tiret demi-cadratin, quand il y a vraiment une raison valable pour le faire — mais est-ce que cela existe vraiment ? — ne peut être utilisé que sans espace ; je mets à part les usages historiquement fautifs de plus en plus nombreux pour remplacer le tiret cadratin, en incise, en début de dialogue ou de liste). Je pense que la raison des espaces vient des dates approximatives (vers 800 — vers 850). Peut-être peut-on garder le tiret cadratin pour ces cas, et utiliser une division sans espaces pour le cas où la date ne comporte que des chiffres.
En effet, pour faire bien il faudrait distinguer selon que les dates sont exactes ou non...
Comme tout cela est très secondaire tout de même, et que je ne suis pas sûr que grand monde ait vu la différence, je ne pense pas me pencher sur le sujet de suite. Mais si tu veux le faire, aucun problème.
Oui, pas de problème. Si cela trouble trop ma susceptibilité typographique je m'y pencherai de mon côté 
.
Bonjour,
Je viens de corriger pas loin de 200 occurrences de Biaise (pour Blaise). Le seul faux positif que j'aie trouvé (avec majuscule, bien sûr) est une ancienne rue de Nantes. Voici donc une scanille facile à intégrer à ta liste.
Fait 
Merci pour ta vigilance !
Et j'en profite, puisque je recopie régulièrement ta page de scanilles. J'ai juste une interrogation à propos de "bottes", qui ne génère chez moi que des faux positifs. Tu as souvent rencontré "bottes" à la place d'autre chose ? "boîtes", j'imagine ?
Je ne sais pas en réalité, la règle remonte à la regex primitive de Cunegonde1 :. Effectivement je ne me rappelle pas avoir jamais corrigé une scanille grâce à cette règle.
Bonjour Modèle:Mention dans Flow et Modèle:Mention dans Flow à la base, en 2017 j'étais parti de la page Wikisource:Chasse aux coquilles pour créer une regex de recherche de scanilles. J'en ai rajouté au fil des rencontres, mais d'après mon souvenir la scanille botte pour boite était déjà présente à l'époque. Je n'ai jamais fait de statistiques sur les faux positifs, mais je ne me souviens pas d'avoir rencontré botte pour boite. Après, chaque ocr à ses propres scanilles ; utilisant en parallèle tesseract et Abbyy, je m'en rends bien compte. Les plus courantes étant "11 pour Il" avec Abbyy et "aufli pour auſſi" avec tesseract. Pour botte, je pense qu'il faut la supprimer de la liste.
Merci du retour ! Fait pour la suppression
Bonjour,
Il y a des soucis avec ce modèle, voir
car il ne permet pas l’indentation du paragraphe qui commence par "la trinité moderne"
où alors c’est le contributeur qui ne sait pas l’utiliser. Merci de m’en dire un peu plus
A part ce problème de Modèle merci de ne rien changer d’autre sur la page.
Comme écrit sur la page de documentation, il faut respecter les sauts de ligne indiqués dans celle-ci : il manquait ici le saut avant {{p fin}}. Sinon, le dernier paragraphe ne devient pas un élément p, mais un div.
Merci pour la modification mais je ne comprends pas.
Il ne faut pas écrire :
{{P début|taille du texte}}Premier paragraphe.
Second paragraphe.
… Dernier paragraphe.{{P fin}}Il faut écrire ainsi, comme indiqué dans la documentation :
{{P début|taille du texte}}
Premier paragraphe.
Second paragraphe.
… Dernier paragraphe.
{{P fin}}avec un saut de ligne après {{p début}}, et un avant {{p fin}}. Si on ne le fait pas, le premier paragraphe ou le dernier paragraphe, respectivement, ne seront pas encodés par MediaWiki comme des <p>, mais comme des <div>.
Ok, je crois avoir compris, mais si le contributeur avait laissé mes modèle "taille", je ne serai pas en train de perdre mon temps. Je ne dis pas que ce modèle n’est pas utile pour autant.
Si le contributeur avait laissé {{taille}}, il y aurait un problème : les interlignes seraient trop grands. Le modèle {{p début}} est plus adapté, et comme expliqué dans la documentation, il devrait être préféré lorsque tout un paragraphe est dans une autre taille de police.
Contrairement à vous, je trouve ce modèle des plus utiles. Voyez Mes mémoires (Groulx), tome II/vol. 3/Formes, moyens d’action ou de propagande, où il est utilisé à maintes reprises, tout comme dans d’autres chapitres des Mémoires.
@Raymonde Lanthier Mais vous avez tout à fait le droit d’avoir une opinion contraire à la mienne
Bonjour ElioPrrl,
Tu ne rejetteras pas, me semble-t-il, le choix d'un texte DE Molière à la place d'un texte SUR Molière en page d'accueil, mais tu auras tout lieu de critiquer mes démêlés avec le {{NOWIKI}} non maîtrisé (ça se voit !) qui dépare beaucoup le haut de la page...
Peux-tu arranger cela ?
Ou bien que faut-il faire ?
Bien amicalement, même si tu n'y arrives pas. (sourire)
Oh ce ne sont que des idées pour coller un peu aux actualités, certes pas des injonctions !
Je ne comprends pas trop ta question : je ne repère pas de problème flagrant sur aucune des pages Wikisource:Accueil ou Wikisource:Extraits. Par ailleurs, aucun modèle {{NOWIKI}} à ma connaissance, ni à celle de Wikisource, visiblement, qui met un lien rouge. Pourrais-tu me mettre un lien vers la page où le problème apparaît, voire, si tu le peux, vers ta modification qui te laisse insatisfait ? Je verrais ensuite comment je peux aider 
Bonjour,
Je croyais que l'harmonisation des modèles de titres concernait uniquement le rendu à l'export ; mais je constate, par exemple, que la taille des titres en {{m|t2}} a sensiblement diminué, au point d'être inférieure au modèle {{m|t3}}, ce qui est assez problématique. Y avait-il une quelconque nécessité de modifier à ce point un modèle autant utilisé ?
As-tu un exemple précis ? Car sur les pages de test (comme celle-ci) je ne vois aucun problème. La taille des titres est censée être décroissante par défaut : 150%, 120%, 100%, 100%, 90%. Quand nous disions harmoniser, nous entendions : faire que la taille soit la même sur Internet quel que soit le thème, sur mobile, en ePub et (dans la mesure du possible) en PDF. Pendant ce temps cela semble être le cas selon tous mes tests.
Je viens de remplacer les t2mp et t3mp sur cette page, et j'obtiens ce que je viens de décrire.
Ok, donc le problème apparaît en mode Page:. Je viens de repérer une règle dans commons.css qui contredisait la nouvelle en mode Page: seulement, mais je pense que cette règle est définie ailleurs dans Proofreadpage parce que la suppression ne semble pas avoir résolu le problème. Par contre, en transclusion, aucun problème. Je continue de creuser.
Résolu ! Il fallait attendre que la modification soit prise en compte.
(le coup de stress ! je vis depuis une heure dans la peur de tout casser par mes modifications aux feuilles de style 
)
C'est mieux comme ça :)
Effectivement, c'est stressant, de toucher aux feuilles de style
Par ailleurs, je viens de vérifier, les nouvelles tailles précisées dans les feuilles de style sont exactement les mêmes que celles qui étaient précisées en dur dans chaque modèle.
Impec ; je me disais bien que ce n'était pas volontaire...
Bonsoir @ElioPrrl,
En finalisant la correction de Livre:Bastié - Ailes ouvertes, 1937.pdf, nous avons constaté que sur la page d'Index, le titre du sommaire, qui est en T3, n'est pas centré mais aligné à gauche...
ça ne m'était jamais arrivé... est-ce que ça pourrait être le résultat d'une de tes modifs d'aujourd'hui sur ce modèle ?
Merci pour ton aide :)
Effectivement, auparavant le centrage était écrit en dur dans le modèle, et la modification le rajoute dans la feuille de style, mais pour ne pas affecter les pages de discussion, les aides, etc., je limite cette modification aux espaces principal et Page: ; il faut que je rajoute donc les index. Merci du signalement, je risque de ne pas faire la modification avant ce soir cependant
Fait
Merci !
tant que le centrage est OK en transclusion, c'est l'essentiel...
mais hier, on faisait un atelier de transcription expresse d'un bouquin, et on s'est vraiment demandé ce qui clochait dans nos edits, jusqu'à ce que je réalise que tu étais intervenu sur le modèle :D
Première fois que je modifie les feuilles de style, donc je crains de tout casser ! aussi, tu es vraiment bienvenue à pointer les angles morts de nos modifications. Avec Denis Gagne, Cantons-de-l'Est et Acélan, nous nous étions assurés que tout fonctionnait bien en transclusion, en mode Page, en ePub et en PDF, mais nous avions oublié les index. Cerise sur le gâteau : ton signalement a permis de simplifier les règles CSS, car au lieu de chercher les titres dans les différents espaces de nom concernés, je viens de rajouter une classe spécifique aux modèles {{t2}} et suivants, ce qui fera que les titres entre signes égal, ou ceux utilisant un autre modèle (comme {{t2mp}}) ne sont pas concernés.
Cantons-de-l'Est a ajouté automatiquement les paramètres au modèle {{t4}} qui compensent ma modification, de sorte que même si le comportement par défaut du modèle a changé depuis, les titres déjà insérés avec {{t4}} ont conservé exactement leur mise en forme antérieure. Acélan se charge de remplacer les occurrences des titres égal et des modèles comme {{t2mp}} par {{t2}} et suivants, ce qui ne peut se faire que manuellement (il a bien du courage !). Et ainsi on finira avec une seule syntaxe pour tous les titres, avec une série de modèles ayant tous les mêmes paramètres et le même fonctionnement ; et un nouveau qui fouinera dans les textes déjà corrigés ne risquera pas de tomber sur des modèles obsolètes.
Bref, je suis bien content de cette simplification. Et en plus, voilà un travail vraiment collaboratif !
Acélan travaille avec AWB, je crois, ce qui simplifie le remplacement de ce genre de choses... mais c'est vrai que son boulot est encore plus minutieux/fastidieux que le mien...
des modèles obsolètes, effectivement, il en reste encore quelques paquets... mais ne serait-ce pas plus simple de créer des redirections ?
On ne peut pas faire de redirection, parce que, dans ce cas précis, on ne peut pas établir de correspondances entre les anciens modèles {{t2mp}} et les nouveaux {{t2}} : ces anciens modèles étaient utilisés à tort et à travers, selon leur apparence plutôt que selon leur sens. Ainsi Acélan a rapporté de nombreux cas où le numéro de chapitre, par exemple, était dans {{t2mp}}, et le titre de chapitre dans {{t3mp}}, ou alors des cas où les titres de niveau inférieur étaient dans un modèle de niveau supérieur, etc. Donc il a préféré tout remplacer à la main !
ahhhh, oui, évidemment !!
c'est d'ailleurs pour cette raison que je les avais créés... pour avoir un modèle structurant, correspondant aux parties/chapitres/etc. du livre, sans mettre == blabla == dans le texte des pages, ce qui créait des sections, même en transclusion...
au passage, en atelier hier soir, j'ai eu beaucoup de mal à faire comprendre qu'il ne faut pas utiliser {{t2}}, {{t3}} et leurs petits frères pour faire la mise en forme des pages de Titre... -> exactement comme T2mp et T3mp sont utilisés en fait...
certains contributeurs (y compris expérimentés) me disait : cette règle n'est nulle part, et T2 met automatiquement en Sérif, c'est super !
il faudrait sans doute repréciser dans l'aide en ligne sur les Titres, et leur Documentation, que ce sont des modèles structurants et qu'il ne faut donc pas les utiliser juste parce que leur mise en forme par défaut correspond à ce que je veux afficher...
Les documentations ont été mises à jour , et la règle est depuis longtemps dans Aide:Guide du nouveau contributeur.
La modification hier a aussi en grande partie supprimé les différences entre les modèles : auparavant certains avaient de grands interlignes, certains des petits ; certains mettaient en gras, certains non ; etc. Maintenant, la seule chose qui les distingue est la taille du texte (150% — 120% — 100% — 100% — 90%). Leur interligne, leur graisse, leur couleur, tout est identique.
Enfin presque ! il reste la fonte serif pour le seul {{t2}}. Il est question de la supprimer, parce que, en réalité, elle a été ajoutée relativement récemment (en 2019) par un seul contributeur, sans aucune consultation du reste des wikisourciens (erreur de ma part : elle a été ajoutée à plus haut niveau, par les développeurs généraux, quand ils ont décidé de la police des titres encadrés par deux signes égal), et que cela introduit une diversité dans la police des textes transclus sans correspondance dans les fac-similés.