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:

Igo ziren hitzak Elhuyarren ikasleen hiztegitik igo ziren, beraz baliteke egotea beste lexema batzuk ohikoak direnak eta hiztegi horretan ez daudenak. Hau da, ez ditugu berez Euskaltzaindiaren hiztegian agertzen diren hitz guztiak.

Nik badaukat 2010ko Hiztegi Batua (adiera gabekoa) XML-n, garai batean Euskaltzaindiaren webgunean deskargatzeko zegoena. Begiratuko dut ea horko lemaren bat ez dagoen wikidatan.

Bestetik, aditz forma nominalizatuen afera dago: euskaraz ia edozein aditz bilaka daiteke izen eta berriro ere deklinatu. Euskaltzaindiaren hiztegian ez da agertzen antolatuta, bai ordea antolatu. Antolatuta edo antolatutakoaren, antolatu aditzaren forma nominalizatuaren aldaerak dira, eta, beraz, beste POS bat izan beharko lukete Wikidatan, "antolatu" moduan, eta hori lotu "antolatu" aditzarekin.

• "antolatu" partizipioa da, eta beraz, aditz forma, bai. Baina aditz formik ez du (aditz sintetikoa ez baita). Forma ia guztiak izenkienak bezalaxe deklinatzen dira ("adituko", "aditze" eta "aditzen" salbu). Bestetik, adjektiboen formak izenen formen berdinak dira, eta wikidatan bi aldiz agertzen dira horregatik, modu erredundantean. Ahotsak-en eta ETC-n, POS bereizketa ez dute egiten (hain zuzen horregatik).
• Wikidatak lexema bati POS bakarra jartzera behartzen du... Baina "aditu" izena, "aditu" aditza, eta "aditu" adjektiboa, ez al dira lexema bera, forma berdinak badituzte, gainera?? POS da lexema batek egitura sintaktikoan (esaldian) hartzen duen rol bat. Hiztegian adierazi behar bada, adierengatik eta itzulpen-ordainengatik da ("aditu" izenak eta "aditu" adjektiboak ez dute adiera-deskripzio berdina ezta itzulpen berdina ere).
• datuak.ahotsak.eus-en, ez dugu adierarik jartzen, hau da, POS bereizteko premiarik ez dago. Eta ezin da bereizi, gainera, ahotsak eta ETC-n ere bereizten ez baitira. Gauzak Wikidatara pasatzean, edo wikidatarekin lotzean, gure lexema (edo forma) bat baino gehiago lotuko da wikidatako entitate berera, Elhuyar hiztegi ID zenbakiekin gertatzen den bezalaxe (adjektiboa eta izena ID berera doaz).

Bizidun formak esplizituko "bizidun" markatzea komeni dela uste dut. "bizigabe", aldiz, default moduan ikusten dut, eta ez dut adierazteko behar bera ikusten. Lexema batek entitate biziduna adieraz dezakeen jakiterik balego, horren arabera sor ditzakegu formak (aulki bat ez dela biziduna jakingo bagenu, "aulkiarengandik" ez genuke sortuko). Agian badago bide bat hori jakiteko. (Erabilera arau-apurtzaile edo poetikoak kanpoan geratuko lirateke). - Forma dokumentatuak soilik jasoko bagenitu, auzi hori horrekin batera konponduko litzake, eta erabilera poetikoak ere jaso ahalko lirateke...

Bai, oinarrizko galdera litzake (a) forma posible guztiak (aulkiarengandik bezalakoak) nahi ditugun, edo (b) inon agertzen diren formak, hau da, forma dokumentatuak. Ahotsak-ekoak dokumentatuak dira guztiak, baita ETC-koak ere.

Bai, nik ere konpondu nuen horrelako bat, merge items erabiliz. Halakorik topatuz gero, horrela egingo dut.

Aditz izena -te/-tze delakoaren alde nago. -a kentzeko ez dut arazorik ikusten, bot bat idatzi ahal dut.

API dokumentazioaren orrian, ez dut lortzen login egitea, "basic authentication" bitartez API frogatu ahal izateko. username eta password badaukat, baina ez nau onartzen.

Argibideak topatu ditut: https://ahotsak.eus/api/v2/dokumentazioa/.
Hor ez dut ikusten aldaerak eta formak nola hartu, horregatik html-etatik hartu ditut. Idazten ari naiz, Euskara Batuko lemak (adibidea) aldaeretara (adibidea) loturak ditu.

Wikidatako lexemak hemendik hartuko ditut: SPARQL. Goian zerrendatuko POS-etakoak baino ez dut hartuko.