Sorry, forget my last comment, it was my fault, everything is OK. I think this ticket can be closed now.

The big lexeme writing job went through well. I have found a way to batch-write to entities bigger than 1MB.
On the other hand, I have written statements to 67,102 items, but only 64,989 appear to be updated in the QS. I have tried several times (example), but the remaining 2,500+ stay without updating. Any stuck jobs in the update pile?

I appreciate your efforts a lot, you have reacted to this very fast! This weekend (or closely after the weekend) I have to write another lexical dataset to the lilamorph instance. I hope that won't cause more hickups in the query update, and that you do not have to spend time on fixing failed update jobs on that instance. On the other hand, I guess it is good to do the test, and see if the system now bears with another dataset like this?

Wonderful! Don't apologize! Everything seems fixed now (all lexemes appear in SPARQL.
I have tried the new upload with 1.5 sec sleep time for 50 items (bot script), and everything appears after no delay in SPARQL. I proceed to write the dataset.

Great. I plan to write another lexeme dataset on the same instance this evening, some of them are really huge (500 forms). Some 8.000 of them. Should I just try, again with 0.34 sec sleep time between API calls, as last time, or should I increase the sleep time? I do one api call for writing the whole lexeme (not adding single forms using wbladdform but building the whole thing and writing it).

The sparql query that should bring up all lexemes from this collection, instead of 10.610 now brings up 9575 results.

In T406426#11258243, @Tarrow wrote:

@DL2204
At the same time and since then, the "recent changes" page of that instance stopped to work while logged in (but does work when logged out)

I overlooked this but it seems like a different issue all together. Does it now appear to be fixed?

I can only think of the maybe unusual amount of forms that are attached to each of these lexeme entities as what makes this dataset "special". However, I have been writing lexemes with a lot of forms before - without problems. btw, the same query now gives different results (it is not the same lexemes showing up), and less (at the moment, 1,225 results).

Update:

• Edits appear again at "recent changes" (but edits present in the user contribution and in the page edit history from some days do not appear).
• Since my (manual) edit from Oct 5 lead to have the lexeme updated in the query service, and until today only that was updated, and the situation stayed the same, I had a quickstatements job doing an edit to every lexeme, so they should all be updated in the QS as well. It seems that this has caused another extreme increase in the update delay.

Now, other users report that their instances are back to normal (query system is up to date). Not in https://lilamorph.wikibase.cloud:

• action=purge has not effect, but
• I have edited a lexeme that was not found by sparql before, that now, after the edit, does appear. All other missing lexemes still do not show up.
• But my edit does not appear in recent changes! The page works for me again, also when logged in (but does not list my last edits).

In this last table, I see two issues:

Some comments:

I have had an experiment: On May 19, I manually edited one of the properties where formatter URL did not work, and now, three days later, it does work. Another one (P20) I left unedited, and it still not works, as seen here: https://eneoli.wikibase.cloud/wiki/Item:Q276#P17, where there is a P20 qualifier in the statement.

Yes, I meant if it is possible to track the amount of sparql queries or api get actions, in order to measure the impact of a wikibase instance.

In T338255#8909023, @DL2204 wrote:

My bot has indeed created 24,007 new Latin lexemes. It uses python Wikibaseintegrator (WBI 12.0). And, indeed, the value I passed for dct:language was "wd:Q397" (as found in the source the bot used). That is my fault; I should have passed "Q397" to WBI, and not "wb:Q397". WBI accepted that and wrote it to these lexemes, which Wikidata accepted (WBI and/or Wikidata should have raised an error, since the value expected here is just a numeral preceded by a Q, I have notified the WBI developer)... I will fix that for all affected Latin lexemes.

My bot has indeed created 24,007 new Latin lexemes. It uses python Wikibaseintegrator (WBI 12.0). And, indeed, the value I passed for dct:language was "wd:Q397" (as found in the source the bot used). That is my fault; I should have passed "Q397" to WBI, and not "wb:Q397". WBI accepted that and wrote it to these lexemes, which Wikidata accepted (WBI and/or Wikidata should have raised an error, since the value expected here is just a numeral preceded by a Q, I have notified the WBI developer)... I will fix that for all affected Latin lexemes.

LiLa SPARQL endpoint is now listed at https://gerrit.wikimedia.org/r/plugins/gitiles/wikidata/query/deploy/+/master/whitelist.txt

We have now uploaded lexemes of the above described Kurdish varieties to a Wikibase instance, using ku-arab / ku-latn in all cases, while the above listed variety codes are used in the source. When transferring that data to Wikidata, we would like to use the corresponding variety code.

