Ouvrir le menu principal

À propos de ce flux de discussion

Page de discussion de Tpt (d · c · b)

La discussion précédente a été archivée dans Discussion utilisateur:Tpt/Archive 1 le 2016-04-25.

Hsarrazin (discussioncontributions)

C'est récent... il fonctionnait encore il y a quelques jours...

{{WD|Q42}}: [[Erreur Lua dans Module:Wikibase à la ligne 30 : attempt to index local 'args' (a nil value).|Douglas Adams (Q42)]]


Je présume qu'il y a eu des modifications de wikibase ? Merci pour ton aide...

Tpt (discussioncontributions)

C'est corrigé. verdy_p avait cassé Module:Wikibase en le réécrivant d'une manière àmha discutable. Je me suis permis de le revert.

Hsarrazin (discussioncontributions)

et il t'a annulé, puis, apparemment corrigé le problème ^^

Hsarrazin (discussioncontributions)

Merci pour ton aide... et bises (on ne s'est pas vus depuis un bout de temps) :)

Répondre à « un petit problème avec Modèle:WD »
Reptilien.19831209BE1 (discussioncontributions)

Bonjour,

Je rencontre une bizarrerie avec le nouveau système que je peine à expliquer: cette page se termine bien par un tiret, et cette transclusion réuni les deux parties du mot correctement, mais pas sur cette page.

C'est pareil avec le mot Brouhisse (et bien d'autres) mais bizarrement pas avec Paile ou le mot tumultueux est correctement réuni sur les deux pages (section P).

Une idée ?

Reptilien.19831209BE1 (discussioncontributions)

PS. si je fais <pages index="R.-H.-J. Cambresier - Dictionnaire walon-françois, 1787.djvu" from=146 to=147 fromsection="Ponde" /> ça fonctionne : « le jour ne fait que poindre », si je fais <pages index="R.-H.-J. Cambresier - Dictionnaire walon-françois, 1787.djvu" from=146 to=147 /> ça ne fonctionne plus: « le jour ne fait que poin- dre ».

Reptilien.19831209BE1 (discussioncontributions)

J'ai isolé le bug ici.

Reptilien.19831209BE1 (discussioncontributions)

Bon, je pense que j'ai mis la main sur quelque chose. Lorsqu'il y a des sections dans le wikicode des pages et que je me limite à une transclusion sans faire appel aux sections, le code (ligne 236) fait une concaténation de {{:Page:xxx/n}}{{:Page:xxx/n+1}}[...], ce qui a pour effet de transformer les sections en une séquence unique du genre UNIQ--section-00000001-QINU après être passé par l'analyseur (ligne 328). Du coup c'est logique qu'il ne détecte pas le tiret en fin de page, vu que c'est ladite séquence.

Si je remplace la chaîne de la ligne 236 par {{#lst:' . $text . '}} ça ne fonctionne pas non plus, mais avec {{#lst:' . $text . '|}} ça fonctionne. Il y a très certainement quelque chose de plus propre à faire.

Tpt (discussioncontributions)

Merci d'avoir creusé cela. Une manière de résoudre le problème serait de faire faire à ProofreadPage l'inclusion des pages et des sections "à la main" sans passer par une étape wikitexte comme {{:Page:xxx/n}}{{:Page:xxx/n+1}. On pourrait alors faire la détection de tirets sans problème. Un commentaire sur phabricator:T104566 serait sans doute bienvenue, voir même un patch si tu as le temps (les contributions sur ProofreadPage sont plus que bienvenues ;-)).

Reptilien.19831209BE1 (discussioncontributions)

Est-ce que tu suggères au final que ProofreadPage puisse gérer nativement la transclusion des pages et des sections sans faire appel à l'extension LabeledSectionTransclusion ? Ça me semble une idée intéressante.

Sinon, dans un premier temps, il me semble qu'on peut appeler la méthode recursiveTagParseFully à la place de recursiveTagParse de la ligne 238, chez moi, ça à l'air de fonctionner, qu'en penses-tu ?

Tpt (discussioncontributions)

Je serait plutôt pour que ProofreadPage puisse gérer la transclusion des pages sans faire appel au préprocesseur MediaWiki pour l'étape transclusion, i.e. en appelant directement LabeledSectionTransclusion (je ne suis pas certain que cela vaille le coup de dupliquer toute l'extension).


Merci beaucoup pour l'idée de recursiveTagParseFully, n'hésite pas à faire une pull request sur gerrit si tu veux (sinon je peux le faire sans problème). Cela semble une bonne approche. Il est possible que cela rende le rendu des pages faisant beaucoup de transclusion un peu plus long mais probablement pas de manière significative. Si tu fais un patch, n'hésite pas aussi à rajouter des parser tests (tests/parser/proofreadpage_pages_pagelist.txt) pour faire en sorte qu'il n'y ai pas de régression future pour cette fonctionnalité.

Répondre à « Prise en charge automatique des césures »

big problem avec les langues d'écriture des auteurs...

4
Hsarrazin (discussioncontributions)

Salut,

j'ignore si tu as vu cette discussion sur le scriptorium, ou d'aucuns, face au problème, proposent de purement et simplement faire disparaître les catégories de langue d'écriture des auteurs ^^ (vu que wikidata dit n'importe quoi...)

Je pensais résoudre le problème en "privilégiant" les langues d'écriture, comme tu me l'avais indiqué il y a longtemps, mais je me suis fait reverter sur tous les auteurs ayant "espéranto", à cause du projet eowp -> d:User_talk:Robin_van_der_Vliet.

du coup, après m'être fait répondre depuis des années, "t'as qu'à faire une proposition de propriété pour ça", la moutarde m'est montée au nez et -> Wikidata:Property_proposal/langue_d'écriture...

mais j'aimerais avoir ton avis sur d'autres possibilités techniques... en particulier, est-ce que l'ajout d'un qualifier permettrait de résoudre le problème ?

Merci pour ton aide sur ce coup... frws est le premier wikisource à avoir passé tous ses auteurs sur wd, avec beaucoup de boulot.... je ne voudrais pas qu'il soit le premier à en claquer la porte à cause de difficultés comme ça ^^

Bises

Tpt (discussioncontributions)

Salut Hélène, utiliser une nouvelle propriété, un "rank" ou un qualifier sont trois solutions possibles et implémentables facilement dans le modèle. Tpt (d) 7 mai 2019 à 14:23 (UTC)

Hsarrazin (discussioncontributions)

je ne suis pas fan de créer une nouvelle propriété à tout prix... si on pouvait se contenter d'un qualifieur ça me paraîtrait plus simple...

