Query builder

D'accord, j'ai changé la traduction.

Par ailleurs, que penses-tu de Wikimedia:Query-builder-label-opt-out/fr, j'avais laissé timeout faute d'une bonne traduction et parce que je sais que les utilisateurs utilisent souvent le terme en anglais. Verdy p a remplacé en « dépassement de délai » qui ne me semble pas du tout adapté (le timeout justement est la durée que l'on ne peux pas dépasser), quitte à inventer une traduction inconnu des utilisateurs, autant en mettre une claire et compréhensible.

Merci.

Pour "timeout", je suis assez pour "dépassement de délai", ou "délai dépassé" quand c’est l’événement qui s’est produit. La valeur du "timeout" est en effet une durée à ne pas dépasser, mais en général, le terme est utilisé plutôt pour l’événement de dépassement effectif de cette limite (et c’est le cas dans ce message, me semble-t-il).

Après, l’usage des termes techniques anglais, c’est toujours un vaste débat pour les termes touchant à l’info, tellement c’est entré dans les usages… mais uniquement pour ceux qui sont familiers avec. L’équilibre est parfois difficile à trouver! :)

Idée de compromis : « pour éviter d'atteindre la limite (timeout) ». Qu'en penses-tu ?

Je notifie aussi @Thibaut120094:.

@Verdy p: a finalement mis « erreur d’exécution hors délai ». C'est un peu plus parlant que « dépassement de délai » mais cela me semble toujours trop compliqué vu le contexte et la cible du message.

Ça ne me semble pas correct. Ce qui est compris par "timeout", c’est une erreur qui est levée quand le délai défini est dépassé. Mais ça ne veut pas dire qu’il y a eu exécution quelconque; en fait, on n’en sait rien. Du coup, la traduction de Verdy me semble sous-entendre que l’exécution a eu lieu, ce qui n’est pas forcément vrai.

@Gomoko: que proposes-tu du coup ? Personnellement, vu que l'outil est à destination de personnes débutantes, je pense que "limite" conviendrait le mieux.

Sinon, le nom de l'outil a été changé de "Simple Query Builder" en "Wikidata Query Builder", voir Wikimedia:Query-builder-heading/en). Du coup, "Assistant" a moins de sens... "Créateur de requête Wikidata" irait-il ?

Je reste plutôt sur "dépassement de délai" ou "délai dépassé", car dans le contexte, il s’agit de la cause de l’erreur que l’on veut éviter. "limite", je ne vois pas trop comment l’intégrer? "limite de temps dépassée", peut-être? En tout cas, il me semble que la notion de "dépassement" de quelque chose est la chose importante à conserver.

Pour l’outil, oui, ça me paraît bien, le terme "simple" qui posait question ayant été retiré :)