In one of my usecases I also want to link from wikibase entities to a wikitext page about that entity (like Wikidata sitelinks, but on the own wiki). I have checked again, and my attempt to have an externalID property (https://lexbib.elex.is/wiki/Property:P165) with formatter URL "https://lexbib.elex.is/wiki/$1", that is, with my own sitename in the regex pattern, that would link to own wikitext pages, doesn't work; it seems the formatter URL leading to the own site is not accepted, e.g. at https://lexbib.elex.is/wiki/Item:Q50#P165. So, at the moment, the only option to have ownsite-links is to write the whole url to a prop with datatype URL. Couldn't it be allowed to have the own site name in a formatter URL pattern?

This particular problem is resolved, and worked on now in general at T325894

In this error log (mwclient warnings log), 502 and 404 responses appear. 502 is very frequent, 404 not that frequent but several times a day. I don't know if the 404 problem is related to the 502 problem (T309070). The 502 problem is not new, while I never had got 404 until the last three or four days.

This is still an issue, as seen in this errorlogging (python mwclient). The scrips I have running are here.

Yes! It is there! Thanks!

Update two days later: The initial super user is still not there.

We have the same problem again on this new wikibase. The owner (wikibase account holder), in the creation dialogue, set the initial super-user name to "sinaahmadi", and now, 19 hours after creation, did not get the credentials for that, so that, at the moment, we have no "bureaucrat" super-user. Should we create that user, so that you can add them to the "bureaucrat" group? Otherwise, you can add my user to that group (user DavidL).

I have the same problem here: https://lexbib.elex.is/wiki/Special:Log/newusers , where yesterday and today new spammer users have been created, despite "accounts must be requested" option in wikibase cloud dashboard being set to "on". In Spring 2022 there was another time frame when spammers got in (that seems to have ended in April). The dashboard option was set to "on" all the time.

Hi, wonderful, my super-user now has all permissions. Many thanks. As to your question: Sorry, I cannot remember exactly (was doing several things at the same time). But yes, I believe that since the usual system message about initial super-user creation did not arrive in several hours, I tried to login directly (sign-up), and that could have lead to the account creation as normal account.

Esperimentuzko saio batean, Wikidatako identifikaitzaileak lortu ahal izan dugu, OpenRefine bitartez: Inguman Wikidata identifikatzailerik oraindik ez zuten egileak zerrendatu ditugu, eta argitalpenen kopuruan ordenatu. Zerrendaren goiko 500etik 365 Wikidatan aurkitu ditugu (screenshot openrefine:)

Yes, I am still experiencing this issue. WBI v12.0 gets 502 responses quite frequently, then waits for 60 seconds (the default in WBI), and then the edit gets through. With "quite frequently" I mean about once every 2-3 minutes, while the script is constantly editing entities (without any sleep time between edits but the few milliseconds the script needs to put together the content to edit).

Pertsonen lerrokaketa Wikidatako "INGUMA ID" eta "ORCID" bitartez egin dira (ikus lan-urratsaren deskribapena).
Lerrokaketa batzuk eskuz burutu dira.

Hi, until last week I had a writing bot running on qichwa.wikibase.cloud (see log), and yes, I still experienced the 502 response problem from time to time (something like once every 5 to 10 minutes). After the 60 seconds sleep (default in WBI), the edit always got through. After last week, I had no further edits.

Ingumako API-tik datuak hartu eta wikibasera igotzeko script hau erabiltzen dut. Apriliran 13an deskargatutako datuak igo eta gero, scriptak datu berriak hartu eta wikibase eguneratzeko balio dezan moldatuko dut. Wikibasen idazteko, WBI 0.12 erabiltzen dut.

Pertsonak, jakintza-arloak, UDC identifikatzaileak, erakundeak, aldizkariak wikibasera igota daude, eta ekoizpen gehienak ere bai (igotzen ari dira). Hasiera orrian wikibaseko edukiak ikusteko esteka batzuk daude.

Hi, I am one of the Batch A users (http://lexbib.elex.is, among others). Everything works fine, many thanks!!
Two observations:

Pertsona-itemak API-tik hartu eta wikibasera transferitu egin dira. Pertsonak ikusteko, edo orri nagusiko bilaketa-eremuan bilatu, edo galdeketa honen bitartez guztiak ikusi ("limit" kenduta, tardatu egiten du).

• Hasi naiz item bibliografikoak eta pertsonak errepresentatzeko propietateak sortzen. Ikusi sortutakoak hemen.
• Lehenengo pertsona item bat hemen dago.

We will use existing project tag Wikimedia-User-Group-Basque

In T304136#7787999, @Aklapper wrote:

@DL2204: Hi, if you want to manage and organize work for a certain project which serves the Wikimedia communities (!), please request a project tag: https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects . (Tasks should have project tags, so tasks can be found by others.) Thanks a lot! :)

Ahotsak wikibase-rako proposatzen dudana hauxe da: ETC-n agertzen diren forma guztiak hartzea, bakoitza bere analisi posibleekin batera. Forma hipotetiko guztiak hartzea ezinezkoa dela uste dut, atzizki-kateko konbinazioek multzo teorikoki amaigabea osatzen baitute.

Eguneraketa: Josu Landak ETC-ko formak, POS-ak eta agerpen-kopuruak prestatu egin ditu. Milioi bat forma dira. Hurrengo pausoa, MORFEUS-en analisia gehitzea forma bakoitzari, anlisia(k) wikibase-ko "grammatical features" gisa errepresentatu ahal izateko.

EHU Euskara Institutukoekin hitz egin dut (Josu Landa informatikoarekin, eta zuzendaritzarekin). ETC-ko formak gure wikibasean eta Wikidatan jartzearekin ados daude. Josu Landak datuak prestatuko dizkigu. Hemen bezalako forma-sortak, agerpen-kopuruak eta ETC-ko atarira daramaten idenfikatzaileak izango ditugu. Honezkero, badakidu zer forma benetan erabiltzen den (=ETC-n agertzen den), eta Wikidatan jakingo genuke zeintzuk kendu, eta zeintzuk gehitu, lexema bakoitzean. Horrekin lotutako arazo bat POS desambiguazioa da. Josuk ETC-ko POS-ak ere emango dizkigu (ETC-ko atarian POS-ak ez dira agertzen, baina barruko datu-basean bai).
Bestalde, IXA-koak (CLARIAH-EUS-etik egin dut eskaera) ETC-ko forma guzti horiek dagoeneko existitzen den MORFEUS analizatzaile morfologikotik pasatzen saiatuko dira. Horrela, wikidatako "grammatical features" izango genituzke forma bakoitzerako.

Euskalkiak wikidatan itxura hau dute: Query.

Urtzi, mila esker argibideengatik. Orain ulertzen dut API key nola pasatzen den. Python requests erabiltzen dut, moldatuko naiz. Postman ez nuen ezagutzen, ondo dago jakitea.

Laguntza behar dut Ahotsak API erabiltzen ikasteko. Aintzanek API key bat bidali zidan, baina ez naiz moldatzen. Mesedez: Ea zeinek lagun dezakeen.

Proposamena: Bot bat martxan jarriko dut, honako gauza hauek egingo dituena:

Ahotsak-eko baliokide estandarrak ETC-n aurkituko ditugu gehiagotan Wikidatan baino, atzizki bat baino gehiago dutenak batez ere. Hortik hasierako motibazioa ETC-ko datuak hartzeko.

In T286543#7208295, @Theklan wrote:

Lexema homografoak, POS berberekoak baldin badira, adiera moduan tratatzen dira. Adieran lantzen dira bi esanahiak.

Bai, hori da wikidatako irizpidea? "baso"-ren kasuan, baso1 agertzen da (oihana), eta baso2 (edalontzia) ez da agertzen. Batuko bagenitu, edalontzia eta oihana wikidata lexeme beraren azpian agertuko lirateke. Ez nuke hori egingo, baizik eta bi lexema sortu. Alemanez, homografoak honela daude islatuta: Ausdruck1 > P5402 homograph lexeme > Ausdruck2.
POS bereko homografoak lexema berean agertzea ez zait egokia iruditzen. Horrela lotuko genuke baso (izena) eta baso (izena), baina aditu (izena) eta aditu (adjektiboa) ez genituzke batuko? Azken bi horiek eskubide gehiago dute lexema bera izateko lehenengo biek baino, nire ustez.

Ez dakidana da ea nola lotu dezakegun Elhuyarreko 1 baso, 2 baso eta 3 baso adierekin, berez Elhuyarren erabilitako zenbakiak ez baitira publikoki ikusten.

Homografia-zenbakia duten Elhuyar lemak berrikusi behar dira guztiak, batzuetan oker batuta edo partzialki lotuta daude eta. Jakiterik dugu zein Elhuyar lemek homografia-zenbakia dakarten? Bestalde, ElhuyarID berbera wikidata lexema batean baino gehiagotan agertzen da (Elhuyar hiztegiko sarrerak izena eta adjektiboa tratatatzen badu). Hori ez da ideala.

In T286454#7208268, @Theklan wrote:

Nik uste bi gauza ezberdin ditugula. Alde batetik Wikidatan lexemetan aukera posible guztiak ditugu, Xuxenek egiten duen moduan. Noski, "guztiak" hori ez da posible, zuk diozun bezala, aglutinazioa dela eta posible delako deklinazio bikoitzak eta egitea, jada deklinatutako zerbait nominalizatuz.

Nik aditz-izena aditzaren sarreratik kendu eta lexema propio gisa sortuko nuke. Lotura bakarra honako hau izango litzateke:

Forma hauek dira aditz-izenak wikidatan, aditzen sarreretan: https://w.wiki/3dSG

Elhuyar hiztegi elebidunaren lemategia baneukan, eta Hiztegi Batuan 4834 lema agertzen dira, Elhuyarren agertzen ez direnak. Hemen dago zerrenda; atzizkidun formak dira ia guztiak, -te/-tze asko tartean, baina baita ere -ar, -arazi, etc. Wikidatako lexemekin froga bera egingo dut, baina zerrenda antzekoa izango dela uste dut.

P7706-ean, euskarazko adibide bat dator, eta horrelaxe ondo dagoela uste dut: