User talk:Zolo

Previous discussion was archived at User talk:Zolo/Archive 1 on 2015-08-10.

Hi Zolo,

Following, this question on the Dutch Wikipedia helpdesk, I address this message to you.

Q21086297 has been created by you, back in 2015. Is there a reason why this is a different item then Q3662995? Should they co-exist? Should the items be merged? Or should the newest be deleted and their Wikipedia pages be updated accordingly?

Best regards, Démarche Modi (talk) 16:03, 27 November 2022 (UTC)

Hi one item is about a structure Pompey, the other about a type of structure

Thank you!

The links do not work for these, can you add a new url, and load the image to Wiki Commons:

*Q15268919

*Q111333170

*Q111336806

I already fixed these two:

*Q111336807

*Q111333077

• I updated the link for Paul Morand (1888-1976) birth certificate (Q15268919) fQ#uielem_move=184.68333435058594%2C75&uielem_islocked=0&uielem_zoom=73&uielem_brightness=0&uielem_contrast=0&uielem_isinverted=0&uielem_rotate=F
• Félix Roguet (1823-1888) death record (Q111333170) works. Record number 604 page numbered 78 in the original document and 19 in the online file. Not sure how it should rendered on
• the link in Henry-Léon Bulot (1820-1889) birth record (Q111336806) works for me, but I can't find the right page. It is rather long and hard to read

Thanks!

Dear Zolo,

I hope you are doing good,

I am Kholoud, a researcher at King's College London, and I work on a project as part of my PhD research, in which I have developed a personalised recommender system that suggests Wikidata items for the editors based on their past edits. I am collaborating on this project with Elena Simperl and Miaojing Shi.

I am inviting you to a task-based study that will ask you to provide your judgments about the relevance of the items suggested by our system based on your previous edits.

Participation is completely voluntary, and your cooperation will enable us to evaluate the accuracy of the recommender system in suggesting relevant items to you. We will analyse the results anonymised, and they will be published to a research venue.

The study will start in late January 2022 or early February 2022, and it should take no more than 30 minutes.

If you agree to participate in this study, please either contact me at [] or use this form https://docs.google.com/forms/d/e/1FAIpQLSees9WzFXR0Vl3mHLkZCaByeFHRrBy51kBca53euq9nt3XWog/viewform?usp=sf_link

I will contact you with the link to start the study.

For more information about the study, please read this post: https://www.wikidata.org/wiki/User:Kholoudsaa

In case you have further questions or require more information, don't hesitate to contact me through my mentioned email.

Thank you for considering taking part in this research.

Regards

Hello

You're an contributor to {{Item documentation}}. For your information, I've launched a request for comments about the topic : Wikidata:Requests for comment/How should we develop and deploy documentation for items ?. Feel free to give your advice.

Hi, I created a new page for collecting sites that could be added to Mix'n'match and I plan to expand it with the ones that already have scrapers by category. Feel free to expand, use for property creation. Best, Adam Harangozó (talk) 15:40, 21 October 2019 (UTC)

Ok thanks I'll have a look !

Bonjour Zolo ! En voyant Q56395326, je me suis laissé dire qu'il pourrait être opportun de rechercher toutes les déclarations du site en source avec URL de la référence, pour y ajouter cet élément. Qu'en penses-tu ?

Bonjour user:Nomen ad hoc.Désolé je réponds un peu tard. Oui tout à fait d'accord, pour ce cas, et pour pas mal d'autres qui lui sont similaires. On doit pouvoir retrouver les éléments concernés avec une recherche sparql, mais c'est quand même un peu fastidieux. On aurait besoin d'un bot pour faire ça, mais je ne crois pas qu'il existe, et je me sens pas trop capable de me lancer dans sa construction pour l'instant...

Pas de souci pour la réponse, mon message ne datait que de quelques jours. Dommage que le répertoire ne soit pas bâti avec des notices individuelles, ça aurait facilité les choses !

Au passage, maintenant que l'élément existe, tu ajoutais quand même l'URL de référence à titre subsidiaire dans les déclarations ? J'ai un doute pour Q520375#P5021, par exemple.

?

Ajouter ce genre de lien peut avoir du sens, je pense, dans la mesure où il est plus spécifique que celui stocké sur Q56395326. En revanche, tu les a entré comme deux sources séparés, alors qu'il s'agit de la même source. J'ai changé ça .

Entendu ! (Et désolé :)

Hello! Unfortunately, your administrator flag was removed for not making the required 5 actions in the last 6 months. Thanks for your work!

Alors c'est mignon [https://www.wikidata.org/w/index.php?title=Q32075377&oldid=prev&diff=628071858 ça], mais tout ce que j'ai fait à l'époque, c'est lier les catégories commons Category:Model railroaders et Catégorie:Modéliste ferroviaire (qui sont strictement équivalentes), depuis Commons. Je n'ai pas utilisé stricto sensu l'outil de fusion de wikidata, d'ailleurs je n'ai même pas fait cette modification depuis wikidata. Ce n'est pas ma faute si de base la catégorie Commons (et comme ta modification vient de le rétablir) est à une place où elle n'a rien à faire, ie sur une page d'item au lieu d'une page de catégorie.

