Sun, Mar 15
The indexing in connection with lexemes are now slow again. For instance, during creation of L270066, the form L270066-F3 is not available for use.
I am wondering whether @Bstorm could clarify if -m 1Gi is a typo and should have been -m 1G?
Mar 1 2020
Feb 29 2020
Thanks for the explanation and the restart
Feb 26 2020
There might be a bug in webservice migrate: https://wikitech.wikimedia.org/w/index.php?title=Talk%3ANews%2F2020_Kubernetes_cluster_migration&type=revision&diff=1856814&oldid=1856342
Feb 25 2020
Feb 21 2020
I think was due to our tool (import error on lxml on new server) as well as the problem with virtual environment change during migration. It seems to work now. https://tools.wmflabs.org/scholia/
Also tracking this at https://github.com/fnielsen/scholia/issues/1013
Dec 11 2019
Both the entity IDs and the label searches were slow. The search is now fast again, so I can make it "Resolved" (or something else?). I suppose it could have been a temporary lag in elasticsearch.
Dec 10 2019
Is @Multichill able to add 172.16.0.0/12 to https://www.wikidata.org/wiki/MediaWiki:Autoblock_whitelist ?
This seems not to be confined to lexemes but also the case for Q-items.
A possible unrelated issue is Magnus Manske's sourcemd that is also in non-working condition. https://twitter.com/MagnusManske/status/1204000679116849152
Dec 3 2019
My two tools came up nicely yesterday evening/night.
Oct 28 2019
I think the design of Wikidata lexeme was inspired by the work around wordnets and Ontolex. In the wordnet world, a sense is the intermediate step between a lexeme and a concept/synset, see Ontolex specification where the sense is called LexicalSense https://www.w3.org/2016/05/ontolex/
I suppose this issue was inspired by the discussion after Lydia's talk at WikidataCon 2019: https://media.ccc.de/v/wikidatacon2019-2-wikidata_and_languages#t=2788 . I have now gone back to see how I actually handle there situations for Danish.
Oct 2 2019
Sep 27 2019
The query is a bit hard on WDQS. If one execute it twice then the second time can apparently use some caching from the first.
Here a variation on @Yurik's query with count on within-language forms: https://w.wiki/8y8 (current count is obfuscated by Tamil annotation). For instance, 'led' in Ordia shows 9 lexemes from 3 language: https://tools.wmflabs.org/ordia/representation/led
I count over 30 basic lexemes on https://en.wiktionary.org/wiki/for while there may be more when we start to count inflections and derived terms ...
Sep 18 2019
Maybe the priority should just be "high" as few users might be viewing the 3D models?
There was some work on I18N branches in Ordia: https://github.com/fnielsen/ordia/branches It is not yet implemented in Scholia
I have changed the priority to unbreak now. I do not know if that is appropriate. The problem is that it is currently not possible to interact (basically) with 3D models on the Wikimedia sites, - only by downloading and viewing them in e.g. meshlab.
I can confirm this on Ubuntu Firefox 69.0:
Sep 16 2019
It seems that this was the only one.
I have now edited the lexeme back and forth (https://www.wikidata.org/w/index.php?title=Lexeme:L10531&action=history) which switched the language to wd:Q9056.
Sep 13 2019
Aug 29 2019
Thanks, that was apparently not submitted but just shown as preview
Aug 22 2019
Aug 16 2019
Aug 15 2019
There has been a recent namespace change announced at https://lists.wikimedia.org/pipermail/wikidata/2019-August/013350.html but this was with dcatap.
Yes, there is a Q/P mixup. DESCRIBE wd:P20980928 gives 512 results.
Aug 14 2019
Aug 2 2019
Works for me now too. Thanks!
Aug 1 2019
Yes. It is back.
Yes, fixed at my end too.
My browser is Firefox.
The lexeme has these language fields for word stem.
Yes, I experience no error on the main sight now.
Jul 15 2019
The error also appears when the first gloss is reedited
If the page is reloaded by the browser then it is possible to enter the second gloss.
Jul 2 2019
Jun 18 2019
This may have been a temporary error. It works now.
BTW: This affect the ShEx validator.
Quite a number of panels in Scholia has been affected by the change/bug, e.g., https://tools.wmflabs.org/scholia/author/Q20980928 "Number of publications per year", "Number of pages per year" and "Citations by year".
Jun 2 2019
As a tool provider it would (also) be nice to have the data transposed - so to speak: Eg. https://tools.wmflabs.org/toolviews/api/v1/tool/scholia where the returned data is across multiple days.
May 24 2019
Further development issues are noted here: https://github.com/fnielsen/scholia/issues/721
This was related to Wikimedia-Hackathon-2019.
May 19 2019
May 17 2019
Maybe this is not a bug per se, but intentional? There is not yet a Fon Wikipedia, - it is on Incubator.
May 6 2019
Yes, it has been working fine now.
This seems to work fine now.
May 2 2019
Another way to generate status code 500 is by, e.g.,
Apr 30 2019
Apr 14 2019
Commands such as these seems to have fixed it:
webservice --backend=kubernetes python shell cd www/python python3 /usr/lib/python3/dist-packages/virtualenv.py --python=python3.4 venv3.4 ln -s venv3.4 venv cd ordia ; pip install -rrequirements.txt
It is a python3.4/python3.5 issue? The Virtualenv I can construct is 3.5. Kubernetes start Python 3.4.2.
Ordia's uwsgi.log looks basically the same as QuickCategories. And with restart I get the same message.
Apr 4 2019
Yes. This may have been a temporary issue.
Apr 2 2019
Apr 1 2019
currentDay gadget for P813 now in troubles. I wonder if the fix/changes related to this issue.
The fix works for me. Thanks!
Mar 31 2019
Mar 27 2019
Mar 14 2019
The issue must related to a change happening on 13 March or a few days before.
Mar 13 2019
Feb 4 2019
There have been slow response from Toolforge services. I use sourcemd and scholia. sourcemd was just slow, and have been slow from time to time. In scholia I have seen error messages like: