Wikisource:Bugs signalés et améliorations demandées

La bibliothèque libre.
Aller à : navigation, rechercher


Labeled Section Transclusion[modifier]

  • Aide:Labeled Section Transclusion : introduit des sauts de ligne, ce qui peut détruire la mise en page ([1]). Marc (d) 4 octobre 2011 à 10:00 (UTC)
  • ## s1 ## problème de saut de ligne supprimé à modifier, est-ce souhaitable ? ne va-t-on pas cassé du wikicode déjà existant ?
  • <phe> oui, je vois, faut parser deux fois, une fois avec /##[\s]*(.??)[\s]*##[\s]*\n/ et une avec /##[\s]*##\n/ cf [2] easy_lst()
  • Pareil dans le cas général mais configurable par wiki, le problème est qu'une modification faite par une personne n'activant pas ce gadget peut être défaite involontairement par une personne l'ayant activé

Moteur de rcherche[modifier]

  • Le moteur de recherche n'indexe pas les pages transcluses.
    • Idée de projet pouvant faire l'objet du Google Summer of Code 2012 : [3]. Pyb (d) 21 janvier 2012 à 13:16 (UTC)

Statistiques[modifier]

  • Corriger les statistiques de WMF : article count comptabilise les articles présents dans les espaces de noms (0, 102, 104 et 106) qui ont un lien interne[1]. Remarques : 1) Demander la comptabilisation des pages sans liens, 2) Numéro d'espaces de noms diffèrent entre les wiki de Wikisource. Pyb (d) 19 décembre 2011 à 16:13 (UTC)

Extensions[modifier]

Proofread Page[modifier]

  • [4] les nums de pages ne s'affiche pas dans user:, c'est gênant. — Phe 15 octobre 2011 à 17:08 (UTC)
Fait Yes check.svgPhe 21 janvier 2012 à 14:47 (UTC)


  • Si l'on utilise le moteur de recherche, il est impossible d'afficher plus de 500 livres en changeant à la main limit= : exemple. Il est nécessaire de naviguer à l'aide de Voir (500 précédentes | 500 suivantes) (20 | 50 | 100 | 250 | 500).




  • Avancement erroné : la barre d'avancement disparait. Semble se produire après un purge. Exemples :
fr:
en:
wmflabs
Problème survient en présence d'une apostrophe dans le titre, puis d'une purge.

Collection[modifier]

Epub[modifier]

Voir Wikisource:Wsexport

Sidebar[modifier]

Citer un livre[modifier]

  • Pyb a reporté sur IRC qu'avec FF 9.0.1 et monobook le lien "citer le livre" n'ouvre pas la popup, à vérifier sur Traité d’économie politique/1841, sinon il y a un léger souci avec le positionnement de la fenêtre, elle s'ouvre au milieu de la page, normal mais juste après FF repositionne le scrolling en haut, dans certain cas la fenêtre ouverte n'est même plus visible, c'est apparemment du au # dans l'url du lien, j'avais essayé de le supprimer mais ça fonctionne pas sans ce # — Phe 12 janvier 2012 à 00:01 (UTC)

ChoixNotes[modifier]

  • ChoixNotes ne devrait pas être un gadget mais un lien dans le menu options d'affichage avec persistance du choix via un cookie

