LinguaLibre talk:Explore the sound library

Titre

Bonjour @Nicolas NALLET & Seb35 Merci pour votre travail sur cette page d'exploration. Veuillez noter qu'"Explorer la sonothèque" est le titre en français de cette page, et qu'elle devrait donc être renommée avec un titre en anglais pour l'internationalisation (ex. "Browse the Sound Library"), avec une possibilité de traduction du titre dans d'autres langues, via l'extension Translate peut-être.

De plus, par quel moyen prévoyez-vous de traduire l'interface de cet outil d'exploration ? (TranslateWiki, extension Translate, LangSwitch...)

Merci pour votre travail, cordialement. — WikiLucas (🖋️) 09:51, 15 September 2021 (UTC)

Il y a actuellement du JS (avec 3 langues) pour gérer les messages dynamiques (par ex. « Pas de résultats »), mais Translate est la solution la plus adaptée en complément pour les quelques messages statiques (par ex. « Results ») voire les instructions éventuelles, d’autant que c’est utilisé sur d’autres pages comme Special:MyLanguage/Help:Main. Si le titre anglais actuel convient, on peut activer Translate. ~ Seb35 [^_^] 10:03, 22 September 2021 (UTC)

@Seb35 Merci d'avoir ouvert à la traduction, de mon côté j'ai mis à jour le menu "latéral" (supérieur) avec la sonothèque à la place des jeux de données. — WikiLucas (🖋️) 12:23, 22 September 2021 (UTC)

Questions

Bonjour @Nicolas NALLET, Seb35, & Mathis Back , j'ai quelques questions concernant ce projet de page d'exploration :

1. Serait-il possible d'afficher les résultats sur plusieurs colonnes plutôt qu'une seule ? L'idéal serait d'adapter le nombre de colonnes à la largeur de l'écran.
2. Comment allez-vous gérer les requêtes donnant plus de 100 résultats (ex. Les enregistrements en français, les enregistrements de Poslovitch...) ? Actuellement il semble y avoir un maximum de 10 pages de 10 résultats chacune, pour chaque requête.
3. Serait-il envisageable d'adopter une solution de type "infinite scrolling", similaire à celle de la recherche sur Commons ? C'est-à-dire qui charge les données à mesure que l'on déroule la page

Cordialement — WikiLucas (🖋️) 10:23, 16 September 2021 (UTC)

1. C'est fait, les modifications sont en Local pour le moment.
2. Le nombre total de résultats sera divisé en 10 pages.
3. Ce serait intéressant mais ce n'est pas prévu. Mathis Back (talk) 10:42, 16 September 2021 (UTC)

Mathis Back said: "Le nombre total de résultats sera divisé en 10 pages."
Donc les +200.000 enregistrements en français seront affichés sur 10 pages de +20.000 enregistrements ? 🤔 — WikiLucas (🖋️) 19:55, 16 September 2021 (UTC)

Hello, non plutôt 20 000 pages de 10 résultats actuellement... Tu pense que 100 résultats par page serait mieux ? Nicolas NALLET(talk) 08:16, 17 September 2021 (UTC)

Je pense que moins l'utilisateur a besoin de cliquer, plus agréable est son expérience, donc 100 résultats ce serait déjà mieux, mais l'idéal serait quelque chose d'adaptable type infinite scrolling (la page suivante s'affiche à la suite en bas lorsque l'utilisateur atteint le bas d'une page). — WikiLucas (🖋️) 13:38, 17 September 2021 (UTC)

Pour le point 2, la limite de 100 permet que ça ne mette pas trop de temps à se charger. Les tailles (100 résultats, 10 résultats par page) peuvent être changés, ce sont des constantes au début du code. La requête SPARQL est faite sans ordre pour accélerer la réponse. En fait la vitesse d’affichage s’est révélée être une contrainte forte car Blazegraph peut mettre beaucoup de temps, surtout s’il y a plusieurs visiteurs qui font des grosses requêtes (ce qui pourrait se développer avec cette interface si on ne met pas de limites).

Si on souhaite afficher plus de résultats, voire tous, il faut imposer un ordre à SPARQL à partir du 2e lot de 100 (si on veut plus de 100 résultats) afin de parcourir l’ensemble des résultats de façon ordonnée (et retirer de l’affichage les 100 premiers déjà affichés, sauf si on accepte des doublons). Mais avant de développer cela, il faudrait préciser le but de cette interface : est-ce simplement pour de la consultation sérendipidique ou de la recherche plus systématique ? Il est peut-être bon de mettre en fonctionnement la version actuelle et de faire le point après quelque temps sur les évolutions. (Et en fait, contractuellement vis-à-vis de WMFR, je pense qu’on a fait ce qui était demandé, et peut-être même plus, en tous cas il s’agit de livrer une version.)

~ Seb35 [^_^] 10:55, 22 September 2021 (UTC)

