Discussion utilisateur:Tpt

Sauter à la navigation Sauter à la recherche

À 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.

import des données du modèle Book, quand il est alimenté depuis Wikidata...

10
Hsarrazin (discussioncontributions)

Bonsoir Tpt,

j'ai importé ce soir File:Taché - Forestiers et voyageurs, 1884.djvu sur Commons, en le liant à son élément wikidata Forestiers et voyageurs (Q90714136), mais en voulant créer la page d'index, je me suis aperçue que les champs alimentés par wikidata ne sont pas importés dans la page d'index.

Je ne termine donc pas l'import, pour te laisser la possibilité de voir ce qui se passe.

Merci pour ton aide :)

Tpt (discussioncontributions)

Bonjour Hélène, c'est tout simplement car le convertisseur du modèle Book vers les pages d'index ne fonctionne pas avec les données issues de Wikidata. Il faudrait mettre cela en place (ou, mieux, avoir des pages d'index et un modèle d'en-tête qui marchent avec Wikidata).

Hsarrazin (discussioncontributions)

oui, je me doutais d'un truc comme ça...

pour mettre en place des pages d'entête qui marchent (aussi) avec wikidata, ça serait bien, à terme... mais les principales personnes qui importent des fichiers ne touchent même pas àWD avec des pincettes (je pense à Ernest en particulier)

Pour le moment, j'en suis toujours à faire le ménage du gigantesque passif que nous avons en termes de "élément wikidata" pour chaque livre, modèle Book sur Commons, lié à l'élément wikidata... et c'est du boulot qui ne PEUT PAS être automatisé, ou très peu, car la saisie dans wikidata suppose que chaque part de la description (auteur, éditeur, etc. ait un élément)...