Ok, si l'éditeur de lien prévient pas qu'il fait une fusion c'est aussi un probléme avec l'iutil, mais il n'en reste pas moins que la modif est mauvaise (fusion d'une "nature de l'élément : catégorie" et "nature de l'élément : occupation", et problème similaire pour les libellés en / fr). Après une fusion, un bot change toutes les valeurs dans les autres éléments pour ne pas lier à des pages de redirection, et c'est long de revenir correctement en arrière quand il y a un problème. Lier une catégorie Commons à un élément Wikidata ne portant pas sur une catégorie n'est pas recommandé, mais en pratique c'est très très courant (c'est même je pense la majorité des cas), donc si l'outil ne prévient pas, il faut éviter de faire ce genre de manip sans vérifier.

Bonjour. Sur Scholfield Creek, j'aimerais que les coordonnées géographiques renseignées via coordinate location (P625) en qualificatif de mouth of the watercourse (P403) s'affichent sous la mention "Umpqua". Pourrais-tu voir, si tu as le temps, et modifier Module:Infobox/Rivière en conséquence ?

Bonjour,

C'est relativement simple ç faire, mais je pense que pour la plupart des gens, ce n'est pas très parlant. A mon avis, le mieux serait d'afficher une carte avec un point pour l'embouchur, un point pour la source, et peurt-être d'autres. Il faudrait aussi sans doute revoir la partie "localisation" : le mot "adresse" est bizarre pour un cours d'eau et j'ai de très gros doute sur la pertinence du champ "continent". Ce n'est pas forcément par oubli que ce champ ne figure pas dans l'infobox cours d'eau : si on va lire un article sur une rivière, on sait normalement déjà dans quel continent elle se trouve. Enfin, un peu comme pour l'infobox Localité et biographie, je pense qu'avoir deux infobox pour le même sujet '(cours d'eau et rivière) et une mauvaise idée : plus de confusion, plus de travail de maintenance, et plus de désaccords potentiels sur le choix de l'infobox à utiliser. Dans mon expérience, passer un modèle à Wikidata / Lua ne pose pas de beaucoup de problèmes politique sur Wikipédia, en revanche, en revanche la cohabitation de deux modèles d'infobox....

Je n'ai pas osé te demander le système des doubles points, qui existe je crois sur Wikipédia en russe. Mais effectivement c'est ce qui serait le mieux. Quant à lui, le système des doubles Infobox a l'avantage de permettre de contrôler l'introduction petit à petit d'informations nouvelles dans Wikipédia : si on convertit une version existante, il faut au contraire tout à coup vérifier tous les champs. Et puis je ne suis pas sûr que ce soit plus facile : la pratique des doubles Infobox m'indique que c'est plutôt un facilitateur. Les gens s'y convertissent. Par contre, oui, cela engendre du boulot de fusion pour plus tard et c'est donc d'un certain point de vue un peu paresseux ! Enfin je te dis franchement ce que le continent fait là : c'est précisément parce que c'est un champ indisponible sur les vieilles versions qu'il m'est utile. Il sert à refroidir, si nécessaire, celui qui voudrait tout refaire à l'ancienne et remplacer la nouvelle Infobox par son aïeule. Il ne pourra pas tout afficher comme avec le nouveau modèle et le continent est donc - entre autres choses - le garde-fou psychologique de celui-ci ! Et puis concrètement je crois qu'il prépare une nouvelle propriété que je vais finir par proposer en remplacement : 'island' ou 'landmass'.

Ok, j'ai adapté les modules pour faire une carte à deux points. Cela dit, il serait encore mieux d'afficher d'afficher le cours entier. Si les données sont sur OpenStreetMap, ça sera fait automatiquement, mais je suis pas sûr qu'OSM gère les cours d'eau. Il faudrait se servir de geoshape (P3896)

Merci. C'est excellent. Je vois que tu sembles préférer que les coordonnées soient stockées sous coordinate location (P625) avec applies to part (P518) pour indiquer source ou embouchure. Moi aussi, je crois. J'ai cependant souvent croisé des coordonnées stockées en qualificatifs de origin of the watercourse (P885), mouth of the watercourse (P403) ou autres. Est-ce que le module peut aller les chercher le cas échéant ou bien en reste-t-on là ?

J'ai donc posé une question sur le stockage des données sur Wikidata talk:WikiProject Rivers. Aussi, puisque j'y pense : les doubles coordonnées pourraient déterminer le niveau de zoom optimal pour les cartes de l'Infobox, éventuellement.

Je pense qu'il vaut mieux adopter une solution unique, mais si on y arrive pas, ce serait éventuellement possible d'adapter le modèle. J'ai adapté le module carte pour que le zoom s'adapte aux coordonnées des marqueurs affichés sur la carte.

Bonjour,

Je viens de remarquer un changement pour le moins problématique concernant les entités Q51252 et Q16335227 (et j'imagine, potentiellement d'autres situations du même type).

Je comprends très bien la motivation de votre modification, mais le souci est que presque aucune oeuvre dont la property Property:P195 est Q51252 n'a été migrée vers Q16335227 (eg. Q151047). En résultat, toutes les collections du musée font désormais partie d'une entité qui n'est elle-même plus un musée.

Vous serait-il possible de corriger le tir sur cette migration ? Ou doit-on reverse le changement de type sur Q51252 en attendant que la migration soit faite ?

Bonjour Eledeuh,

Effectivement, la distinction / bâtiment pose couramment ce type de problème, et dans ce cas, par malchance, l'élément le plus utilisé est celui qui porte sur le bâtiment. J'ai fait une demande de mise à jour sur Wikidata:Bot requests.

Merci !