The project results are available at https://github.com/WolfgangFahl/snapquery

We just started https://github.com/WolfgangFahl/snapquery for ntroduce Named Queries and Named Query Middleware to wikidata https://phabricator.wikimedia.org/T363894

Example:
Chat-GPT4 prompt
``
create a SPARQL query for wikidata that gives a list of german chancelors and the prior ministeries they have been head of in the past
ChatGPT

@Nikerabbit - thx for the hint - my fear is that the only speciality here is that the wiki is running in a docker container. The wiki setup is generated by https://github.com/WolfgangFahl/pymediawikidocker which explicitly tries to create a "clean" environment. The templates (general and per version) in https://github.com/WolfgangFahl/pymediawikidocker/tree/main/mwdocker/resources/templates are cut&paste from an out-of-the box installation without any extensions. The LocalSettings.php changes are defined per extension in https://github.com/WolfgangFahl/pymediawikidocker/blob/main/mwdocker/resources/extensions.yaml - and except for the current issue there is no fiddling with debug parameters activated at this point - i added some commented out stuff yesterday but that's it.

@Nikerabbit - thanks for the hint - why did the message show up in the JSON response and made mwclient choke? see https://github.com/mwclient/mwclient/issues/296#issuecomment-2064066084 - or better - where should i discuss such a topic?

I got hit by this today - the deprecation message even shows up in API calls that should only create JSON results. I did not find any way to switch it off yet. I badly need a workaround and still hope that the whole parsoid idea will be dropped in favor of compatibility. Why would people have to use Lua? Python would be the language of choice these days.

What a great application of Postel's law https://en.wikipedia.org/wiki/Robustness_principle

I've linked this task to the discussion in qlever: https://github.com/ad-freiburg/qlever/discussions/588

https://phabricator.wikimedia.org/T339347 was created by me now

This page is currently fully protected and can be edited only by administrators. .... (sigh)

IMHO the documentation pointed right here. I am trying to reproduce this but only find

Some imports have been successful and the results will be further discussed in the https://wikitech.wikimedia.org/wiki/Search_Platform/Contact#Office_Hours in July 2023

according to https://github.com/ad-freiburg/qlever/discussions/588#discussioncomment-6018412

Please make https://w.wiki/6m6B work by adding both https://qlever.cs.uni-freiburg.de/dblp and https://qlever.cs.uni-freiburg.de/wikidata.

This task is not completed in time for the end of the Wikimedia Hackathon so we'll keep it open until the results for the running imports are known in a few days.

I wouldn'd cache the results on github but some other place in Wikimedia tool universe as outlined by Bryan Davis (whom i already talked about this during the hackathon last weekend)

I'd go more general and introduce "named queries". Some such queries might indeed have cached results. I'd remove the "tiny" restriction in case the named query is "relevant" e.g. popular highly requested, most useful ...

Please reopen - it's linked to the get your own copy of wikidata Wikimedia-Hackathon task and might renaming and stating the concrete goals. E.g. for the subsetting this is linked to https://github.com/ad-freiburg/qlever/issues/859.
So having different (and not time limited endpoints) support a subset of Wikidata is actually one of the issues. See also https://cr.bitplan.com/index.php/List_of_Queries where a similar set of queries is needed (but the timeout issue is not a s big)

I would have expected that an LTS version pins all dependencies. Wouldn't stability be here the more important goal than staying up-to-date? This case of breaking the system "out of blue air" is IMHO a warning call. Taking it seriously and changing the procedures would IMHO be an adequate response. Would the request for this stabiity with pinned versions be a new phabricator task or has this already been discussed and there is a task for it?

see also https://stackoverflow.com/questions/76072671/guzzle-update-breaks-mediawiki-1-39-3-lts-how-can-dependency-hell-be-avoided-f

What is the work around for 1.39.3?

Tonight I'm bringing up the topic of getting a proper Wikidata mirror running in the https://etherpad.wikimedia.org/p/Search_Platform_Office_Hours - may be you can attend to give background info on what you imagine. I could already offer to use our wikidata machine at RWTH Aachen as an endpoint where we do our "Get your own copy of wikidata" experiments.

@Nikki - your comment is a valid concern which IMHO could be easily solvable by selecting the URL handling. Obviously the discussion is about more choices and avoiding the "URL shortening failed" which is just not acceptable as a message/result in my opinon. There should be a least a link to explaining the choices and solutions available or better make these solutions/choices directly available.

I second that the variable extension functionality should be incorporated in to parsoid or drop the whole parsoid improvement ideas that call for removing the variable extension. For me the variables extension is much more important than the parsoid improvement ideas discussed here. These improvement ideas are IMHO introducing more complexity than solving problems for end users if the current way of implementation is enforced. The worst part for me is currently that on each and every new wiki i create the first thing that pops up is the deprecation message in a fully useable wiki - this makes it look as if the wiki would be broken which it isn't at this point. De-Deprecation would be much appreciated by me.

Why not go with "named queries" while at it? The examples Button at https://query.wikidata.org/ currently has 363 such "named queries". If the names would have a namespace structure it would be an ideal way of having two ways to reference a query

see T220703

We are using this great feature in https://cr.bitplan.com/index.php/List_of_Queries but run into length limits for some of our queries e.g. try it !

The worst part is IMHO the message URL-shortening failed / URL-Kürzung fehlgeschlagen - instead it should offer workarounds and alternatives. It's quite strange that his is being discussed for many years given that there is such a big need.