Paramètres supplémentaires

Durant des discussions, il est apparu que des paramètres d'exploration supplémentaires tels que la période temporelle et le lieu de résidence du locuteur seraient les bienvenus. — WikiLucas (🖋️) 14:59, 18 September 2021 (UTC)

Nouvelle màj

Bonjour @Seb35, Nicolas NALLET, & Mathis Back et merci pour cette mise à jour, c'est plus rapide (Grâce au cache ?) !

J'ai quelques questions/remarques :

• Prévoyez-vous d'améliorer les exports csv des requêtes qui ont beaucoup de résulats ? J'ai exporté la requête pour les enregistrements d'Olaf, environ 300 lignes seulement, seulement 100 pour les enregistrements de Titodutta, et seulement 500 pour mes enregistrements
• Les csv sont générés directement chez le client, ou sont stockés temporairement sur le serveur ?
• Certaines requêtes tournent sans fin, par exemple si l'on demande les enregistrements faits par des locuteurs masculins.

Bien à vous, — WikiLucas (🖋️) 09:32, 30 September 2021 (UTC)

Pour les CSV, il y a un petit bug que je dois corriger car il y a plus de lignes que d’enregistrements. La limite est censée être 100 pour correspondre aux résultats effectifs. Comme pour le nombre de résultats, ça pourra être changé. Plus globalement ça sera à vous de voir à l’usage si l’export CSV est pratique/utile, et si/comment ça doit évoluer. Les CSV sont issus d’une requête SPARQL et le CSV lui-même est généré côté client.

En lien avec les exports : actuellement Blazegraph retourne "des résultats", c’est lui qui décide ce qu’il retourne. Je vais modifier les boutons (demande de WMFR) pour mettre 1 bouton "donner 100 résultats aléatoirement" et 1 bouton "donner les 100 derniers résultats". Les exports CSV pourraient être utiles pour conserver les résultats affichés, surtout s’ils sont aléatoires. D’ici quelques temps/mois, vous pourrez discuter si ces choix sont pratiques/utiles ou si vous voulez les faire évoluer selon les usages que vous trouverez à cet outil (peut-être faire une interface experte pour les contributeurs et une interface simple pour les lecteurs, vous verrez).

Sur les requêtes sans fin, Blazegraph retourne parfois des 429 (Too many requests), je vais faire en sorte d’afficher à l’utilisateur que la requête a avorté (en complément, il faudrait arriver à augmenter la limite du nombre de requête, mais je n’ai pas trouvé, ça a à voir avec Jetty).

~ Seb35 [^_^] 10:44, 30 September 2021 (UTC)

J’ai accusé un peu trop rapidement Blazegaph pour les requêtes sans fin (même si ça peut arriver dans certains cas) : pour seulement les locuteurs masculins ou seulement les locuteurs français, c’est corrigé.

C’était que la requête SPARQL comprenait une liste exhaustive des tels locuteurs (pour accélerer les requêtes avec ce critère pour les cas où il y a peu de locuteurs répondant aux critères) mais dans le cas des locuteurs en français, il y a 446 locuteurs, ce qui faisait une URL bien trop longue. ~ Seb35 [^_^] 12:26, 30 September 2021 (UTC)

@Seb35 j'ai un problème avec le bouton Export this query in csv car je ne peux pas cliquer dessus (ça ne fait rien quand je clique). J'utilise Firefox 78.14. Pamputt (talk) 15:25, 4 October 2021 (UTC)

En fait, j'ai le même comportement (rien ne se passe quand je clique) avec Firefox 91.1. À noter qu'un effaçant, testant avec d'autres utilisateurs, j'ai réussi à générer le fichier CSV mais sans être capable de reproduire. Bref, ça fonctionne « parfois » sans que je sache dire pourquoi. Pamputt (talk) 18:10, 4 October 2021 (UTC)

Je vais essayer de reproduire le problème. En tous cas, quand on n’a pas encore fait de choix, le bouton est présent mais non-cliquable ; le mieux est probablement de le cacher au début ou lorsqu’on clique sur 'Réinitialiser'. ~ Seb35 [^_^] 08:57, 7 October 2021 (UTC)

Le problème est que la requête SPARQL pour obtenir les infos pour le CSV est longue et termine parfois en timeout. Du coup, il faut optimiser cette seconde requête SPARQL (faite après la première pour obtenir l’affichage initial) ou au pire demander les infos lors de la 1ère requête SPARQL (ce qui ralentira l’affichage initial). ~ Seb35 [^_^] 09:46, 7 October 2021 (UTC)

C’est résolu pour l’export CSV : les informations sont demandées lors de l’affichage initial et donc disponibles dès que cet affichage arrive, ça ne semble pas retarder outre mesure (enfin, certaines requêtes très générales peuvent être longues, mais c’est comme précédemment). ~ Seb35 [^_^] 11:15, 8 October 2021 (UTC)