Modernisation[modifier]

  • Un problème reporté en 2010 Wikisource:Questions_techniques#Le mini-dictionnaire pour la modernisation de texte inopérant dans les sous-domaines d’un texte ?, à vérifier si toujours d'actualité. Dans les sous-pages d'un texte le dictionnaire de modernisation inclus dans la page principale n'est pas pris en compte. (c'est sur old que ça se passe [5], je m'en occupe. — Phe 18 septembre 2011 à 13:08 (UTC))
    Le pb n'avait pas de rapport avec le fait que ce soit une sous-page, mais il reste beaucoup de travail sur la modernisation. — Phe 19 septembre 2011 à 18:17 (UTC)
  • Il faut un script externe et le wikicode de tous wikisource pour faire ça : voir si on peut optimiser le fonctionnement du dictionnaire de modernisation global et des dictionnaires locaux en pages principale et en sous-pages en déplaçant des entrées locales souvent utilisés vers le niveau supérieur du dico et vice-versa.
  • Idem ci-dessus, peut-on détecter les mots modernisés dans un dictionnaire local et utilisé dans des pages transcluse dans main: et qui n'utilise pas ce dictionnaire locale (i.e. les mots candidats à l'inclusion dans le dictionnaire global ou bien dans le dico local de cette page).
  • Le dictionnaire doit respecter la casse.
  • Idéalement, quand on ajoute un mot au dictionnaire principal, il devrait y avoir un parsing des textes à moderniser pour voir les phrases impactées et vérifier de visu s'il y a des possibilités d'homonymie. Il devrait y avoir un dictionnaire des mots rejetés du dictionnaire principal, avec un warning si l'on veut l'ajouter au dictionnaire principal (avant d'ajouter ce mot, veuillez le supprimer des entrées des mots pouvant avoir plusieurs variantes...).
  • Le dictionnaire commence à être gros et lourd ... possibilité de le scinder, d'ajouter une série de mot qui ira se classer automatiquement dans l'ordre alphabétique
  • intégrer la modernisation avec la possibilité de sortir le texte en epub modernisé Sapcal22 (d) 4 septembre 2012 à 21:42 (UTC)

Barre d'outils[modifier]

  • Le bouton « Match et Split » n’apparaît plus sous monobook. Marc (d) 7 janvier 2012 à 12:56 (UTC)
    Avec Chromium 17.0.963.26, FF et chrome fonctionne par contre.

Gadgets[modifier]

  • MediaWiki:Gadget-Erreurs-communes.js, permettre des corrections automatiques ?
  • MediaWiki:Gadget-Erreurs-communes.js est trop lent, voir par exemple L’Encyclopédie/Volume 1. Voir Optimisation pour ce qui a déjà été tenté.
  • Gadget erreurs communes, une solution intérimaire si les corrections automatiques assistés sont longues à venir : quand on clique sur une erreur et qu'on est mode édition, se positionné sur le texte de l'erreur dans la boîte d'édition
  • Faire le tri dans les gadgets typo.
  • Remplacer le gadget typo qui se déclenche en preview sur une page q1, par un gadget qui se déclenche sur la création d'une page (if ($('# msgNewarticletext').length) sera sans doute suffisant comme test), en contrepartie la typo pourra être faire de façon plus agressive.
    Un seul gadget irait bien avec un set de regexp pour chaque cas 1) au chargement du texte lors de la création d'une page 2) au chargement du texte d'une page existante (cas du br --> nowiki par exemple) 3) sur l'appui du bouton typo. Pour l'extension faite dans les js utilisateurs (les str.replace()) on peut maintenir la compatibilité sans trop de problème. On peut aussi se débrouiller pour cacher le gadget dans les préférences et on le met ON pour tout le monde. Le gadget doit aussi exposer publiquement une fonction acceptant un tableau de couple de regexp et l'appliquant à wpTextbox1 utilisable pour des besoins spécifiques, par exemple le script Trévoux utilisé par Acer11.
    La fonctionnalité de customisation des gadget qui sera bientôt au point va permettre de faire cela facilement. Tpt (d) 14 octobre 2011 à 17:01 (UTC)
  • Intégrer au gadget d'édition du modèle auteur, son remplissage automatique, mais prévoir que le remplissage automatique puisse être utilisé séparément, voir Utilisateur:Phe/Auteur v2.js
    Intégration en cours. Tpt (d) 14 octobre 2011 à 17:01 (UTC)
  • Intégrer Utilisateur:Phe/Entete page.js, comme gadget, actuellement mal nommé ce code reporte lors de la création d'une Page: le modèle {{nr}} dans la page courante et un éventuel modèle {{tiret}} en le transformant en {{tiret2}}
  • Intégrer Utilisateur:Phe/Michaud.js, même chose que précédemment, plus le report de la dernière ## section ## depuis la page précédente, doit être généralisé pour marcher sur tous les Pages de dictionnaire.
  • Intégrer Utilisateur:Phe/Oeuvre par.js, s'utilise sur une page auteur pour ajouter dans l'edit box toutes les pages liés depuis main: à cet auteur et qui ne sont pas déjà présente sur la page auteur, à charge à l'éditeur de faire le tri et de placer correctement les liens. (exemple, ajout des articles de journaux écrits par un journaliste sur sa page Auteur:)
  • Refaire l'ergonomie de MediaWiki:Gadget-IntersectionCategorie.js (Wikisource:Recherche dans les catégories), il faut pouvoir définir des sous-groupes dans les groupes et avoir une boite de sélection par sous-groupe. La deuxième boite actuel devrait être caché par défaut, et visible par un bouton « recherche avancé »

