Je m’aperçois que les fiches d'identifiants J9U hébergée par la Bibliothèque nationale d'Israël, et qui donc pointent vers olduli.nli.org.il, n'ont pas d'HTTPS. Les consultation de notices doivent être très marginales pour les lecteurs qui ont sûrement d'autres chats à fouetter, mais il serait plus sûr de les marquer comme obsolètes dans les fiches wikidata et d'utiliser des identifiants Ark/BnF à la place, qu'en pensez-vous ? Pour des manuscrits, ça a du sens, mais pour des registres d'identifiants numériques autant utiliser une référence sûre et locale, non ? Darviche (discuter) 16 août 2024 à 19:00 (CEST)[répondre]
L’absence d’HTTPS sur un site n’a jamais été un critère pour écarter une source ou un lien externe.
Cette base n’est pas très utile sur la page de Cairn.info j’en conviens, mais elle l’est sur les pages liées à Israël ou à la diaspora.
Si les notices sont toujours accessibles, il n’y a aucune raison de les marquer comme obsolètes sur Wikidata, il faut plutôt intervenir sur les modules locaux pour que cette base ne s’affiche que sur des sujets en lien avec Israël et la diaspora. — Thibaut (discuter) 16 août 2024 à 21:02 (CEST)[répondre]
Je ne vois pas de problème avec celle-ci en particulier. On a bien des bases polonaises ou tchèques d'une qualité pas bien meilleure et personne ne s'en plaint... Uchroniste4017 août 2024 à 00:40 (CEST)[répondre]
@Thibaut120094 Les liens en question sont générés automatiquement à partir d'une base de numéros d'identifiants vers une source, Wikidata, indiquant des registres de fiches d'identités (des ouvrages, certes, mais aussi des fiches de personnes morales, par exemple).
Vous sont proposés des registres de données diffusant les mêmes informations (à partir d'un ID Ark notamment) :
L'autre non et l'information consultée ainsi qu'une partie de l'identité de qui la consulte peut être connue de quiconque se trouve sur la ligne entre vous et la source (et sur le réseau d'une bibliothèque nationale publique, je peux vous assurer que ça fait beaucoup de monde).
@Darviche ce que je veux dire, c'est qu'on a plein de bases sans https et qui n'utilisent pas Ark (comme NUKAT) et ce n'est pas un problème. Les deux sont des sites de bibliothèques nationales, donc on sait qu'il n'y a aucun danger pour l'utilisateur. Et non, on ne vas pas tout retirer pour laisser uniquement la bnf (qui est, pour votre information, pas plus fiable que les autres). La multiplication des bases de données n'est pas un problème mais une richesse, notamment pour un lecteur qui veut faire des recherches approfondies sur un sujet. Uchroniste4017 août 2024 à 09:08 (CEST)[répondre]
« La multiplication des bases de données n'est pas un problème mais une richesse, notamment pour un lecteur qui veut faire des recherches ». Je ne remets pas en question que la multiplicité des bases de données soit une richesse. Ma question porte sur le choix de la sécurité (ou pas) d'un lien vers une notice d'autorité. Darviche (discuter) 17 août 2024 à 09:44 (CEST)[répondre]
Bon, vous ne semblez pas vouloir comprendre ce qu'on vous dit (pas que moi), donc je vais quitter cette conversation. Mais avant, je me dois de préciser : vous êtes le premier avoir parlé de la bnf, je n'ai que repris votre propos. Vous n'allez pas m'apprendre ce qu'est Ark, mais sachez que ce n'est pas le seul système qui fonctionne : les autres, même s'ils sont moins efficaces ou sûrs, ne sont pas obsolètes. Bref, je suis Contre la suppression de bases sur le seul prétexte qu'elles n'utilisent pas ark ou https, d'autant plus quand ce sont des bases institutionnelles. Bonne continuation. Uchroniste4017 août 2024 à 11:54 (CEST)[répondre]
Vous par contre, vous m'obligez à répéter : est-ce que HTTP se justifie parce que l'information doit circuler en clair et sans identifier la source émettrice ? Il me semble que non.
Donc, désolé mais je vais devoir encore vous reprendre car vous ne m'avez pas bien lu et vous déformez mon propos : personne ne parle de supprimer des bases, il s'agit d'avoir une conversation ouverte pour comprendre quelles sont les sources sûres et fiables en matière d'archives et s'il existe des registres plus adaptés que d'autres.
L'identifiant Ark n'est pas propre à la BnF et ce système est loin d'être parfait. La clé de hachage d'un CAS serait sans doute bien meilleure. Cependant c'est l'un des dépôts possibles et il se justifie très bien par la localité et la fiabilité de l'information. — Darviche (discuter) 17 août 2024 à 14:26 (CEST)[répondre]
La consultation des notices sur le VIAF contourne le problème.
Cette base remonte une notice du Dictionnaire critique des historiens de l'art actifs en France de la Révolution à la Première Guerre mondiale, qui pose un vrai problème de mise en page du fait du nom trop long de cette base. Voir par exemple Eugène Dutuit.
Proposition de suppression des indicateurs de langue pour améliorer les performances
Bonjour,
Après avoir effectué la correction 221095609 dans le module, je doute de la pertinence de ces indicateurs de langue qui ont été restaurés :
alourdit visuellement la liste ; je trouve que sans les indicateurs on s'y retrouve plus facilement dans la liste.
information guère utile : la majorité des sites étrangers sont en fait simplement en anglais. Et les navigateurs web permettent maintenant de traduire n'importe quelle site à la volée.
les données ne sont pas fiables ; par exemple actuellement sur Björk#Liens externes :
Billboard, Discogs et de nombreux autres n'ont pas l'indicateur (en)
Allociné a un indicateur (pt) !
et surtout : on a actuellement un énorme problème de performances avec le modèle {{Liens}}, généralement appelé une fois par page ; voir 221071560 et 221095100, et ces indicateurs en sont grandement responsables.
Je propose donc de retirer ces indicateurs. Modification complémentaire : il faudra veiller à ensuite utiliser une seule liste alphabétique (actuellement, il y a deux listes alphabétiques qui sont juxtaposées : les liens fr, puis les liens étrangers).
L'ordre de grandeur du gain, ça serait plusieurs centaines de ms par page. Plusieurs dixièmes de seconde, si vous préférez. Ce qui est absolument énorme. Exemple : en virant les indicateurs, sur Björk, le modèle passe de 966 ms à 286 ms… soit un gain de 680 ms, plus d'une demi-seconde !
Pour l'instant, je ne sais pas trop quoi penser : dans le principe, il y a du bon et du mauvais, avec les indicateurs de langue (a priori utile, mais ici, c'est vrai que ça alourdit énormément la présentation) ; et on nous a toujours dit qu'il ne fallait pas s'occuper des perfs. Mais ta démonstration sur Björk est quand même convaincante. Daehan[p|d|d]13 décembre 2024 à 09:24 (CET)[répondre]
Le principe de ne pas se préoccuper des performances n'est pas valable dans 100 % des situations (les développeurs MediaWiki eux-mêmes ont déjà reconnu des cas où une intervention sur le wiki était nécessaire, d'ailleurs ça serait intéressant de retrouver ces histoires). Là on parle d'une différence très concrète, le visiteur qui se promène d'article en article va gagner une demi-seconde avant que chaque page s'affiche, c'est absolument gigantesque. Même au niveau de la charge des serveurs MediaWiki, cela conduira à une différence observable. À noter aussi que le principe date d'avant Lua et Wikidata, qui ont été des portes ouvertes (surtout Wikidata) pour introduire des problèmes de performances, tels qu'ici. J'ai moi-même déjà renoncé à regret à des fonctionnalités en raison de leur coût trop élevé, exemple avec ce module.
Juste pour l'évoquer, une alternative aurait été d'ajouter ces informations aux sous-modules de données au lieu de les chercher sur Wikidata, mais : ça serait laborieux à faire (surtout que les données devinées depuis Wikidata sont blindées d'erreurs, donc tout serait à contrôler/corriger manuellement), ensuite la maintenance de ces informations (au cas de changement sur le site web) serait extrêmement laborieuse (clairement, jamais personne n'ira le faire), et enfin la pertinence de ces indicateurs est de toute façon franchement discutable.
J'avais rédigé le message comme une proposition, mais en fait c'est une explication, parce qu'au vu de l'impact de ce code, il n'y a même pas à discuter, le changement est à faire.
Auparavant, sur de nombreux articles, ce modèle était à lui tout seul le plus coûteux de la page. Avec les deux optims cumulées, sur Mikhaïl Kavelachvili le temps de génération du modèle passe de 800 ms à 200 ms. Imaginez que quand vous modifiez et prévisualisez l'article, vous gagnez 600 ms de réactivité ; c'est énorme.
Le bottleneck suivant que j'ai repéré est l'ajout des attributs de langue (voir ici). Il s'agit de la langue du titre de la base, c'est autre chose que la langue du site de destination.
En reprenant mon exemple à 200 ms, en retirant ces attributs on passe à 145 ms. D'un côté c'est un gain moins significatif, d'un autre côté ces attributs sont relativement peu utiles, donc peut-être vaut-il mieux privilégier la réactivité d'affichage des pages.
Mais le véritable problème, c'est que les appels de Langue.langue() soient aussi peu performants, ce qui me semble même anormal, et je n'ai pas encore trouvé d'explication à cela.
J'ai trouvé le problème, et je viens de le corriger : 221190222. Hop, plusieurs dizaines de ms gagnées, gain obtenu à l'identique sur toutes les pages contenant le modèle. od†n ↗blah16 décembre 2024 à 13:42 (CET)[répondre]
Les résultats sont vraiment bons : dashboard Grafana. Pour chacun des deux graphes, cliquer sur "frwiki_Bases_tout" (pas la motivation de publier une capture d'écran sur Commons, désolé).
Observations :
Dans le graphe du bas (temps CPU total, sur toutes les pages), on observe l'effet de l'optimisation du (221071560).
Ensuite, dans le graphe du haut (temps médian d'exécution), on observe l'effet de l'optimisation du (221187170) (avec aussi 221190222 pour enfoncer le clou). Cela a aussi eu un effet dans le graphe du bas, mais pour le voir il faut resserrer l'intervalle afin d'éliminer les valeurs extrêmes précédentes : graphes resserrés.
Remarques :
Le modèle {{Liens}} est encore un modèle coûteux, mais c'est sans commune mesure avec ce que c'était auparavant ; et je ne sais pas si on peut faire beaucoup mieux, car le modèle va quand même chercher plein d'informations sur Wikidata.
On peut profiter de ces graphes pour détecter les autres modules coûteux. Il y a par exemple les modules d'infoboxes (qui sont désormais les modules les plus coûteux) ou bien encore l'infâme Module:Cycling race (une usine à gaz que je refuse de toucher).
Pas que je tienne absolument à garder les trucs, mais c'est moi qui ait codé ça et il y a sûrement du potentiel d'optimisation en tout cas. J'avais rien mesuré à l'époque, c'était juste parce qu'il y a du potentiel pour réduire la maintenance du truc en allant chercher les données sur WD.
Le truc (mais faudrait creuser pour ce qui se passe vraiment) c'est que ça doit charger pour chaque base les déclaration "langue de l'œuvre" sur les entités des propriétés, je suppute que c'est ça qui coûte cher.
Il y a probablement du potentiel d'optimisation, j'ai zieuté vite fait hier mais je crois que les modules comme Module:Base/art donnent l'indicateur de langue en paramètre : {"Art Institute of Chicago", "en"} une solution simple si c'est pas déjà fait serait de ne pas charger les langues Wikidata quand c'est le cas, je pense que dans un souci de faciliter la maintenance toujours, j'avais quand même chargé dans l'idée que si le français apparaissait sur WD il n'y aurait pas besoin. Mais pour optimiser, indiquer la langue dans les modules lua directement pour un maximum de bases et s'en contenter devrait fonctionner, en gardant le chargement dans Wikidata uniquement pour les cas ou ce n'est pas indiqué.
Mais de toute façon il y a une autre problématique qu'on a pas réglé je pense sur la maintenance, c'est la migration des urls de la base. On a une page Projet:Bases/Suivi qui se met à jour quand l'url d'une des bases de données change, pour éventuellement mettre à jour les modules. J'ai pas toutes les sous-page en suivi mais je ne suis pas certain que tout soit à jour (et je ne coderai pas de robot pour la mise à jour des modules, et je ne m'occupe pas de la mise à jour des sous-pages). Donc on a un choix, soit on va "full Wikidata" et on va aussi chercher les urls des bases, avec la latence éventuelle que ça implique vu qu'on peut pas faire ça en une seule opération, soit on continue à maintenir à la main, soit on code un truc pour automatiser la maintenance (qui pourra au passage pré-charger la ou les langues). Sans robot autre que ListeriaBot c'est possible aussi en fait, vu qu'on peut générer par exemple du json avec SPARQL et charger du json. C'est une approche que j'ai utilisé pour le tableau des isotopes mais pas du tout à la même échelle ni la même complexité (pour certaines bases, genre imdb, il y a une certaine complexité.) Une alternative serait d'utiliser systématiquement https://wikidata-externalid-url.toolforge.org/ pour gérer ça, ça simplifierai largement la maintenance, mais c'est un outil hébergé sur toolforge. Je ne crois pas que ça gère les langues. Trève de digression.
Après, question performances, il y a de grosses chances que soit il y a un gros problème de perfs dans la fonction que j'ai codé, soit ce n'est pas vraiment du temps de calcul mais plutôt la latence d'aller chercher dans Wikidata qui soit en cause, multiplié par le nombre de bases. On peut pas batcher, on est obligé de charger les déclarations une par une. Donc pas du calcul intensif. Ça dépend de si c'est un problème à l'usage, est-ce que c'est pénible quand on sauvegarde une page après édition ?
Ce mécanisme avait été introduit par Eru (refs 159687814), utilisateur qui ne semble malheureusement plus actif maintenant.
Tu as fait la même erreur que j'avais aussi faite en commençant à lire le code, ce qui confirme que ce n'est pas évident : les codes de langues qui se trouvent dans les sous-modules de données (ton exemple {"Art Institute of Chicago", "en"}) sont pour la langue du nom de la base. Pour avoir dans le lien e.g. <span class="lang-en" lang="en"><i>Art Institute of Chicago</i></span>. C'est tout autre chose que la langue du site web de destination.