Wikipedia talk:Version 1.0 Editorial Team/Index
|
Selection bug in Wikipedia 1.0 Server
editI'm trying to use the PetScan feature to make a .zim for kiwix.
https://petscan.wmcloud.org/?psid=40642859
However, the Zim that is outputted by the openzim (https://wp1.openzim.org/#/selections/user) tool is weirdly small.
Just 40 pages, it seems, looking at the main page through kiwix.
Not sure if you can access the link to the Zim file but here it is (https://api.wp1.openzim.org/v1/builders/1778e6ef-6c81-494e-b044-d9014b257cc9/zim/latest). It's 430 KB. Any idea what might be going wrong?
Looking at the output of the PetScan, I seem to have all the pages I want, but it doesn't seem to translate properly to the Zim file.
the Zim downloader seems to be getting confused, downloading the pages without the Template: or Help: namespace prefix in the url (eg: instead of downloading https://en.wikisource.org/wiki/Template:Barnaby_Rudge, it downloads from https://en.wikisource.org/wiki/Barnaby_Rudge) SkylightPenguin (talk) 09:31, 23 November 2025 (UTC)
- Hi, I'm not the best authority on ZIM files or the ZIM format, even though I'm the developer/maintainer of the WP 1.0 website. One thing I've seen happen before is that your ZIM has all the articles, but the "index" page it generates is missing them. I believe there is separate logic for generating the index/main page of the ZIM. Try searching for articles that you expect to exist, or accessing them from links in articles you can see.
- I also don't know for sure, but I think Wikipedia ZIMs usually only contain articles from the "main" (unprefixed) namespace. I don't think you can add articles from "Template:" or "Help:".
- What do you think @Kelson? audiodude (talk) 17:05, 5 December 2025 (UTC)
- I believe to have understood the problem. This PetScan selection returns almost only pages which are not in the main namespace. Per default the scraper MWoffliner will ignore the pages which are not in the main namespace. That probably explains why most of the entries returned by PetScan are not in the ZIM file. Now, the big question is: is this a bug or a feature? I have open an issue to discuss the topic at https://github.com/openzim/mwoffliner/issues/2584 Kelson (talk) 17:50, 5 December 2025 (UTC)
- There is no limitation in mwoffliner in terms of namespace when used with a list of articles, which is what is used by WP1, so your explanation is wrong. Limitation is only when mwoffliner is ran without any selection (processing only namespace 0) or with only additional namespaces (processing only namespace 0 and these additional namespaces) ; this is a non-relevant situation for WP1.
- The selection built by WP1 for the given run is at https://api.wp1.openzim.org/v1/builders/1778e6ef-6c81-494e-b044-d9014b257cc9/selection/latest.tsv
- You will easily notice that it does not contains correctly the namespace in article names, e.g. Template:Copyvio is listed as Copyvio (instead of Template:Copyvio). mwoffliner needs the whole article title with namespace, otherwise there is no chance it will find the article without a significant risk of ambiguity.
- This is a bug which needs to be fixed in WP1. B-root (talk) 14:49, 7 December 2025 (UTC)
- Note that https://petscan.wmcloud.org/?psid=40642859&format=plain gives the correct TSV to be used by mwoffliner. B-root (talk) 14:51, 7 December 2025 (UTC)
- Thanks for this information. I can confirm that the bug is in WP1. I created a selection with that Petscan URL and I got: https://api.wp1.openzim.org/v1/builders/ad004cc0-9fd2-471d-a318-da25c0bb35b1/selection/latest.tsv
- Which is missing the namespace prefixes. audiodude (talk) 01:18, 8 December 2025 (UTC)
- I believe to have understood the problem. This PetScan selection returns almost only pages which are not in the main namespace. Per default the scraper MWoffliner will ignore the pages which are not in the main namespace. That probably explains why most of the entries returned by PetScan are not in the ZIM file. Now, the big question is: is this a bug or a feature? I have open an issue to discuss the topic at https://github.com/openzim/mwoffliner/issues/2584 Kelson (talk) 17:50, 5 December 2025 (UTC)
- @SkylightPenguin: Okay this has been fixed in https://github.com/openzim/wp1/pull/1046. Try creating a new selection with the same Petscan URL and your ZIM should work! Thanks for reporting this. audiodude (talk) 02:31, 8 December 2025 (UTC)
- Thanks so much for pulling so quickly. However, when attempting to update my ZIM file, I’m met with this error
- The following errors occurred:
- Error creating or updating schedule for ZIM file creation
- 409 Client Error: Conflict for url: https://api.farm.zimit.kiwix.org/v2/schedules
- SkylightPenguin (talk) 15:49, 11 December 2025 (UTC)
- Oh nevermind. It seems to work when I make a new selection. Will update in a bit. SkylightPenguin (talk) 15:52, 11 December 2025 (UTC)
WikiProject Australia hasn't been updated by bot today or yesterday
editHi all, can anyone work out why Wikipedia:Version 1.0 Editorial Team/Australia articles by quality log and User:WP 1.0 bot/Tables/Project/Australia haven't been updated during the past 2 days bot runs? I did a manual update last night, which worked. The-Pope (talk) 05:34, 5 December 2025 (UTC)
- Not sure. The bot is definitely running and updating a large number of tables and logs. If the manual update worked, then the automatic updates should be working, because they invoke the same code. Sometimes, if there's no new information, the bot will attempt to update a page and MediaWiki will simply ignore the update because it's the same content. That leads to what looks like "gaps" in the page being updated.
- My advice is to just keep an eye on it for the next couple of days and report back here if there's more problems. Thanks! audiodude (talk) 17:10, 5 December 2025 (UTC)
- It worked fine today. Bot must have got tired from all my changes. The-Pope (talk) 02:36, 6 December 2025 (UTC)
WikiWork ω/Ω not updating since November 2025
editThe project tables are updating, but WikiWork factors are frozen. User:WP 1.0 bot/WikiWork/ww and /om were last edited 17 Nov 2025, so ω/Ω in project tables (e.g. Lichen task force) haven't changed since then. Could the job that regenerates those WikiWork lookup pages be restarted or fixed? Esculenta (talk) 03:13, 14 January 2026 (UTC)
Bot stopped working 5 days ago
editUser:Audiodude, User:Kelson: the bot has done nothing since 2 March. Nurg (talk) 04:53, 7 March 2026 (UTC)
- Good catch! Looks like they finally finished the <code>categorylinks</code> table migration. I'm working on a fix now and will update this discussion. audiodude (talk) 16:26, 8 March 2026 (UTC)
- Okay I've submitted and deployed https://github.com/openzim/wp1/pull/1112. It should run tonight. audiodude (talk) 17:33, 8 March 2026 (UTC)