À trier[modifier]

  • Pas vraiment un bug mais on nous sommes bien placé pour le faire, rendre non clickable les icônes quand on en voit, de cette manière [6]. Voir si on peut écrire un script pour rechercher dans les modèles ce type de liens pour les modifier.
  • Doit-on permettre de désactiver la suppression des sauts de lignes en début de pages, configurable par wiki et qui actuellement sont protégés par des nowiki, est-ce faisable ?
  • book2scroll ne fonctionne pas pour tous les livres : Livre:Montaiglon - Recueil général et complet des fabliaux des 13e et 14e siècles, tome I.djvu donne [7]. C'est sans doute un problème du côté serveur à rapporter à Magnus, mais vérifier avant si ce n'est pas un bête problème d'encodage du nom de page que l'on passe au server.
  • MediaWiki:MediaWiki.panel.js je crois que ce code devrait imiter le fonctionnement de mw quand l'utilisateur à dans ses préférences « Activer le menu de navigation à gauche repliable avec l'habillage vector » (par défaut on), l'état du menu devrait être persistant et stocké dans un cookie, possible que le code de mw soit utilisable. — Phe 17 septembre 2011 à 13:28 (UTC)
    Je vais y travailler. Tpt (d) 14 octobre 2011 à 17:01 (UTC)
  • Revoir la code de Modèle:Note latérale droite et gauche, il existait avant une possibilité d'aligner en center le texte, qui ne fonctionne plus, j'ai essayé de le réintroduire [8], mais dans cette page, ça ne fonctionne pas, le code généré était bien pourtant <span class="sidenote-right"><span style="text-indent:0em;text-align:center;"><small><br />Voyage autour du Mont-blanc ─ Région au nord du Mont-Blanc</small></span></span>. À côté de ça il reste des appels utilisant l'ancienne syntaxe par exemple. Il faut aussi simplifier le code, un seul span avec un font-size devrait suffire (ou le font-size dans le css de sidenote-right ?
  • [9], ajouter un onglet purge dans les Page:. En ajouter un aussi dans les Livre: si possible ?, admin only ? — Phe 23 septembre 2011 à 13:33 (UTC)
    Le gadget "Ajouter un onglet permettant de purger le cache d'une page" est là pour cela. Faudrait-il le mettre en par défaut pour ces pages ? Tpt (d) 23 septembre 2011 à 15:56 (UTC)
    Le problème est qu'il ne purge que la page, pas l'image sur la page (celle là je crois que ce n'est pas la peine) et encore moins celle que l'on obtient en mode édition. Par contre c'est une bonne idée, on peut se servir de ce gadget et l'augmenter pour qu'il purge aussi les thumbs dans l'espace Page. Regarde dans le diff que j'ai donné ci-dessus l'url qu'il faut purger pour réellement récupérer la bon thumb. — Phe 23 septembre 2011 à 22:38 (UTC)
  • 1) [10] montre qu'il manque quelque chose dans le robot.txt pour éviter que les moteurs de recherche indexe les url en title=...&match=xx. 2) voir pourquoi l'extension DoubleWiki ajoute des liens &match= sur toutes les pages, est-ce vraiment utile dans tous les espaces de noms ? Pareil pour ?useFormat=mobile mais global ?
  • Quand mediawiki extrait le texte d’un fichier djvu, les retours à la ligne sont conservés dans la boîte d’édition, et il n’y a pas de différence entre les retours à la ligne qui marquent la fin d’une ligne sans nouveau paragraphe et ceux qui marquent le début d’un paragraphe. Serait-il possible de supprimer les premiers et d’ajouter un saut de ligne pour les seconds ? Marc (d) 25 septembre 2011 à 19:37 (UTC)
    J'ai du mal à comprendre, est-ce que tu pourrais créer une page ou il y a ce problème, la sauver, l'éditer pour supprimer/ajouter les sauts de ligne et sauver à nouveau pour pouvoir regarder le diff ? — Phe 25 septembre 2011 à 21:06 (UTC)
    Ici tu peux voir le texte extrait par mediawiki, et ici le même texte extrait du site Google Livres (seul le formatage du chapitre est de moi). Marc (d) 25 septembre 2011 à 21:16 (UTC)
    Et je ne sais pas si c’est dans le fichier djvu lui-même que les différents sauts de ligne ne sont pas distingués. Marc (d) 25 septembre 2011 à 21:19 (UTC)
    <conflit d'édition>Oui, tu as compris le problème, comme je le dis après, dans les djvus rien ne distingue un saut de ligne normal d'un saut de ligne de paragraphe, excepté que ... (voir la suite)</conflit>Pour la suppression des sauts de lignes peu utile, je ne suis pas d'accord, cette page serait beaucoup plus difficile à corriger sans les sauts de lignes, qu'on les supprime après la correction pourquoi pas, mais je ne le fais jamais, ça ne rend que plus difficile les corrections éventuelles. Pour l'insertion d'un saut de ligne en début de paragraphe, c'est un peu délicat, je le fais pour la plupart des couches textes que je crée mais ça ne fonctionne pas toujours, ces sauts de lignes n'ont rien de particulier excepté que la ligne est souvent plus courte, si la dernière ligne d'un paragraphe est de la même longueur que les autres lignes rien ne distingue ce saut de ligne d'un autre saut de ligne. Pour une implémentation de ça, voir plus haut «  Remplacer le gadget typo qui se déclenche », le but ce serait d'avoir un gadget typo, qui soit actif par défaut pour tout les utilisateurs et qui se déclenche automatiquement mais uniquement lors de la création d'une page, ce gadget typo pourrait faire ce que tu demandes pour les sauts de lignes de paragraphes et beaucoup d'autre choses au niveau typographie car lors de la création d'une page on sait qu'on ne risque pas de casser du wikicode. — Phe 25 septembre 2011 à 21:40 (UTC)
    On pourrait les détecter simplement. Une fin de paragraphe c'est : une ponctuation, un retour à la ligne et une majuscule. ça devrait faire quelques faux positifs pour les lignes au milieu d'un paragraphe qui se terminent par un point. Pour supprimer les sauts de ligne à l’intérieur d'un paragraphe, c'est tout simple et je l’avais déjà proposé str = str.replace(/ *\n/g, " "); Aristoi (d) 26 septembre 2011 à 06:03 (UTC)
    Il faudra essayer, mais ça risque d'insérer beaucoup de saut de ligne supplémentaires dans les tableaux, les sommaires et surtout dans les poèmes. Pour la suppression des sauts de lignes, ça ne doit pas être fait si tôt et l'idéal serait de ne jamais le faire, il vaut mieux conserver un texte le plus proche possible du scan. — Phe 26 septembre 2011 à 10:12 (UTC)
  • Pour les encyclopédies et dictionnaires, il est possible d’utiliser un truc appelé « dynamic_links », ce qui donne : L’Encyclopédie/Volume 1. J’aimerais l’adapter à l’édition des manuscrits parce que les éditions critiques d’un seul et même manuscrit, si elles sont à éditer pour elles-mêmes, sont aussi des éditions de ce manuscrit. D’où l’intérêt de placer différentes transcriptions en regard, ce qui ne semble pas possible dans l’espace page, mais pourrait être fait dans des pages du type La Chanson de Roland/Manuscrit d’Oxford/Page 10, en utilisant la fonctionnalité pour choisir une transcription, et même pour lire une traduction. L’avantage, c’est que, dans le cas de la Chanson de Roland, il serait possible d’éditer normalement un assez grand nombre de transcriptions et de traductions, puis de tout centraliser. Le problème est que cette fonctionnalité ne semble pas permettre d’utiliser plusieurs index à la fois avec le paramètre titre. Est-ce que ce serait possible ? Marc (d) 3 octobre 2011 à 19:34 (UTC)
  • Est-il possible de se débrouiller pour que notre css dans main matche autant que possible le css définit par le layout 1 (layout par défaut) ? — Phe 14 octobre 2011 à 12:52 (UTC)