si jamais la nouvelle propriété est acceptée, pourrais-tu me faire une requête qui sorte les auteurs avec une seule langue en p1412 (à recopier avec Petscan...), et ceux avec plusieurs langues (à vérifier avant transfert) ? (

Tpt (discussioncontributions)

Oui, en effet. Je peux tout à fait te faire la requête.

Répondre à « big problem avec les langues d'écriture des auteurs... »
MediaWiki message delivery (discussioncontributions)
English Wikisource's monthly newsletter; Wikisource:News, which seeks to inform all about Wikimedia's multilingual Wikisource.
Read this issue of Wikisource:News · Discussion · Subscribe/Unsubscribe · Global message delivery 23:43, 31 March 2019 (UTC)
Noting that thus is one-off delivery to those listed at Wikisource Community User Group participants, and those wishing to receive further editions of the newsletter should subscribe as described in the above instructions.
Répondre à « ''Wikisource:News'' (en): April 2019 edition »
Hsarrazin (discussioncontributions)

Salut, Je me souviens qu'il y avait, il y a quelques temps (sans doute 1 ou 2 ans) un gadget qui permettait de faire "remonter" la couche texte d'une page, pour remplacer celle existante (cas de changement de facsimile, avec un bien meilleur ocr). Mais je n'arrive pas à le trouver.

Il devait s'appeler un truc du genre TextLayer.js...

Sais-tu ce qui lui est arrivé ? et serait-il possible de le remettre en route ?

en effet, nous avons des volumes entiers issus du Partenariat BNF dont les pages ont été rosies, mais dont l'ocr est crade au possible. Certains contributeurs font un gros travail pour améliorer ces ocr, mais la seule façon de récupérer la couche texte est de supprimer les pages (ce que seul un admin (moi) peut faire... ça serait vraiment bien de pouvoir remonter la couche texte (quitte à verrouiller sur les pages "roses" pour éviter le vandalisme ^^

Peux-tu m'aider sur ce coup-là, stp ?

Répondre à « Gadget disparu ? »
Reptilien.19831209BE1 (discussioncontributions)

Bonjour, j'ai deux un petits problèmes avec le gadget scanilles hocr.

  • Même s'il est désactivé dans mes préférences, il est tout de même actif dans l'espace Page. [le problème n'apparaît plus]
  • Lorsqu'il est actif, les étiquettes span posées sur chaque mot brisent certains caractères contenant des diacritiques non compris dans le caractère (le point de code). Voir sur cette page pour un exemple (le caractère œ̆̀ est décomposé en « œ » et « ̆̀ ».

Quand tu auras un peu de temps, aurais-tu la gentillesse d'y jeter un œil ?

Merci.

Hsarrazin (discussioncontributions)

bonjour Reptilien,

c'est bizarre... j'ai le gadget scanilles activé en permanence, et je ne vois rien d'anormal sur cette page :/

c'est en lecture ou en édition ?

Reptilien.19831209BE1 (discussioncontributions)

En lecture, ou prévisualisation, uniquement dans l'espace Page. @Hsarrazin confirmes-tu que si tu désactives le gadget dans tes préférences il est toujours actif dans l'espace page ?

Hsarrazin (discussioncontributions)

je confirme , après dûe vérification... :)

mais je n'ai toujours pas d'anomalie d'affichage. Un conflit d'extensions chez toi, peut-être ?

Reptilien.19831209BE1 (discussioncontributions)

Non, je ne crois pas que ça vienne de moi car j'ai testé en étant déconnecté et avec un navigateur vierge de tout gadget et extensions. J'ai pris le temps de faire une petite image pour illustrer le problème 2. C'est par ici. On voit que le caractère « œ » est dans une ''span'' isolée de ses diacritiques. Laquelle ''span#word_id_102'' est le résultat du gadget ''scanilles''. Ça doit probablement venir de la manière dont le gadget décompose les mots (Regex).

P.S. ah, je suppose que tu utilises Firefox, où le problème est présent mais non visible à l'écran, les diacritiques se positionnent correctement sur le caractère « œ » malgré la présence de la ''span''.

Hsarrazin (discussioncontributions)

je suis sous Firefox, mais aussi sous Safari et IE... et pas de pb.

je vois un peu plus bas que ça n'était pas le "bon" gadget qui coinçait ^^

bon courage,

Reptilien.19831209BE1 (discussioncontributions)

Bon, il semblerait que j'ai commis une erreur, ce n'est pas le gadget ''scanilles'' qui crée les étiquettes ''span#word_id_xxx'' mais ''hocr''.

Reptilien.19831209BE1 (discussioncontributions)

Le problème 1 n'apparaît plus chez moi !

Reptilien.19831209BE1 (discussioncontributions)

Bonjour, quand tu auras 5 minutes, tu pourras rajouter au fichier mul:MediaWiki:Hocr.js à la ligne 327 :

var combining_diacritical_marks = '\u0300-\u036f';

et rajouter cette variable à la valeur de retour :

return char_latin + char_hebrew + char_cyrillic + char_bengali + combining_diacritical_marks

ceci afin que le script ne me coupe le mot « ʧãtā̃s » en ["ʧãtā", "s"] (mon tidle n'est pas considéré comme caractère)

Un tout grand merci d'avance.

Tpt (discussioncontributions)

C'est fait. Désolé pour le lag.

Reptilien.19831209BE1 (discussioncontributions)

Impeccable, tout fonctionne correctement. Merci beaucoup. Pour l'attente, ne t'inquiète pas avec ça, c'est quelque chose que je comprends parfaitement. On est tous bénévoles ici et on fait ce qu'on peut quand on peut ;-)

Reptilien.19831209BE1 (discussioncontributions)

Bonjour, en essayant quelque chose hier, je me suis rendu compte qu'on pouvait mettre du CSS directement dans le champ CSS de l'Index. Le contenu de ce champ se trouve à l'intérieur d'un<style></style>, dans le head de la page HTML. Moi qui pensais jusqu'alors que ce champ était destiné à faire appel à une classe prédéfinie dans Mediawiki:Common.css, et appliquée au conteneur parent aussi bien dans l'espace page qu'en transclusion. Je ne sais pas d'où je tire cette idée. Bref ! Ça m'a donné du baume au cœur, avant de m’apercevoir que ça fonctionne bien dans l'espace page (exemple) mais pas dans la transclusion (j'ai aussi essayé dans l'espace principal). Y a-t-il une raison particulière ? Si ce n'est pas un bug, du coup, je ne vois pas trop à quoi sert ce champ : pourquoi permettre l'utilisation de CSS dans l'espace page si c'est pour ne pas pouvoir le retrouver dans la transclusion...

Et d'un autre côté, même en considérant que le CSS fonctionne dans la transclusion, je ne sais pas si c'est vraiment une bonne idée de l'inscrire directement dans ce champ. N'aurait-il pas été préférable, comme l'indique d'ailleurs l'infobule de ce champ, d'indiquer une page CSS (en modifiant son modèle de contenu) qui elle contiendrait proprement du CSS qui serait utilisable aussi bien dans l'espace page que dans la transclusion, et dans l'exportation.

Je demande cela, parce qu'il y a vraiment des livres qui gagneraient à être mis en forme à partir d'une feuille de style (mise en forme des tableaux, alinéa négatif systématique pour chaque paragraphe d'un dictionnaire, etc). Proposer une feuille de style propre à chaque ouvrage (si nécessaire) ne me semble pas être une idée ridicule. Qu'en penses-tu ?

Tpt (discussioncontributions)

Bonsoir, c'est une très bonne idée. On pourrait utiliser le même système mw:Help:TemplateStyles mais pour les livres. Le champ "CSS" étant alors le nom de la page CSS à transclure. N'hésite pas à ouvrir une tâche Phabricator lié à "Wikisource", "ProofreadPage" et peut être "TemplateStyles" à ce sujet.

Répondre à « Champ CSS de l'espace Index »
Le ciel est par dessus le toit (discussioncontributions)

pour te souhaiter de joyeuses fêtes de fins d'année.

Tpt (discussioncontributions)

Merci beaucoup ! Joyeux Noël et bonne année à toi aussi !

Répondre à « Juste un petit mot »
Lmaltier (discussioncontributions)

C'est bien de faire des outils également pour le Wiktionnaire, merci. Serait-il possible, dans le cas de MediaWiki:Wikisource.citeBox.js pour le Wiktionnaire, de remplacer l'abréviation p. par page (ou pages, quand il y en a plusieurs) en toutes lettres, car le Wiktionnaire a pour politique d'éviter ce genre d'abréviation technique (même si, dans ce cas, la grande majorité des lecteurs comprennent sans problème). Il y a eu une discussion et un vote sur ce cas particulier de l'abréviation p., ce qui a abouti à la conclusion d'utiliser le mot en toutes lettres. Par ailleurs, le modèle nobr est-il nécessaire ? Certes, il peut probablement améliorer le rendu dans certains cas, mais il complique en même temps ce qui est mis dans la page, et les personnes novices de bonne volonté, qui aimeraient contribuer, sont souvent effrayés par la complexité de ce qu'ils voient et abandonnent tout de suite. J'ai eu cette expérience moi-même sur Wikipédia (en ce qui concerne les références) et le comble a été sur Wikivoyages, qui semble conçu pour ne jamais accueillir de nouveaux contributeurs... Le Wiktionnaire n'a pas trop de contributeurs, il vaut mieux attirer des nouveaux plutôt que les effrayer. Tout ce qui complique sans être absolument nécessaire est à éviter. ~~~~

Tpt (discussioncontributions)

C'est fait. Merci pour la suggestion

Lmaltier (discussioncontributions)

Merci.

Répondre à « MediaWiki:Wikisource.citeBox.js »
Hsarrazin (discussioncontributions)

Salut,

dans l'option permettant d'afficher les notices liées sur wikidata, j'ai tenté d'ajouter l'affichage de la pagination (comme ça tinyurl.com/ybd366tn, mais ça n'a pas l'air de fonctionner :(

il manque sans doute quelques caractères blancs, ou autres...

Peux-tu m'aider, stp ?

Tpt (discussioncontributions)

Salut,

La gestion des dépendances à l'air d'avoir un problème pour les pages d'index, ce qui fait qu'elles ne sont pas "purge" quand on modifie le module. Il faut donc le faire "à la main" pour utiliser la nouvelle requête. En le faisant la requête semble marcher. Je vais corriger cela dans ProofreadPage.

Hsarrazin (discussioncontributions)

je n'ai rien compris à ce que tu m'expliques, mais si tu corriges, ça me convient tout à fait :D

donc, ma modif était bonne ?

Tpt (discussioncontributions)

Oui, et si tu purge la page d'index j'ai l'impression que cela marche.

Hsarrazin (discussioncontributions)

oui, ça fonctionne maintenant ! merci !

j'ai cru que c'était ma syntaxe qui était défectueuse (vu que je ne suis pas sûre de moi sur les modifications de module lua)

Répondre à « Module:Index_template »
Retour à la page d’utilisateur de « Tpt ».