In T276295#7878352, @bd808 wrote:

I think this would be mostly a matter of UI support for editing and rendering and maybe a small amount of documentation. We should be able to find a 3rd party Vue component or other library for both the rendering and rich editing of commonmark.

In T306547#7871538, @bd808 wrote:

Fair point. We made the creation screen a smaller set of values in part to avoid overwhelming folks with all the things that are possible in a toolinfo record. Perhaps we should revisit this idea.

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.

@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.

@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.

@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.

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).

Seems this is live on production. Great to see this finally working!

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.

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.

@Spinster: the algorithm for 'normalizing' input in Minefield is roughly as follows:

+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.

@Majavah, i see. Thanks for linking to that!

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?

This tool is now live here: https://hay.toolforge.org/depictor/

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.

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:

Copying my comment from the duplicate task here about why this would be very useful (apart from machine learning):

In T253053#6736635, @JeanFred wrote:

Appears to be a duplicate of T230315: [XL] Create a way to see and add references to structured data on Commons (MediaInfo) statements ?

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.

@CBogen cool, thanks for the update. Really looking forward to be able to test something!

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:

+1. Machine learning is a good usecase, but there are many others:

In T252251#6125812, @Ramsey-WMF wrote:

1. A while ago, we updated the suggested search dropdown to include an easier way to do haswbstatement:P180 searches. Try any search on Commons using the default search box and you'll see the "Files depicting..." section at the bottom of the suggestion list.

Yeah, i noticed that. Seems like a small but interesting step!

I don't see the same things that @Dominicbm sees, so this might have been fixed by the rollback?

In T221921#6103577, @Spinster wrote:

As for a SPARQL endpoint being challenging for many end users from an UX perspective - I would say: don't underestimate our end users and community.

+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).

In T207170#6033359, @Aklapper wrote:

@Jane023, @Husky: Did someone work on this? Asking as Wikistorm 2018 and 2019 are over and as there are no other project tags on this task. If this should still be open, please add an active project tag via the Add Action... → Change Project Tags dropdown. Thanks!

In T208026#6033353, @Aklapper wrote:

I'm blodly closing this task per last comment, as Wikistorm 2018 is over and as no other project tag is added to this task.

In T221921#5973902, @Jarekt wrote:

That would be great. I think the frustration is due to expectations management.

+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?

@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.

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.

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!

@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.

Hey, as a proof of concept, i've adapted my VizQuery tool to use the beta endpoint.

Should we still do this? See my previous comment. I doubt this dataset is very useful.

In T222089#5225239, @Krenair wrote:

wmflabs.org should probably be a whole separate ticket.

@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.

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.

@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:

@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.

And the current code (now a nagfree script is located here

Here's a video of the current (very basic) prototype: https://www.youtube.com/watch?v=e59qKhin1Mg&feature=youtu.be