Fait[modifier]

Item à garder quelques jours et à déplacer vers les archives si aucun problème n’apparaît.

Développement interne[modifier]

Besoin n°1. Génération automatique de Livre :[modifier]

Les meta-données sont actuellement saisies sur Wikimedia Commons et Wikisource. Il faudrait envisager la récupération automatique des données présentes dans le modèle Book de Wikimedia Commons.

Fait Yes check.svg voir le gadget MediaWiki:Gadget-Fill Index.js. Cette version d'un livre a été créé en éditant un lien rouge et en sauvegardant sans aucune modification. Reste la documentation à écrire.

Besoin n°2 : Citation de livres[modifier]

Le lien « Citer cet article » génère un référence bibliographique permettant de citer wikisource, il nous faut quelque chose d’équivalent à cliquer sur la liste « mode d’affichage » pour permettre de citer facilement un livre ou un passage d’un livre.

Besoin n°3 : Rationaliser la barre d’outils[modifier]

Voir si on peut rationaliser la barre d'outil sous vector, vérifier si tout va bien sous monobook, à coordonner avec Tpt qui a déjà écrit un gadget sur ce thème.

Besoin n°4 : Tableaux[modifier]

a) Vérifier ce que l'on propose pour la création de tableaux et voir ce que propose le wikieditor b) Voir si on peut y intégrer la construction de ce type de table Utilisateur:Phe/Tables. a) et b) sont indépendants. En particulier il faut un éditeur qui gère les rowspans et colspans, qui permette d'appliquer une classe à la table ou à des lignes de la table et qui donne un feedback visuel immédiat.

