A lot of things were done with help from Bruno Perel, including
The community has already stated three years ago that an endpoint with authentication would see very little traction because it just won't be used for building tools (because of the authentication hurdle). Obviously running it for three years and the little traffic it has received proves exactly that point.
I get this error now on all pages on both wikidata.org and en.wikipedia.org.
In T297995#8872458, @Legoktm wrote:My impression from speaking with multiple people at the hackathon is that the authentication requirement is a barrier for people to even use the service in the first place, which defeats the point.
And so the story of the GWToolset ends. Thanks to all who helped on maintaining it and also giving it its deserved resting place. We did a farewell ceremony at the autumn Wikimedia NL hackathon last year, for those interested, here are the pictures.
Notes from the Etherpad:
Notes from the presentation:
Relevant notes from an earlier community call about this topic: https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/Draft/External_Trends/Community_call_notes
Yeah, i agree this can be closed now.
@Krinkle ha, yes you're right. Nice that somebody finally noticed it ;)
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:
@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:
- 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:
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!