It would be even better if there was a proper transaction support so that things could be written entirely or none at all: this way the upload could be retried from beginning instead of leaving it in a half-completed state.

Example of error message: pywikibot.exceptions.APIError: lockmanager-fail-conflict: Could not acquire lock. Somebody else is doing something to this file.

Working checkout of github's pull requests would be something like this:
git checkout -b <remote branch> main
git pull git@github.com:<user>/PendingChangesBot-ng.git <branch>

Apparently bitbucket uses slash instead of dash in pull request naming? (such as pr/101)
The dash-format does not seem to be working (maybe github deleted those branches after merging?)
The way github manages pull requests does not seem to be visible to real git tool, only github's own gh cli..

Also there might need to be initial pull (fetch+merge) at the start

Steps 3 and 4 could be before 2 (Fetch the pull request) since they only need to be done once.

In T335428#10941968, @Aklapper wrote:

@Ipr1 Removing task assignee as this open task has been assigned for more than two years - See the email sent on 2025-05-22.
Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome!
If this task has been resolved in the meantime, or should not be worked on by anybody ("declined"), please update its task status via "Add Action… 🡒 Change Status".
Also see https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator. Thanks!

May need to start using Wikidata lexemes instead of adding code to modules for correct cases?

In T396822#10911701, @Bugreporter2 wrote:

Arvoisat käyttäjät,

Pyydämme ystävällisesti kirjoittamaan MediaWikin Phabricatorin tiketit englanniksi. Tämä johtuu siitä, että kukaan ei puhu suomea, ja suomi on englannista hyvin erilainen kieli, mikä tekee ymmärtämisestä vaikeaa. Kiitos ymmärryksestänne ja yhteistyöstänne!

• uusi moduuli lisätty
• käytössä viitemoduuleista
• korvaukset työn alla
• lokalisointi työn alla
• erillisten symbolimallineiden muunnosta ei ole aloitettu

yhdistetty palstamallineet, korvattu monta palstaa -mallineen toteutus uudella, joka mahdollistaa siirtymisen kun näytöllä ei ole riittävästi palstatilaa.

Lisätty moduuli Moduuli:Tienumero, muunnettu tienumeromallineet käyttämään moduulia.

Tunniste-kenttään merkittyjä ISBN-tunnisteita oli noin 14 000 kappletta, taikalinkkejä käyttäviä artikkeleita oli jossakin vaiheessa 26 096 kappletta (helmikuu 2025).

Myös virheelliset ISBN-tunnisteet korjattava: tarkistusnumero puuttuu, virheelliset välimerkit, numerot vaihtaneet paikkaa tai väärä numero jossakin kohdassa.

Muutokset tehty bottiskriptin avulla jäljellä olleisiin.

With the recent update there are other problems noticed that pages are not updating correctly after changes.
Again, could you rollback the changes?

Could you rollback to previous version if there is no fix available soon?

Phash does not generate reliable hashes. File uploaded from Finna to Commons does not match.

There is alternative library called PyLibTiff which uses the libtiff library. This might give better results (testing).
pylibtiff has a mismatch somewhere and simply does not work currenly:

See also other related bug reports resulting from pillow:
https://phabricator.wikimedia.org/T354147
https://phabricator.wikimedia.org/T352942

result from example: pywikibot.exceptions.APIError: modification-failed: Malformed input: +2023-08-27T05:48:00Z
messages: [{'name': 'wikibase-validator-malformed-value', 'parameters': ['+2023-08-27T05:48:00Z'], 'html': {'*': 'Malformed input: +2023-08-27T05:48:00Z'}}];
servedby: mw2285;

jpeg-version uses 8-bit integer rgb/alpha, while tiff uses 16-bit integer grayscale.
visually checking the jpeg-version seems to have more "noise" in the image (worse compression).

Phash diff: 30, image1: 94dbac9b8ac4c2cb, image2: 87f807f00ff007f8
Dhash diff: 26, image1: 701844a8a9a4a6a6, image2: 0000000000000040

datasetti:
https://zenodo.org/records/10408884

koordinaatit muutettava gps-koordinaateiksi, formaatti on nyt ETRS-TM35FIN

muita aikamuotoja:
pp.-pp.kk.vvvv

Kansallisgallerian api:sta saa objects-listauksen (max. 200) ilman autentikaatiota, haku id:n mukaan vaatii authentication tokenin, joka on nykyään Githubin autentikointitoken (jossa siis 2FA).

Kansallisgallerian kuville Commonsissa näyttää järjestään olevan lähteet "references" -kentässä, jonka sisältö tulee wikidatan propertyistä. eli urlit ja lähdetiedot eivät ole suoraan commonsissa. Commonsin dokumentaation mukaan käytettyjä propertyjä ovat mm. catalog code (P528), described at URL (P973), described by source (P1343)

Some images with "L" band are converted fine while others are not. So that isn't a reliable method of checking either.

And like I've said before, listing claims is not the issue, it is trying to make the server accept it as modification instead of new entry.

those I've already got:
wikidata_site = pywikibot.Site("wikidata", "wikidata")
commonssite = pywikibot.Site("commons", "commons")
for page in pages:
filepage = pywikibot.FilePage(page)
wditem = page.data_item()

sdcdata = wditem.get() # all the properties in json-format
claims = sdcdata['statements']  # claims are just one step from dataproperties down

Example case: for file File:Vilho Penttilä, Kansallis-Osake-Pankin talo, Kauppakatu 4, Tampere.jpg, get TIFF-image from finna.fi for musketti.M012:HK19700502:98.

List of types given by pillow documented here:
https://pillow.readthedocs.io/en/stable/handbook/concepts.html

FYI: pywikibot needs fixing, it doesn't work with commons sdc-data

jos tuon itemin yrittää ohittaa niin sitten tulee virhettä:
ValueError: Q23040125 is not type <class 'pywikibot.page._wikibase.ItemPage'>.

page already has claims:
claim P275
claim P6216
claim P571
claim P7482
claim P9478

does not work in commons:

Joo, ei nuo muut varoitukset sinänsä ole kovin ihmeellisiä kun ne tulee jos jokin muu arvo puuttuu. Tuo viimeinen lähinnä mietityttää:
" ID should not be used on this type of entity, the only valid entity type is Wikibase item. "
Eli onko propertyn määrityksessä jotain vikaa kun se herjaa structured datassa käytöstä?

P9834 käytöstä commonsin structured datassa näyttää tulevan kuitenkin herjaa:
item-requires-statement constraintHelp Discuss
An entity with Finnish National Gallery artwork ID should also have a statement location.

Wikidatassa on property Kansallisgallerian teostunniste (P9834), jota on käytetty esimerkiksi teoksen Haavoittunut enkeli (Q471289) kohdalla.

Kaikki kuvat ovat siis CC0 ja rajapinta palauttaa julkisesti saatavilla olevat. Tiedoissa voi olla mukana ID:tä, joiden kohteet eivät ole saatavilla.

Kansallisgalleriasta saa ladattua jsonin, jossa on kaikk(?) esineet. Tuo on parisataa megatavua, mutta siinä toistuu samoja asioita jokaisen esineen kohdalla kuten taiteilijan syntymävuosi. Varmaankin ajatuksena ollut että helpompi käsitellä noin? (78784 objectID:tä dumpissa eli varmaankin tuon verran julkisesti saatavia olevia tietoja?)