Besoin n°5 : Librairie javascript pour wikisource[modifier]

Quelques fonctions générales de manipulation de l’interface :

  1. une fonction pour ajouter un bloc de liens dans la colonne de gauche
  2. une fonction pour ajouter un lien à un bloc de liens
  3. une fonction pour ajouter un bouton à la barre d’outils

Toutes ces fonctions doivent fonctionner sur les deux interfaces Monobook et Vector (voire sur toutes ?). Ces fonctions doivent ensuite être utilisées dans les différents gadgets pour assurer une compatibilité de gadgets sur toutes les interfaces. Pour 2. voir addPortletLink() qui doit être compatible vector/monobook. 3. devrait déjà exister sans doute, mais vérifier comment ça fonctionne.

Pour 3 mauvaise idée, les deux barres sont trop différentes. Il vaut mieux utiliser les fonction propres à chacune (expérience personnelle). Pour 1-2 j’y travaille. Tpt (d) 10 septembre 2011 à 17:15 (UTC)
2 existe déjà et 3 il faut le faire de toute façon. 1) doit exister dans mediawiki, mais ça sera peut-être difficile à utiliser. — Phe 11 septembre 2011 à 00:07 (UTC)
1-2 fait (MediaWiki:MediaWiki.panel.js), 3 cela me semble inutile. Tpt (d) 16 septembre 2011 à 20:58 (UTC)
Pourquoi ? j'ai peut être raté quelque chose, mais si on ne fait pas ça, chaque outil ajoutant un bouton dans la barre d'outil sera dépendant du skin utilisé ? — Phe 18 septembre 2011 à 09:04 (UTC)
Il vaux mieux appler la fonction intégrés pour chaque barre car les paramètres sont trops différents (images et placement différents pour les deux, nombre de fonctionnalités intégrés plus important pour Wikieditor…). Un exemple de code :
        if(typeof $j.fn.wikiEditor != 'undefined') {
          $j('#wpTextbox1').wikiEditor('addToToolbar', {
            section: 'main',
            groups: {
              'nav':{
                tools: {
                  'auteur': {
                    label: "Formulaire d'édition du modèle auteur",
                    type: 'button',
                    icon: 'http://upload.wikimedia.org/wikipedia/commons/c/c1/Crystal_personal.png'
                  }
                }
              }
            }
          });
          $j('img[rel="auteur"]').mouseup(function() {
            if($j("#auteur-form").size() == 1) {
              auteurForm.submit();
            } else {
              auteurForm.create();
            }
          });
        } else {
          $j("#toolbar").append('<img id="auteur-button" width="23" height="22" border="0" src="http://upload.wikimedia.org/wikipedia/commons/8/83/Button_biocitas.png" alt="Formulaire d\'édition du modèle auteur" title="Formulaire d\'édition du modèle auteur" style="cursor: pointer;">');
          $j('#auteur-button').mouseup(function() {
            if($j("#auteur-form").html()) {
              auteurForm.submit();
            } else {
              auteurForm.create();
            }
          });
        }
