User Details
- User Since
- Oct 27 2014, 12:11 AM (401 w, 1 d)
- Availability
- Available
- LDAP User
- Hay
- MediaWiki User
- Husky [ Global Accounts ]
Apr 26 2022
Depending on how many extra fields there would be on that screen i think that as long as optional fields are marked as such (and maybe placed at the bottom of the screen) this will be fine.
Apr 21 2022
@bd808 great, i didn't know that! It doesn't show that value in the 'Add or remove tools' screen though. Also, it might be useful to add a link to the documentation to the 'add a toolinfo.json' screen, and maybe provide the Toolhub page as a good example on how it will look like if all the values are filled.
@JJMC89: i could imagine that for the case you're mentioning here it might be useful to display the id *after* the title/description, although i can't estimate how big of a problem this actually is.
@bd808: using localStorage seems completely fine to me. It's not the end of the world if this setting is lost on another browser or when deleting the cache.
Apr 20 2022
@bd808: i've also added a couple new issues concerning UX improvements:
- T306546: Remove / hide / reorder rarely used menu items
- T306544: Toolhub logo should be clickable and go to homepage
- T306542: Remove ID from autosuggest on search input form and add descriptions
- T306541: Swap around 'Source code' and 'Browse tool' buttons on tool detail page
- T306538: Add option to change number of items on search result screen
- T306536: Reorder facets on search result screen to something more logical
- T306534: Searching the hub should be more discoverable
@bd808 yes, this definitely makes things a lot easier now, nice work! I still think there's a lot that can be done to make the user flow easier and more intuitive, but for now i'll close this ticket given that the main concern has been fixed.
Jan 16 2022
@Majavah okay, this was due to an older composer.json that was requiring v1.1.0 that had its dependency set as ">=7.2.9". Upgrading to v1.2.0 solved the issue.
Jan 13 2022
Yup, just run into this as well. I would think that PHP 8.0 and 8.1 are mostly backwards compatible with earlier versions, and i've experienced no problems running the client under PHP 8 on my local dev machine (unfortunately Toolforge doesn't support it yet, see T269073).
Jan 11 2022
Seems this is live on production. Great to see this finally working!
Dec 17 2021
Because it prevents creating client only solutions and requests would need to be routed via proxy which would do the authentication. This would increase overall complexity.
+1. We're in a really fortunate position to being one of the very few large websites with an API that is accessible without authentication. It's really beneficial when explaining concepts of API's and knowledge graphs to students and they don't need to go through hoops to understand authentication and other things before doing a simple HTTP GET call. It's in our mission that we want to share the sum of human knowledge. It doesn't say anywhere that we should make that as easy as possible, but i think we should. Putting up an authentication layer is making it harder for people to access our knowledge.
Nov 25 2021
Hey @aborrero, i'm only now reading the whole section about increasing CPU and memory usage using the webservice command, so i'll try that first and raise memory to 4 and maybe 8GB. If i still get out of memory errors i'll post a message here again.
Nov 24 2021
Oct 21 2021
@Spinster: the algorithm for 'normalizing' input in Minefield is roughly as follows:
Oct 13 2021
+1. This would be really useful, especially for inline links and simple text formatting.
In hindsight i think the decision to make tool names unique in the toolinfo scheme was wrong. It's really difficult to have a uniqueness requirement without being able to actually enforce it. If i would do it again now i would probably opt for an approach where tools get a unique id, maybe in the some way Wikidata does it: simply start with 1 and keep adding up.
I'm not sure why a 'Back to Home' button is needed. There's already a home button in the sidebar nav right? On mobile the hamburger menu is serving the same job. When i first tried out the Toolhub i had no problems at all finding the home button.
As a tool author i would be interested in this feature. However, i would refrain from adding too much features. There's already a communication problem with many of the tools because there are so many possible places where people can get support and discuss the project (e.g. on several WM projects, on social media, over e-mail, etc.). I think maybe having an option to directly link to a 'documentation homepage' (instead of just the regular tool link) might be useful though.
Sep 1 2021
@Majavah, i see. Thanks for linking to that!
Aug 27 2021
Okay, it seems logical then not to provide PHP 8 until Debian Bullseye is deployed? PHP 7.4 is actively supported until end november this year, and getting security support until end november 2022. Debian Buster is EOL in August 2022, so i imagine somewhere within that timeframe PHP 8 and/or a new Debian version might be coming?
Aug 26 2021
This tool is now live here: https://hay.toolforge.org/depictor/
Aug 23 2021
Would really love to see this version available as well, many new features to write cleaner code, including named arguments and union types. See here for a full list.
Aug 13 2021
Yeah, great! This simplifies the queries so much, without that awful hack of using the string concat method. Finding all images depicting Douglas Adams is now just:
Jan 12 2021
Copying my comment from the duplicate task here about why this would be very useful (apart from machine learning):
Jan 11 2021
Jul 24 2020
See https://tinyurl.com/y26mtate for an example of how this is currently done. Given that items returned will virtually always be images (or at least things that can be represented as images) i guess it makes sense that every query always returns images and maybe uses the ImageGrid view as the default as well.
May 26 2020
@CBogen cool, thanks for the update. Really looking forward to be able to test something!
May 25 2020
May 24 2020
Note that i've been working on a tool called Structured Search that is pretty much a proof-of-concept of how a revamped Commons search interface would look like. Also see ticket T252251.
@Ramsey-WMF you might want to take a look at the prototype again, i've improved it quite a bit with a couple of new things:
May 18 2020
+1. Machine learning is a good usecase, but there are many others:
May 12 2020
Yeah, i noticed that. Seems like a small but interesting step!
May 10 2020
May 8 2020
May 7 2020
I don't see the same things that @Dominicbm sees, so this might have been fixed by the rollback?
May 4 2020
+1. SPARQL is definitely not for the 'average' user, fortunately we don't have many average users on our projects. Also note that a SPARQL endpoint can easily serve as the fundament of tools that are more user-friendly, for example my own VizQuery uses the Wikidata SPARQL service. To adapt that to a future stable SDoC / Commons endpoint would literally be a one-line code change. It already works on the old beta service (if that would still work).
Apr 6 2020
Mar 16 2020
+1. It's pretty hard to stay excited about SDoC when there's no proper way to view the hard work that is being done with editing all images, *especially* when there's no way to take Wikidata items into the same query. What's the point of tagging all the reproductions of the Mona Lisa with a 'depicts' statement if there's no way to do a query on them? Or having a completely separate, other way of doing that?
Dec 16 2019
@Gehel, thanks for your response!
@Jarekt afaik this is only a proof of concept. However, the data does seem to be updated (previously it only had the data from april or so). I don't know who is currently maintaining the beta, but maybe @Lea_Lacroix_WMDE or @Lydia_Pintscher knows.
Dec 9 2019
Another domain is fine for me. About the privacy/security implications: now people are using alternatives like bit.ly and tinyurl.com over which we have zero control in terms of privacy implications. So i guess anything we can create/control ourselves would be better.
Dec 8 2019
Nov 23 2019
Nov 22 2019
The tool mentioned by @Spinster above is done and working over here:
Well, the tool is done and working:
I've also added support for PagePile ids now. Also in the hash by the way:
A fixed a couple of problems and all the example lists posted in this issue should now work!
Nov 18 2019
@Spinster, i don't think so. There's no unique identifier, and the data itself is pretty meagre compared to the Rijksmonumenten database. Let's not waste more effort in doing something with this dataset.
Nov 11 2019
Hey, as a proof of concept, i've adapted my VizQuery tool to use the beta endpoint.
Nov 5 2019
Should we still do this? See my previous comment. I doubt this dataset is very useful.
Oct 28 2019
Aug 29 2019
May 29 2019
@Ecritures misschien wel interessant, maar ik zou er eerst even in moeten duiken.
@Ecritures ik heb hier wel aan gewerkt, maar ik kan me niet meer zo heel goed herinneren of het iets heeft opgeleverd. Wat mij betreft mag het van het bord.
May 17 2019
It would also be really nice if this could export to either GeoJSON or TopoJSON, because it makes it a lot easier to integrate query results in visualisation tools. For example, Vega-lite maps.
Nov 7 2018
@valhallasw thanks for trying out a couple of things, and indeed confirming that using the location won't work. I was pretty confused by the HNO / HNE columns as well, unfortunately there doesn't seem to be any kind of description of what those fields actually mean.
@valhallasw that could be an interesting option, but would it also work if there are many monuments that are close to each other, like in the centre of Amsterdam?
When looking closer at this dataset i doubt it's going to be very useful. There's a couple of reasons for that:
Nov 6 2018
@1Veertje: i downloaded your SQL files and converted them to a CSV dump (see attachment). However, i think maybe something went wrong because i don't see many improvements. Many of the streetnames seem to be truncated because of a VARCHAR limit, e.g. rijnr 8895 now has 'Burgemeester van Dobben de Bru' instead of 'Burgemeester van Dobben de Bruijnstraat'. i've also included a Jupyter Notebook with the zip file, maybe you can see for yourself if i missed something.
Oct 27 2018
Here's a video of the current (very basic) prototype: https://www.youtube.com/watch?v=e59qKhin1Mg&feature=youtu.be