Ton super script ws2sw.js est une aide énorme.... mais ça ne marche que pour les bouquins qui sont transclus avec header (et il y a encore des milliers de cas de transclusion avec {{page}}.

ça avance, mais j'aimerais qu'on soit un peu plus nombreux à se partager ce travail (pour lequel je vérifie systématiquement l'existance d'une notice BNF ou Sudoc afin de limiter les erreurs...

Il reste aussi encore des centaines d'auteurs (probablement plus avec les revues, à identifier et créer, et l'outil d'import d'autorités de Dicare n'est plus opérationnel depuis une quinzane :(

Je te souhaite une bonne santé et une bonne continuation... (et si tu as un petit peu de temps pour penser à l'import depuis Book/wikidata, ça serait génial... sinon, tant pis).

Bises

Tpt (discussioncontributions)

Merci beaucoup pour tout ton boulot d'importation dans Wikidata. C'est génial que tu avance dessus. Ce serait super effectivement s'il y avait d'autre personne pour t'aider.

Au niveau de Book Wikidata, que dirais-tu plutôt de faire en sorte que les pages d'index en mode "visualisation" et le header template affiche les données de Wikidata ? Cela serait probablement autant de travail que de faire l'import depuis book/Wikidata et éviterais de dupliquer l'information.

Je compte m'atteler ce week-end à avancer (et j'espère finir) le code pour faire enfin marcher les liens inter-langues avec Wikidata via les éditions/oeuvres.

Bon week-end et bonne santé à toi aussi !

Hsarrazin (discussioncontributions)

le produit de mes cogitations... ça a pris un peu de temps car (1 : je télétravaille ; 2. j'essaie de voir comment optimiser mon boulot au fur et à mesure que je le fais...)

oui, ça serait bien, si on pouvait avoir pour chaque page d'Index un champ Wikidata, où on mettrait le QID... -> mais certaines données ne sont pas sur wd... la source, par exemple...

et ça marcherait bien pour les "nouveaux" bouquins.... mais la reprise pour les anciens reste un boulot de fou...

penses-tu qu'il soit possible de créer un champ Wikidata... sur lequel serait calé le fait que le bouquin EST catalogué dans wikidata (et plus le fait que le "titre" ait un lien wikidata ; car ça donne des faux positifs, et aussi des faux négatifs)...

si le champ est renseigné, toutes les données possibles seraient affichées.

Mais je me pose la question de "afficher" ou "importer"... car on a la question de la gestion des liens (Auteur, espace principal, séries, etc.)

car il n'est pas envisageable d'imposer aux contributeurs qui importent des bouquins de créer l'élément wikidata avant... ni même après.... il y a bien trop peu de wikisourciens qui sont capables de le faire, ou qui souhaitent le faire ^^

et surtout, si on veut en venir à bout, il faudrait une catégorisation efficace des bouquins pour lesquels il FAUT créer/chercher un élément wikidata... car avec les problèmes actuels de Petscan, la recherche par croisement de critères est devenue totalement impossible...

par ailleurs, il y a sur Commons des milliers de fichiers qui utilisent encore un modèle Information et pas le modèle Book, donc ces fichiers devraient être mis à jour aussi...

autrement dit :

  1. créer un champ wikidata pour mettre le QID
    1. le cas échéant, ce QID pourrait être importé du fichier Commons correspondant
    2. ET/OU reporté sur le fichier Commons correspondant (comme ça on ne fait le boulot qu'une seule fois)
  2. créer une catégorie "Page d'index sans QID dans le champ wikidata" pour facilement trouver TOUS les bouquins à traiter (au départ, TOUS, bien sûr).
  3. reprendre tous les bouquins qui font partie de la liste Catégorie:Livres_avec_un_lien_Wikidata (qui correspond au fait que le titre a un lien wikidata, ce qui n'est pas du tout la même chose pour les recueils, les journaux, etc.
  4. compléter ces livres là le plus vite possible avec le QID
  5. compléter avec le QID des bouquins dont le fichier Commons a un QID
  6. reprendre tout le reste...

Je me pose aussi la question s'il serait plus commode de partir des plus anciens fichiers, ou des plus récents.... je pense que traiter chronologiquement est la seule façon de ne rien oublier...

autre questionnement... comment faire fonctionner les liens Auteurs... y compris, le cas échéant, les liens rouges d'Auteurs à créer

j'espère que ces cogitations te seront utiles...

on devrait peut-être faire une sous-page du projet Wikidata pour traiter de cette question ?


Qu'en dis-tu ?

Tpt (discussioncontributions)

Bonjour Hélène. C'est un super plan ! Je vais faire un prototype et je reviens vers toi. J'espère qu'on pourra dans la suite se passer quasi complètement du champ Wikidata quand il sera possible d'accéder aux données structurées de Commons depuis les modules Lua de Wikisource.

Hsarrazin (discussioncontributions)

oui, mais pour le moment, je ne vois pas comment faire sans...

et puis, juste un champ wikidata, c'est moins lourd que tous ces champs doublonnés....

PS : il faut aussi penser au cas des fs qui ne sont PAS sur Commons, pour des questions de copyright - notre modèle Book n'est pas à jour, et n'affiche même pas l'élément wd... (enfin, je lui ai fait une petite bidouille pour l'afficher, mais il ne récupère rien... - voir par ex. Fichier:Alain_-_Système_des_Beaux-Arts.djvu)

j'ai créé à la volée

Tpt (discussioncontributions)

En effet, il y a ces fichiers qui ne sont pas sur commons.

Un autre point a considérer : si on importe automatiquement les données de Wikidata dans l'espace index, il faut faire de même avec le modèle d'entête (header=1). Et là une ambiguïté se pose : si la page où l'entête est affichée est elle même connecté à une entrée Wikidata, faut-il afficher les données de l'entrée vers laquelle pointe la page d'index ou les données de l'entrée liée à la page ?

Hsarrazin (discussioncontributions)

normalement, quand j'importe les données dans wikidata, je commence par faire le ménage de la page d'index et des headers pour qu'ils soient homogènes et propres, avec le maximum de données directement fournies par la page d'Index, mais on a toujours tout un tas de cas particuliers...

pour les pages de l'espace principal, alors là, on a plusieurs cas...

  • ceux où l'élément qui est lié à la page est le même que celui mentionné dans la page d'index (c'est le cas pour les pages principales des ouvrages qui ne sont pas des recueils, et pour les petits ouvrages transclus en une seule page, sans sommaire) - donc les données devraient être les mêmes... normalement - sous réserve que Book récupère correctement les données de wikidata, ce qui n'est pas encore totalement le cas... (par ex, les sous-titres)
  • les sous-pages de type chapitre... qui utilisent les mêmes données de header que le volume, à l'exception de la pagination ;-> celles-là ne devraient pas avoir d'élément wikidata, sauf exception...
  • les pages de périodiques ou de recueils, qui sont "publiées" dans le volume, qui lui est lié à un autre élément ; celles-là, pour toutes sortes de raisons, peuvent poser des problèmes... -> j'aurais tendance à dire que l'élément wikidata directement lié devrait prendre le pas sur les données de l'Index, exactement comme on peut forcer la valeur des paramètres dans le header... - (et peut-être prévoir des catégories pour mettre en évidence les divergences...)

dans tous les cas, si on récupère les données de wikidata dans le header, il faudra pouvoir conserver la possibilité de forcer des données locales...

je ne suis pas sûre qu'il faille utiliser wikidata pour afficher le header, pour le moment... déjà, une fois qu'on aura mis à plat tous les Index, ça sera pas mal... je ne sais pas à combien de milliers on en est, mais on dépasse largement les 14000 (et il y a plus de 20000 djvu en français sur commons).

mais s'il faut définir un ordre de priorité je dirais : les données de la page d'Index par défaut > si les données de l'élément wikidata direct sont différentes, elles prennent le pas > s'il y a des paramètres locaux en dur, ils prennent le pas...

je crois que sur Commons, des dizaines de catégories de maintenance ont été mises en place pour mettre en évidence les divergences... mais compte tenu du nombre de nous sommes, est-ce vraiment gérable sur wikisource ?

autre point, qui n'est actuellement PAS DU TOUT géré par le modèle Book : les paramètres comme Auteur ou Editeur, avec une valeur liée à un autre élément, et un qualifier "indiqué comme" qui correspond à la valeur à afficher (comme dans [[lien X|valeur affichée]]). -> ex : Sur_la_mémoire -> l'auteur est [[Auteur:Alain]] mais la signature qui s'affiche est "E. Chartier".

Il faudra bien sûr les récupérer correctement, sinon c'est vraiment pas la peine de s'enquiquiner à aller les documenter...

mais dans l'immédiat, je dirais qu'il faut s'occuper des Index, et continuer à gérer les header à partir des index comme ils le sont déjà, c'est à dire la valeur par défaut ou la valeur forcée

puis, dans un 2e temps, on verra s'il y a des différences avec ce qui vient de l'élément wikidata lié...

Tpt (discussioncontributions)

Bonjour Hélène,

J'ai fait un premier jet de l'importation des données depuis Wikidata. Les pages d'index ont un nouveau champ pour l'identifiant Wikidata et le "index template" et le "header template" sont tout les deux mis à jour. Si un identifiant Wikidata est donné, les données depuis Wikidata sont utilisés si aucune donnée n'est présente sur Wikidata. L'importation depuis Wikidata est faite depuis Module:Index_data qui est utilisé par Module:index template et Module:header template. Il n'y a pour l'instant aucune catégorie de tracking sauf Catégorie:Livres avec un identifiant Wikidata pour les pages ayant un identifiant Wikidata (et donc où l'importation est active). Voici un exemple de page d'index et [page de l'espace principal associée].

Répondre à « import des données du modèle Book, quand il est alimenté depuis Wikidata... »
Reptilien.19831209BE1 (discussioncontributions)

Bonjour, WSexport ignore Templatestyle. En effet, pour que ça fonctionne, le contenu doit être à l'intérieur d'un conteneur ayant un attribut class="mw-parser-output" (doc). Si ça fonctionne très bien ici, ça ne fonctionne pas lorsqu'on exporte car ledit conteneur n'est pas repris. Il faudrait :

  • soit nettoyer le style intégré au document en supprimant la chaîne .mw-parser-output
  • soit rajouter le conteneur dans le document généré

J'espère que tu trouveras quelques minutes pour t'en occuper, je crois savoir que tu es fort pris en ce moment.

Tpt (discussioncontributions)
Reptilien.19831209BE1 (discussioncontributions)

Coucou, c'est normal que ça prenne aussi longtemps à être déployé ?

Reptilien.19831209BE1 (discussioncontributions)

Je relance également ce sujet, ça ne fonctionne toujours pas à l'exportation. Le style est bien présent dans le document exporté mais ne s'applique à rien car aucun conteneur .mw-parser-output :-\

Répondre à « Templatestyle et WSexport »
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 237) 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 329). 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 237 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 239, 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é.

Reptilien.19831209BE1 (discussioncontributions)

Bonjour, je relance le sujet que j'avais complètement oublié. Oui, si tu as quelques minutes à consacrer à cette opération, je veux bien que tu t'en charges. Merci :-)

Reptilien.19831209BE1 (discussioncontributions)

J'ai pris connaissance de ton post sur phabricator, et j'ai remis en place les modeles tiret(2) en attendant qu'une solution soit trouvée.

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

catégories de maintenance que je n'arrive pas à nettoyer

4
Hsarrazin (discussioncontributions)

Bonjour Tpt,

J'espère que tu vas bien par les temps qui courent, et que le confinement ne te pèse pas trop.

J'essaie de faire un peu de ménage dans les fichiers stockés en local, soit pour les transférer sur Commons, soit pour les annoter en vue de leur transfert ultérieur...

j'ai un problème avec les catégories suivantes, dont je n'arrive pas à me débarrasser, même en apposant le modèle {{Book}} ; il s'agit des catégories suivantes :

Ignorant totalement comment elles sont alimentées, je ne parviens pas à m'en débarrasser, alors même que toutes les infos sont en place.

J'ai l'impression qu'en fait, seul le modèle {{InfoLivre}} est reconnu, et pas du tout le modèle {{Book}}, ni le modèle {{Information}} qui est beaucoup plus adapté pour les images...

Peux-tu y remédier, stp ? et sinon, à qui dois-je m'adresser, stp ?

Merci d'avance, et veille bien sur toi :)

Bises !

Tpt (discussioncontributions)

Bonjour Hsarrazin.

Le confinement se passe bien pour nous. J'espère que l'éloignement et les bruits de travaux dont tu te plaignait sur Twitter te laissent encore un peu de moral.

Ces catégories ne semblent pas ajoutés par un modèle mais par mw:Extension:CommonsMetadata qui suppose plein de chose sur la tête du wikitext qui est supposé ressembler à celui de Commons. Ce crains que cela ne soit difficile à désactiver. Tu peux peut-être demander de l'aide sur Phabricator mais cela me semble difficile à corriger complètement sauf à utiliser seulement des clones des modèles Commons (i.E.e pas de {{DP-EU}}...).

Hsarrazin (discussioncontributions)

ok, pour DP-EU, qui de toutes façons, ne rentrait pas bien dans le modèle {{Information}}, j'ai résolu le problème avec {{PD-US-expired}}... Comment le trouves-tu ?

Hsarrazin (discussioncontributions)

Mais Book est bien un clone de celui de Commons... et pourtant, il m'indique "sans description lisible par une machine" et "sans auteur lisible par une machine" :(

ou bien y a-t-il un pb avec notre {{Book}} ?

Répondre à « catégories de maintenance que je n'arrive pas à nettoyer »

Comment obtenir la langue de l'utilisateur dans un module Lua ?

7
Rical (discussioncontributions)

C'est Rical, ma principale activité est de mettre au point le Module:Centralizer destiné à plusieurs wikis dans plusieurs langues. Pour cela j'ai besoin des langues de contenus, de pages, que je sais obtenir. J'ai aussi besoin de la langue de l'utilisateur et pour çà j'utilise l'expression frame:preprocess("fr") qui fonctionne bien.

Mais je l'utilise depuis longtemps et je me souviens que j'ai créé, comme administrateur, la "page" fr. En la cherchant maintenant je ne trouve rien et surtout je ne sais plus ce qu'il faut y mettre pour qu'elle fonctionne. J'ai aussi essayé la tache phabricator T4085 "Add a Modèle:USERLANGUAGE magic word" mais je n'ai pas réussi à l'utiliser. Voir mes premiers essais dans T4085 Workarounds available:...

Saurais-tu recréer fr et me tranmettre la méthode pour les administrateurs de ces wikis.

Tpt (discussioncontributions)

Bonsoir Rical. Le bon "hack" lua est en effet frame:preprocess('{{int:lang}}') qui utilise mediawiki:lang et ses sous pages. Pour ajouter plus de langues il faut créer mediawiki:lang/MON CODE contenant comme contenu "MON CODE". par exemple mediawiki:lang/es qui contient "es".

Rical (discussioncontributions)

Un grand merci ! çà marche !

Ce message a été caché par Rical (historique)
Ce message a été caché par Rical (historique)
Ce message a été caché par Rical (historique)
Tpt (discussioncontributions)

Hum, je ne vois pas ce que tu veux dire. Parles-tu d'un outil qui crée les pages Mediawiki:lang/XX automatiquement ?

Répondre à « Comment obtenir la langue de l'utilisateur dans un module Lua ? »
Ernest-Mtl (discussioncontributions)

Salut Thomas... J'ai eu ceci en essayant d'exporter un livre:

The command "'ebook-convert' '/tmp/www-data/ws-c0_Histoire_du_Canada_et_des_Canadiens_sous_la_domination_anglaise__Vol_3-17677889292057.epub' '/tmp/www-data/ws-c0_Histoire_du_Canada_et_des_Canadiens_sous_la_domination_anglaise__Vol_3-17677620736224.pdf' '--page-breaks-before' '/' '--paper-size' 'a5' '--margin-bottom' '32' '--margin-top' '40' '--margin-left' '24' '--margin-right' '24' '--pdf-page-numbers' '--preserve-cover-aspect-ratio'" failed.

Exit Code: 1(General error)

Working directory: /var/www/tool/public

Output:

====

No write acces to /var/www/.config/calibre using a temporary dir instead Conversion options changed from defaults: margin_left: 24.0 margin_right: 24.0 paper_size: u'a5' margin_top: 40.0 margin_bottom: 32.0 preserve_cover_aspect_ratio: True pdf_page_numbers: True 1% Converting input to HTML... InputFormatPlugin: EPUB Input running on /tmp/www-data/ws-c0_Histoire_du_Canada_et_des_Canadiens_sous_la_domination_anglaise__Vol_3-17677889292057.epub


Error Output:

====

QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-www-data' Traceback (most recent call last): File "site-packages/calibre/ebooks/conversion/plugins/epub_input.py", line 241, in find_opf File "site-packages/calibre/startup.py", line 192, in local_open IOError: [Errno 2] No such file or directory: u'META-INF/container.xml' Traceback (most recent call last): File "site.py", line 77, in main File "site-packages/calibre/ebooks/conversion/cli.py", line 401, in main File "site-packages/calibre/ebooks/conversion/plumber.py", line 1110, in run File "site-packages/calibre/customize/conversion.py", line 246, in __call__ File "site-packages/calibre/ebooks/conversion/plugins/epub_input.py", line 281, in convert ValueError: /tmp/www-data/ws-c0_Histoire_du_Canada_et_des_Canadiens_sous_la_domination_anglaise__Vol_3-17677889292057.epub is not a valid EPUB file (could not find opf)

Ernest-Mtl (discussioncontributions)

le message est changé maintenant... il semble qu'il n'y ait plus d'espace sur le disque :

IOError: [Errno 28] No space left on device

Tpt (discussioncontributions)

Merci du report et désolé du lag. Il y avait un problème d'espace disque. Cela devrait maintenant fonctionner.

Ernest-Mtl (discussioncontributions)

Ce matin, toujours la même chose : IOError: [Errno 28] No space left on device

Tpt (discussioncontributions)

En effet. Je m'étais trompé de source du problème. J'ai fait en sorte que cela devrait marcher maintenant mais la source du problème reste à résoudre (probablement lié à la nouvelle version de Calibre et/ou un détail dans la config du nouveau serveur mis en place par la Community Tech Team).

Répondre à « problème avec wsexport »
Le ciel est par dessus le toit (discussioncontributions)

prendre connaissance de cette discussion et nous dire d'où viennent ces changements stp. Merci

Répondre à « Peux-tu... »
Candalua (discussioncontributions)

Hi Tpt,

could you please add to ProofreadPage Statistics some domains which are missing? Here's the list: bs, cy, eu, fo, hi, is, li, mk, nap, pms, sah, sk, yi.


Thank you!

Tpt (discussioncontributions)

Hi Candalua! I have added some of these domains to the statistics. The others are not in pywikibot yet, making phetools fail for them.

Candalua (discussioncontributions)
Tpt (discussioncontributions)

Thank you for the suggestion! I have updated pywikibot. Everything seems to be correctly setup for nap and hi but they do not appear yet in the tables. I have purged the python cache. Hopefully they are going to be displayed in the tables.

Candalua (discussioncontributions)

Seems like we are out of luck :( Would you mind giving me temporary access to the tool? I would love to take a look at the code, and four eyes see better than two... :)

Tpt (discussioncontributions)

I just granted you access. Thank you! We are going to run soon into an other problem. Most of phe tools are written in Python2 and I am not sure how much time ToolsForge is going to allow to run python2.

Candalua (discussioncontributions)

I think I found out the reason. The script is trying to connect to the db server called "napwikisource.labsdb" but fails to do so. Now, on https://wikitech.wikimedia.org/wiki/Help:Toolforge/Database#Naming_conventions they say:


"You may find outdated documentation that uses *.labsdb aliases (for example enwiki.labsdb) to refer to the Wiki Replica databases. These service names are deprecated and have not had new wikis added since January 2018. Please update the docs or code that you find these references in to use the ${PROJECT}.{analytics,web}.db.svc.eqiad.wmflabs naming convention."


So it looks like the naming convention for db servers changed some time before 2018, and the old names like "enwikisource.labsdb" still work, but for new wikisources the same alias was never created. So it seems we should update the naming convention in file phe/common/db.py, function create_conn(), from:

db_server = domain + family + '.labsdb'

to:

db_server = domain + family + '.analytics.db.svc.eqiad.wmflabs'

(analytics seems to be the preferred one for background jobs)

Tpt (discussioncontributions)

Thank you for having a look at it. I just applied the fix you suggested and restarted the statistics computation task.

Candalua (discussioncontributions)

Yay, it works now! Since I'm at it, there is a small improvement that I've been dreaming about since years: make the table sortable! I already looked into it, and it's a very unobtrusive change: I just need to import sorttable.js and apply a few customizations to make it work. The appearance of the table will remain as it is, just with an arrow on each column. Do I have your blessing to proceed?

Tpt (discussioncontributions)

Yes, you have! If you want to maintain this tool moving forward, you are more than welcome. If you think it's more suitable, you could also fork phetools to isolate the statistics parts from his bots and other services, and then redirect the stats parts of the tool to your new tool. I don't think he will mine.

Répondre à « Statistics »
Le ciel est par dessus le toit (discussioncontributions)

sur la page il est indiquer ce qui suit , peux-tu réparer ça stp.


No webservice

The URL you have requested, https://tools.wmflabs.org/phetools/statistics.php, is not currently serviced.

If you have reached this page from somewhere else...

This URI is managed by the phetools tool, maintained by Phe , Tpt .

That tool might not have a web interface, or it may currently be disabled.

If you're pretty sure this shouldn't be an error, you may wish to notify the tool's maintainers (above) about the error and how you ended up here.

If you maintain this tool

You have not enabled a web service for your tool, or it has stopped working because of a fatal error. Please check the error logs of your web service.

Le ciel est par dessus le toit (discussioncontributions)

Bon c'est revenu !

Répondre à « Statistique en rade »
Toto256 (discussioncontributions)

Bonjour Tpt, je me demandais pourquoi l'extension ne fonctionne pas avec Le Mystère de la chambre jaune (1932). Est-ce du au fait qu'il y a déjà un lien vers wikisource (pour la page multi-édition) ? Merci pour ces précisions.

Tpt (discussioncontributions)

Bonjour Toto256. L'affichage des liens ne se fait que quand le cache de l'affichage de la page est renouvelé. Celui ci n'avait pas été renouvelé depuis l'activation de l'extension. Je viens de "purger" ce cache et les liens s'affiche maintenant. Le cache se renouvelle automatiquement toutes les quelques semaines par petit bouts. Si tu veux le faire "manuellement" pour vérifier que cela marche bien sur quelques pages tu peux utiliser le gadget "Ajouter un onglet permettant de purger le cache d'une page" qui ajoute un bouton "purger" dans la liste déroulante à côté du bouton "voir l'historique".

Toto256 (discussioncontributions)

Autant pour moi, je le sais pourtant qu'il faut purger ;-) Désolé pour le dérangement.

Hsarrazin (discussioncontributions)

Oui, ça marche pour moi :)

on va pouvoir avancer, et nettoyer tous ces éléments où la page wikisource a été mise sur le même que la page wikipedia http://petscan.wmflabs.org/?psid=1448568 (ou plusieurs éditions linguistiques) \o/

Tpt (discussioncontributions)

Super ! Il reste encore les liens interlangues à faire. Je suis dessus en ce moment.

Hsarrazin (discussioncontributions)

Salut,

visiblement, ça marche !

Mais je constate sur Pères_et_Enfants que la page est catégorisée en Catégorie:Éditions sans œuvre liée, alors que le lien vers WP s'affiche bien, par le biais de l'extension...

Il faudrait sans doute revoir comment cette catégorie est attribuée, et la conditionner à la présence de P629 sur l'élément wikidata (ou l'absence d'élément wikidata).

Qu'en dis-tu ?

Tpt (discussioncontributions)

La catégorie est proprement attribuée s'il n'y a pas de P629 sur l'élement Wikidata. Par contre, il me semble qu'il y ait un problème dans le cache de MediaWiki/Wikibase : la page Wikisource croyait toujours être connectée à l'item oeuvre, d'où le fait qu'il n'y ai pas de P629 et que l'infobox affichée par le script que je t'ai fait était celle de l'oeuvre. J'ai fait une "null edit" et tout est rentré dans l'ordre.

Répondre à « Extension wikisource »