Pour faire un équivalant il faudrait une usine à gaz d’une dizaine de paramètres et le travail pour placer cette fonction dans les cript est àmha équivalant à celui de faire un code beaucoup plus souple du type :
if(typeof $j.fn.wikiEditor != 'undefined') { /* CODE POUR WIKIEDITOR UTILISANT SES FONCTIONNALITÉS INTÉGRÉS */ } else { /* CODE POUR L’ANCIENNE BARRE */ }
d’autant plus que la partie métier du gadget doit souvent varier en fonction de l’éditeur et ce sera encore plus vrai avec le WYSIWYG qui sera couplé avec Wikieditor et qui se profile à l’horizon. Tpt (d) 18 septembre 2011 à 12:54 (UTC)
Oui, je vois, mais dans ce cas là, tout les gadget ayant besoin d'un bouton et indépendant du skin devront inclure ces portions de code ou bien ces gadgets ne fonctionneront qu'avec un skin et je vois arriver les problèmes que l'on aura avec des gadgets qui ne fonctionneront qu'avec un skin. Il a déjà été conseillé à Pikinez par exemple de changer de skin uniquement à cause d'un gadget défaillant sous un skin. Pour le wikieditor, je ne sais pas trop, je n'ai pas encore regardé, mais pour les placements on peut choisir utiliser les ids d'un skin et utiliser un tableau associatif pour les traduire pour les autres skins et avoir ainsi une interface unifiée. Il faudrait regarder ce que fait mediawiki, il y a vraiment des fonctions séparés pour chaque skin pour ajouter des boutons ? Sinon, si ça devient vraiment trop compliqué, on peut aussi choisir de ne supporter que vector/monobook, ça fait trois variantes avec (vector avec ou sans la barre améliorer) — Phe 18 septembre 2011 à 16:02 (UTC)
Les deux barres d’outils sont indépendantes du skin : wikiéditor fonctionne très bien sous monobook et l’ancienne barre de même sous vector et la structure du module d’édition ne change pas selon le skin mais la barre d’outil utilisé. Les fonctions sont en fonction de ces deux barre d’outils. Il y a donc deux point de personnalisation indépendant : le skin (vector vs monobook vs les autres) et la barre d’outil (wikiéditor vs old). Tpt (d) 18 septembre 2011 à 17:46 (UTC)

Formulaire pour {{Document}}[modifier]

Comme pour {{Auteur}}, il faudrait un formulaire pour simplifier le plus possible l’édition de l’espace Auteur avec {{Document}}. J’ai vu qu’il était assez facile de commencer à adapter le premier formulaire pour traiter au moins une ligne du modèle Document, mais ensuite ça me dépasse. J’indique donc ici ce besoin. Marc (d) 25 octobre 2012 à 13:18 (UTC)

Notes et références[modifier]

  1. Cf. lignes 17 et 1710 de WikiCountsInput.pm