Note: "hors délai" résume bien les choses et inclut déjà la notion de "dépassement" (et aussi de l'existence d'une limite) juste avec la préposition "hors" (comme dans "hors des clous", "hors des sentiers battus", "hors concours"... et "hors limite" si on ne qualifie pas en quoi consiste cette limite; mais avec "hors délai" c'est bien une limite de temps, un temp imparti et si on dépasse cette limite on est bien en dehors). Je suis aussi d'accord sur le fait que "simplifié" laisse entendre qu'il existe une version normale, complète ou étendue, mais ne dit rien à la facilité d'utilisation: les rédacteurs en sinogrammes traditionnels ne considèrent pas que leur écriture est plus "simple" à utiliser qu'avec les sinogrammes simplifiés, qui apportent des ambiguïtés supplémentaires en retirant des distinctions utiles.

Bref ici le mot "simple" veut seulement dire que l'outil se veut plus accessible (avec un apprentissage préalable moins pénible ou moins long) parce qu'il apporte de l'aide pour les constructions les plus fréquentes ou les plus productives, mais pas parce que cela réduit la complexité des requêtes (bien au contraire: il vise à permettre de faire des requêtes plus compliquées, et avec moins d'erreurs d'interprétation (ce qui veut dire que dans certains cas, il peut donner des résultats un peu plus complets ou détaillés que ce qui est attendu initialement: c'est l'utilisateur final qui risque d'être surpris peut-être mais qui découvrira des choses utiles à savoir et dont il ne soupçonnait pas l'existence au départ.

C'est bien pour ça que l'outil doit proposer des fonctions de recherche améliorées, donnant des résultats en général pertinents, mais pas nécessairement uniques et donnant assez d'informations complémentaires et la possibilité alors d'ajouter des filtres par une exploration la plus "intuitive" possible, qui ne tente surtout pas de masquer la complexité et la richesse réelle des données (et que bien souvent, ce qu'on croyait clairement distingué dans une ontologie ne l'est pas toujours dans tous les cas: Wikidata a donc tenté, sans y parvenir complètement, de modéliser la complexité mais il ne sera jamais terminé, il représente souvent d'ailleurs plusieurs ontologies parallèles, parfois concurrentes et qui si on n'y prend pas garde, peuvent conduire à des contradictions, là où les branches de modèles différents fusionnent sans moyen de qualifier les chemins de raisonnement suivi (dont celui du "modèle objet" avec ses classes et instances, un modèle en fait beaucoup trop strict pour représenter les sciences humaines: ce modèle a donc dû être annoté branche par branche: merci aux "qualificateurs" qui tentent de débroussailler un terrain difficile, mais jusqu'à présent l'utilisation des qualificateurs rend les requêtes beaucoup plus compliquées à écrire, ce serait plus simple si pour chaque niveau de déclaration on pouvait juste calculer automatiquement une métrique de pertinence plutôt que d'utiliser de façon aveugle l'inférence par induction binaire, c'est à dire vrai ou faux).

J'attends donc de voir comment mettre en place ces métriques pour enfin pouvoir utiliser ce qu'on appelle la "logique floue" (largement étudiée et très bien mises en œuvre par les géants des grands moteurs de recherche et du "Big Data", alors que basiquement la logique flou est très simple avec une arithmétique élémentaire, même si on peut raffiner les opérateurs en utilisant non pas de simples "portes" ou produits scalaires, mais des courbes de tendance et des probabilités, qui deviennent de plus en plus intéressante quand on requêtes sur des données de plus en plus volumineuses ou des métriques et tendances se dessinent très vite): son on a des métriques ainsi composables, l'arbre d'exploration s'élargit très vite mais avec des branches de poids de plus en plus faible, alors que les branches principales ont un poids bien plus élevé et font vite converger la solution: on ne fournira pas alors un résultat complet, mais on fournira vite des résultats les plus "pertinents" mais on pourra poursuivre une requête pour chercher plus loin dans les branches initialement élaguées (mai là on doit s'attendre à un moins bon temps de réponse, et peut être plus de réponse si on a dépassé les limites de calcul ou la charge sur le système, qui doit continuer à pouvoir répondre rapidement aux autres requêtes courantes).

Mais c'est justement là la force de Wikidata par rapport à d'autres systèmes utilisant des ontologies fermées: il va pouvoir trouver des réponses relativement fiables, ou au moins largement utilisables, là où les autres systèmes sont bloqués et ne vont en donner aucune (et ils auront tous de plus en plus de peine à s'adapter aux demandes sans rompre l'édifice construit sur leurs ontologies fermées, trop hiérarchisées).

Mais là aussi c'est un piège dans lequel Wikidata peut tomber s'il devient trop stricte dans ses "règles" de classification (notamment le fait d'avoir voulu y introduire un truc que je trouve assez débile, le modèle de classes/instances, qui montre déjà ses limites avec l'arrivée des métaclasses, méta-métaclasses... avec beaucoup de peine pour les distinguer: je préfère nettement le modèle plus général et mieux adapté aux sciences humaines, où tout objet est une classe et une instance, donc où tout objet hérite d'un autre en en modifiant certaines propriétés! Wikidata n'est pas un atelier pour programmeurs ou concepteurs de systèmes informatiques ou de télécommunication! Et ce sera encore plus vrai avec les données lexicographiques et traductions, et la nécessité à venir d'intégrer dans Wikidata non seulement des données pures mais aussi des "foncteurs", autrement dit des objets qui vont donner des réponses de façon progressive et pas dans un temps fini ni de façon synchrone. Et là on voit poindre Wikifonctions... absolument nécessaire pour créer un système multilingue et naturel, en langues humaines et pas en langues informatiques).