We are using this great feature in https://cr.bitplan.com/index.php/List_of_Queries but run into length limits for some of our queries e.g. try it !

I ran into this today see https://github.com/LeMyst/WikibaseIntegrator/discussions/507

Generally we need a reliable much higher timeout wikidata query service. Currently you are kind of forced to get your own copy of wikidata see e.g. https://wikidataworkshop.github.io/2022/papers/Wikidata_Workshop_2022_paper_4558.pdf

7.3 seems to work thanks god ...

This is quite a horror show. I do not even use pywikibot just import it and it throws a ton of log stuff at me. Unfortunately this is marked as resolved without given the clear answer what version makes sure that the logging is not verbose by default.

I don't have permissions to create projects in Phabricator. I'd love to take over the original project of PDFEmbed or create a new one for it and I'l love to create an new general RESTFul extension that has no name yet. How would i start those two projects?

I'd just love to make the project more linked to the Wikimedia world and I feel a bit remote with what I am currently doing.

Couldn't i open a project for the extension or might there already be one?

Diagrams. bitplan.com happily accepts POST requests. So will any local installation of the python server or the PHP server by Samwilson. Would you like to see some kind of python API for this to simplify the usage or what are your needs to get this working for your usecase?

@Xqt - thanks for considering our diagrams server. If you have any questions on how to install it on your own infrastructure let me know. If you'd like to use it as is you are welcome as long as the load on the server will
be moderate.

I was hit by this problem again today and did a google search on 'mediawiki "Fehler beim Erstellen des Vorschaubildes: Datei fehlt "' and you find lot's of wikis suffering from this problem. In at least one case the wiki was abandoned in 2016 and replaced by a wordpress site and i would not be suprised if the reason was that the error reasond could not be identified by the new admins of the wiki as soon as their mediawiki specialist was gone.
Please reconsider
This is way too complicated and very unlikely to happen.

Looks good to me in paper form.

This is all i have. See https://github.com/WolfgangFahl/py-3rdparty-mediawiki/blob/067d2291e79c2f73726c177ac0dc3a889d43ef19/tests/test_SMWApi.py#L148. With scriptpath returning "/" the behavior shown in the log below happened. https://github.com/WolfgangFahl/py-3rdparty-mediawiki/commit/067d2291e79c2f73726c177ac0dc3a889d43ef19 fixed this - the family python file is generated and now has the changes.

@Xqt - you are right might have been 6.0.1 - I'll watch the situation. Currently py-3rdparty-mediawiki uses semantic depencency:

**Do you have a sample for investigation?
It turned out that i had set the scriptpath to "/" where an empty scriptpath was expected. I think even that this used to work in the past. The workaround was to set the scriptpath to "" again.

pymediawikidocker currently tries to use the same version of an extension accross all versions of MediaWiki. The version i intended to selected for this was 5.2.1 which actually works.
The composer syntax i used was "^5.2.1" which actually seems to select the version 5.3 for Mediawiki 1.31 which leads to an incompatibility.

see https://github.com/WolfgangFahl/pymediawikidocker/issues/22

in the case a timeout occurs the original error messages should IMHO be made available as part of the exception and a hint given that this information is available. Otherwise it's IMHO to hard to debug such situations.

Could you please point to the ticket/project where the progress of the intended improvement of setting up local versions of WDQS is tracked?

The problem persists. It just takes longer until it shows up. I can't upgrade my Mac OS and the machine was specifically bought just for the purpose of running wikidata hence the 12 cores and 64 GB of RAM.

The preview files still do not render the gradient correctly.

I have now worked around the problem by using a HSL to RGB conversion in the script that creates the Icons. All 11 icons are now uploaded.

Is there some workaround by changing the gradient style, version or anything?

@AID-PMBD just get in touch with me @Samwilson and I have been working on a solution which works in my wikis see http://wiki.bitplan.com/index.php/GraphViz. http://wiki.bitplan.com/index.php/Special:Version. There is a contact form at http://www.bitplan.com/index.php/Contact or use any of the contact options at http://training.bitplan.com/index.php/Wolfgang_Fahl

http://s.bitplan.com/wiki/index.php/Template:Jscad has now an example for a template using the OpenJsCad alpha version extension.
see

• http://s.bitplan.com/wiki/index.php/Special:Version
• http://s.bitplan.com/wiki/extensions/OpenJsCad/

@Aklapper: Thanks for the hint - Oh that one - that looked like a fifth account with still a different password - that one is in my password safe. - Indeed it is the seppl2017 account mentioned by @MarkAHershberger - the username is seppl2017 and the fullname WolfgangFahl.

@MarkAHershberger - thank you for looking into this. So at it looks there are currently four accounts for me:

Thx for the hint. I still need more info to start working. How are the rights for extension git repositories managed? How do you get my initial code reviewed if i can't push it?

Now the git repository is available but I do not have access rights to it.

The Request I put in https://www.mediawiki.org/wiki/Gerrit/New_repositories/Requests was in the meantime corrected to have the path mediawiki/extensions/OpenJsCad - thanks for that. For the code review model I am not sure what the difference between the two is. https://www.mediawiki.org/wiki/Gerrit/Privilege_policy#Other_MediaWiki_extensions does not even mention "open push". I am not familiar with the git repository of wikimedia as a contributor. In the past I worked with github projects where you can have a limited set of users with rights. How are the rights for extension git repositories managed?

https://www.mediawiki.org/wiki/Extension:OpenJsCad has a draft mediawiki page for this extension