BaGLAMa2 has been collecting view data for Wikipedia pages that contain image from a Commons category tree since March 2010. If your organisation “donated” images, audio, or video to Commons, this kind of data gives highly valuable feedback. Look, out images were viewed 20 million times on Wikipedia last month! There are over 1200 category tree “roots” in the database already. However, this tool has had problems for a long time now, which started with Toolforge moving from grid computing to k8s. The initial version of the tool was written in PHP, and a single grid job would process one category tree and generate a TSV file. Later, I changed that to write all data directly to MySQL, resulting in a 20GB database, which did not scale well. Then I changed it back to storing the main data in files, sqlite3 this time. Meanwhile, the old TSV format and the MySQL data were both kept and supported. However, the k8s switch made the one-script-one-category approach impossible, and so I rewrote the tool in Rust, to run one single job To Rule Them All™. This worked in principle, but database connections and pageview API requests both did not scale well. I then tried a new, more efficient MySQL table approach, which also never took off. Sadly, BaGLAMa2 was stuck in a broken state for years. Now, I tried a new, radically different approach (while staying in Rust, building on existing code). First, I (and my useful slop generator) designed a new, bespoke, and highly optimized format to store results. As before, one file would keep the wiki sites, pages, images, and view counts for one category tree, for one month. However, where the dataset for a whole month would use something like 16GB (sqlite3 files, October 2022), the new format uses ~0.5GB in total for a month. Then, I switched from using the pageview API, to reading the pageview data dump, which is conveniently available on the file system on Toolforge. All site/image/page data gets prepared in advance, which takes ~1h. Then, the compressed pageview dump file is read in its entirety, keeping the relevant view counts, which takes another 15 minutes. In contrast, the previous PHP or Rust processing took several days, and usually left some failed groups for re-run behind. I have already back-filled July, August, and September of 2026. I have also converted all TSV and sqlite3 files to the new format. This has now saved almost half a TB of disk space on Toolforge. I will also convert the MySQL datasets into that format, to be able to retire the backwards-compatible reading (and writing!) code, and reduce the database size from 20GB to almost nothing. The total disk space for storing all BaGLAMa2 data will then be <35GB, with 0.5GB added every month. At this speed, it will take many decades to again occupy the space it did a few days ago, in the old formats. Last not least, the new code will run automatically on the 3rd of each month, processing the pageview data from the previous month.

Harvest Templates by User:Pasleim has been a key tool for synchronizing data between Wikipedia templates and Wikidata. However, Pasleim stopped updating the tool in 2021, and issues have been piling up since. So I (and my not-so-trusted slop generator) set out to Do The Thing: _Rewrite it in Rust_. And while at it, fix the issues that had accumulated. And implement the feature requests. The rewrite it now live at **harvesttemplates.toolforge.org**, the source is on github (since Codeberg frowns at code that wasn’t written in the One Proper Way). Some highlights: * The “harvests” now run on the server, not in the browser, so they keep running in the background, can be paused, restarted, etc. * Much of what used to be API queries that would timeout is now done via the database replicas, so no more hanging “Loading…”, and huge queries work fine (though they can take a minute) * Editing will not add statements twice, which was a much-bemoaned issue. Also, HT now checks by default if that statement was ever removed before, and won’t add it again. Each row gets its own edit status, and won’t fail the batch. You can also preview edits as a dry run. * Now supporting qualifiers, coordinates, numbers with units, combining several parameters, values from nested templates, multiple properties per run, as well as PetScan, SPARQL, and instance-of filters * Your old permalinks, and the shares queries, have been ported to the new DB, so they will still work (when adjusted for the new URL path) So, if you liked the original Harvest Templates, or got curious and want to try it out (there is a help page, and some examples), I hope you’ll give the new version a whirl.

The breach links the names and photos of millions of people across North America. One expert said this is likely the largest database of facial images ever breached.

Every article is a room, every hyperlink a doorway. Wander Wikipedia as an endless museum - or race friends through it.

There is a clear _no_ to LLM-generated content on Wikimedia projects, which is a good thing IMO. On the other hand, I found that LLM-assisted coding helps me significantly in Getting Things Done as a volunteer, that would otherwise turn tools into bitrot graveyards over time. Given that LLMs can be useful for some tasks, I thought about an application for Wikimedia projects outside content writing and coding. Many people write Wikipedia articles, but most do so in one or two languages.And, unless yours is a smaller language Wikipedia, one might not often read other language editions while writing. Wikipedia language editions are independent, so besides core information, they tend to focus on slightly different aspects of a subject. But what if they disagree on information? One of them might be outdated, or factually wrong. Even if both are correct, in their own way, seeing a conflict might lead to better writing, on both sides. And it would be essential to discover deliberately false information, on a Wikipedia taken over by compromised admins, as it has happened. It would also be beneficial to consider aspects and approaches on one Wikipedia edition in another; it might lead to a better article. That is not to say that all editions must say the same, but _how do others do this_ is a classic source of learning, understanding, and improving, both your work and yourself. So I asked Claude Opus to compare the language editions of a Wikipedia article. I picked the English, German, and French editions of Kassel, a city in Germany, as an uncontested topic. I told Claude to look for contradictions and important information missing in some editions. I also told it to produce a JSON file, and a human-readable table (below). I believe even this little comparison is informative, and helpful for editors. Using more languages, and taking Wikidata into account, would make this even better. Of course, scaling up is not (financially) feasible with the commercially available LLMs. An open, capable LLM (e.g. Qwen series), ideally hosted on Wikimedia servers, would allow such comparisons, and other wiki-related tasks, for various tools. I am not talking about hosting a publicly accessible LLM, I am thinking of a back-end service for Wikimedia services, Toolforge, etc. It could be limited to access only Wikimedia sites, to avoid adding scraper stress to other websites. Either way, I believe there is potential in using LLMs to assist Wikipedia editors, if not the editing. ## Claude comparison of Kassel, acrosss en, de, fr | English | German | French ---|---|---|--- Title | Kassel | Kassel | Cassel (Hesse) Depth | Medium | Very high (reference version) | Low–medium Character | Strongest on dynastic history, WWII bombing, Anglosphere threads; stalest on present-day facts | Deepest on geography, administration, religion, economy, local culture | Declared partial translation of an old German revision — inherits German framing without German updates, but adds substantial French-perspective content ### Core facts side by side Field | English | German | French | Verdict ---|---|---|---|--- Population | 201,048 (Dec 2020) in lead; 197,230 (2024) in table | 197,230 (31 Dec 2024, state statistics); city’s own figure 207,863 | 200,406 body / 204,687 infobox | Conflict Area | 107 km² | 106.798 km² | 106.78 km² | Agree Elevation | 167 m (single value) | 132.9 m lowest to 614.8 m at Hohes Gras | 132.9 m to 614.8 m | Complementary Cassel → Kassel | 1926 | 1926 in lead, “seit 1927” in history | 1926 | Conflict (internal to DE) Etymology | Several unproven assumptions | Recent onomastics favours Germanic kas- + -sella | Asserts Castellum Cattorum as fact | Conflict City rights | 1189 deed certifies them; grant date unknown | Before 1189; renewed 1239 by Hermann II | Before 1189, renewed 1239 | Complementary Westphalia capital | 1807 | Occupied 1806, capital to 1813 | Capital from 1806 | Conflict Worst air raid | 90% of downtown, ~10,000 dead, 150,000 homeless; no date in body | 22 Oct 1943, over 10,000 dead, 80% of housing | Over 10,000 dead, over 80% of houses | Conflict (scope) documenta | Every five years since 1955; latest 2022 | Irregular at first, five-year cycle since 1972; text still ends at documenta 14 (2017) | Five-yearly, 100 days, city-wide; 15th in 2022 | Conflict University | 25,000 (2018) in lead; ~21,000 (2026) in body | 23,699 (WS 2021/22); earlier university 1633–1653 | ~25,000 (2018) | Conflict Fridericianum | “Europe’s first public museum” | First public museum building on the European continent | “One of the oldest public museums in Europe” | Conflict (claim strength) Ice hockey | Huskies dissolved 2010, successor in 5th tier | Restarted, promoted to DEL2 in 2014 | — | Conflict (EN stale) İzmit twinning | not captured | 2000 | 1999 | Conflict ### Sharpest contradictions # | Issue | Assessment ---|---|--- C1 | Population spread of ~10,600 across editions | Not a factual dispute but an undeclared definitional one: census-adjusted state statistics vs. the municipal residents register. Only German tells the reader both exist. C3 | English geography section places Hesse in “the south-western part of Germany” | Flatly wrong, and contradicts English’s own lead (“central Germany”) and the German/French statement that Kassel is about 70 km north-west of Germany’s geographic centre. C2 | Fama Fraternitatis: 1617 (EN) vs 1614 (FR) | 1614 is the standard dating of the first printing; English looks like an error. C5 | Student numbers | Real enrolment decline reported at three vintages, plus an English lead never reconciled with its own body. C13 | Scheidemann as mayor: “1920 bis 1925” in prose vs. 1919–1925 in the mayors list | Internal German inconsistency. C15 | English still lists Bombardier as a local employer | Absorbed by Alstom in 2021; German notes Alstom on the site. ### Substantive content in one edition only Topic | Only in | Why it matters ---|---|--- WWI POW camp at Niederzwehren: built for 20,000, extended to 30,000, and a 1915 typhus epidemic in which a French army doctor estimated roughly 12,000 of 19,000 prisoners infected and 2,300 dead by end of June — 1,600 French, 700 Russian; other sources say 3,000 | FR | The largest unique block anywhere. Absent from German entirely. Hesse-Kassel selling Hessian soldiers to Britain to suppress the American Revolution, financing palaces and the landgrave’s lifestyle | EN | Central to 18th-century city finances; missing from German. SA and SS in civilian clothes wrecking the synagogue on 7 November 1938 to fake spontaneous anger, two days before the national pogrom; 2,301 Jews in 1933, ~300 refounding the community, ~1,300 by 2006, new synagogue opened 28 May 2000 | DE | English says only that “in the late 1930s, Nazis destroyed the Kassel Synagogue” and nothing about afterwards. GDP of €9.914bn (2016), €49,937 per capita against €43,496 for Hesse; unemployment 10.2% (2011) → 6.7% (Dec 2018); city entered Hesse’s municipal rescue scheme in 2012 and left in 2016 | DE | English offers one unsourced sentence about halved unemployment. Treppenstraße (1953) as West Germany’s first pedestrian street; first German city to introduce the parking disc (1961); reconstruction following plans drawn up under the Nazi regime | DE | The reconstruction-plan provenance is a real historical point, not trivia. First German observatory (1558); documenta 6 making Kassel the first city lit by laser at night (1977) | EN | — Napoleon III imprisoned at Wilhelmshöhe after Sedan; Hindenburg and Ludendorff preparing the capitulation there in 1918; Brandt–Stoph inter-German talks in 1970 | EN | French omits the imprisonment of a French emperor while detailing French POWs. Kasselänerisch dialect; the Kasseler / Kasselaner / Kasseläner distinction; and that the cured pork called Kasseler is not from Kassel but named after a Berlin butcher named Cassel | DE | Exactly what a non-German reader would want and won’t find in English. Kassel’s boundaries unchanged since 1936, because the 1970s Hessian reform brought no incorporations | DE | Makes the population series directly comparable over time, unlike most German cities. German Rugby Federation founded in Kassel in 1900; first German water-ski club 1949 and federation 1958; MT Melsungen playing Bundesliga handball in the Rothenbach-Halle | DE | English covers only football and ice hockey. Brothers Grimm resident 1805–1830 as court librarians; Druselturm dated to 1415; 1923 Esperanto congress under Einstein’s honorary presidency | FR | The Einstein item is unsourced in French.

_tldr: the live version is here:https://curl.se/perf/_ How fast is “fast” and is it good enough? Does it run as fast now as it did before or was there a regression? What exactly needs to be fast? How fast is it? These are questions that many projects and products face, and in curl we are no different. Yet, performance testing and comparisons are _hard_ and full of landmines and time-wasting efforts. For many years we have occasionally brought up the idea of a performance test suite for curl only to shut it down again because the challenges seemed hard and no one was volunteering to do this. This week it changed. ## Let’s do this I started out trying to find existing projects that host performance results for Open Source projects so that we could just feed our results something else and get great visualizations and data management. I did not find any such. I then took a look at what existing tools there are for this purpose, and most pointers seemed to suggest that Grafana is a popular and maybe even a good solution to build something like this with. But man, that is a complicated machine and it felt more than a little overwhelming just figure out where or how to start with it. I decided to postpone that take as well. ## Let _me_ do this I decided that instead of trying to do this the best and optimal way – I shouldn’t let perfect be the enemy of good – I would start out by doing the things I know how to do and take it as far as I can one step at a time. _Something should be better than nothing_. Performance testing needs decently stable system conditions so that repeated runs produce reasonably similar results, when all involved factors remain identical. This is basically impossibly to accomplish using most cloud infrastructure since those are almost always shared with countless other users. At least on the cheap and free tiers we use. We probably need our own dedicated hardware for this, but instead of trying to figure out where to get that and arrange for that, I would start by running performance tests on my own local development machine. I am a single user on this and it has many cores and runs decently fast. It should be good enough to get this going on. I created a first shell script that updates the curl source code from git, it configures and builds it. Then it runs a bunch of tests, outputs a bunch of data and logs all the output in a single log file. I started out with a few simple tests. How fast does curl download a 100 GB file from localhost, how many allocations and how big allocations does it need for a single HTTP download? My second script parses all the test log files from the previous builds and generates summaries and graphs for them. To make it possible for humans to see how the performance changes between builds and ideally to automatically detect when something changes more than what should be tolerated. As I am a graph addict already since before, and that journey has taught me a little gnuplot, I decided that even while there probably are much better tools and fancy JavaScript things that _could_ be used, I don’t know them and learning them now is an endeavor I rather avoid. So I stick to what I know and can get results with quickly. I third script is invoked from a crontab every twenty minutes, sets up some variables and invokes the runner script. Once the basics started to work, I showed my curl friends the early versions and I soon created a new git repository for the code. ## It’s live baby After a little more poking, I soon made my locally produced performance test summary get packaged and automatically transferred to the curl website after each build, and voila, the first public curl performance tests were live and public. Getting this data available immediate triggered curl developers. It only took hours until we had the first proposed changes to improve some numbers, and soon we had a few merges to that affect. Visibility really helps! The performance numbers we get are still varying to a certain degree, partially of course because I still use my machine for my daily development things, but also because most of them do real (localhost) networking and that is by its nature a little… _varying_. The system builds and runs a new round every twenty minutes and it does that using the latest commits from git. This setup makes it sometimes run many rounds on the same commit and it might also mean that it sometimes updates and get several new commits at once, so it might skip a round for some commits. I might reconsider this design later, but since it is still a twenty minute time window, the number of commits is still limited. When the script makes multiple build rounds on the same commit, it accumulates the numbers and for the graph it stores the maximum, the median and the minimum value. It helps show the variation per commit and allows us to cram more into the graphs. It is still early days, but there will be a maximum limit to how many commits that can be displayed in a single graph and still be helpful. HTTP/2 parallel download speed through 31 build rounds ## Distribution To help visualize the distribution and data spread per test, I created a separate illustration that shows the Minimum, maximum, P25, P75, Medium and Mean values in a _Box-and-Whisker Plot_. A Box-and-Whisker Plot showing the HTTP/2 parallel download speed data distribution. ## Changing conditions An obvious downside with me just storing build logs in files, is that it will not scale up to the millions. I did however decide that I’m not designing this system for that. At least not now. Performance tests are highly specific and dependent on the exact machine it runs on, the exact third party libraries and their versions that are used, the other components involved in the tests, such as the servers, and more. I expect that we will change conditions for the tests every once in a while that makes it hard to compare the current numbers with past numbers or at last hard to do much about the differences. Therefore I think the performance test numbers and values are primarily useful in the short term. To help us spot if we land something that subtly and _unintentionally_ degrades something. ## Stakes To detect extremely slow and long-term changes in performance and even making sure we can better survive wiping all the existing build logs etc, I introduced a concept I call _stakes_. As in a stake pole. A marker. An arbitrary threshold set manually for each specific test. This value can be used to measure performance test results against, now and later. As conditions change and maybe something makes the results go up or down and we are fine with those changes because they are motivated and expected, then we just change the stakes. If it works out, I might the system automatically detect and maybe highlight tests that deviate too much from its set stake (at least if done in the _wrong_ direction) . It could be a signal that something bad was merged. ## Balances As with everything in life, things are often balanced out. We already ran into this when we eagerly merged several changes to reduce the number of allocations to do a single HTTP download, only to realize that one of the optimizations we did had the side effect that it expanded the size one of the main structs. Changes in one area might come at an expense in another. With sufficient tests and data we can improve curl for users, and at the same time make sure that our improvements don’t come with a cost we are not prepared to pay. Exactly how to make the balance is of course a question we need to deal with, discuss and decide. Possibly for whatever change we do. ## The tests As I write this, we have 24 tests and a full test round completes in about six minutes on my machine. We can of course do multiple builds using different hardware, different operating systems, different build options, different third party libraries and different test servers to check more angles of performance, and I am certainly open for and prepared to do that going forward. I will however first let this single-flavor run for a while so that we get more data, get a change to tweak it and make it as usable as possible for curl developers. As with everything there is no end to what we _can_ make this do. This is a start. I sure we can take it further as we move along. In particular if people join in and help out. Both with ideas and proposals for visualizations, graphs and new tests to add, but also with actual pull-requests and code. ## Build volumes and graphs Over the last year, we have merged, on average, about 10 commits per day. If we keep this pace up and this performance test setup can show 100 commits conveniently into a single graph, that is just ten days of development. Probably not enough. Once we reach one hundred builds or so in the first graphs I need to consider adding separate _long term_ graphs that use select data-points to display data development over a longer time. Some googling told me the Largest-Triangle-Three-Buckets, or LTTB for short, is a fine algorithm to use for this. I now do a separate “long term” graph that “downsamples” the full range down to something that can be shown in a reasonable way. I suppose we will see properly in the future how this works. ## Spotting change The _stake_ thing I mentioned is one way to help us spot gradual performance changes over time. Another googling told me that there’s a _Mann-Kendall Test + Sen’s Slope_ algorithm to use to identify trends in graphs like this and it can be used to plot a trend. It might work as a helper to better identify… yeah, the data _trend_ for each test. The HTTP/2 parallel download speed trend at a specific moment ## Developing This setup has only existed for a few days. There is lots to do, lots to learn and much more to experiment with. Your comments, help and pull-requests will be appreciated!

A Rust implementation of a Wikibase REST API client - magnusmanske/wikibase_rest_api

Rewrite of the PHP geohack in Rust. Contribute to magnusmanske/geohack development by creating an account on GitHub.

A brief comment on Codeberg’s new terms, and why a free-software host deciding which projects are welcome worries me more than the bans themselves.

Comments

A brief update on Mix’n’match. When you are logged in, you can reach your “user page” in Mix’n’Match through the user icon in the top navbar. On that page, you will now find a link to “Settings”. The first setting (besides dark mode) there is a configuration of the search buttons on unmatched lists of entries. This doesn’t sound like much, but I found that looking for an entry in a bespoke search engine, or in the Mix’n’Match “creation candidates”, is very helpful.

**The curl project will not accept or otherwise handle any vulnerability reports during the month of July 2026**. We call it the _curl summer of bliss_. curl’s submission form on Hackerone will be paused starting July 1, 2026. Summer of bliss starts: **July 1, 2026**. 00:00 CEST Submissions resume: **August 3 2026**. 09:00 CEST The security email address will also be a dead end, as we will not process or otherwise care about security or vulnerability reports sent to us that way either. Whatever issue you find that you feel a need to report to the curl project during this month has to wait. curl’s Hackerone form opens for submissions again on Monday August 3. We do not accept vulnerability reports over email in general, and this fact remains during and after our vacation. ## Vacation for real The curl maintainers will use this time of less pressure to take in some extra air and to enjoy the summer. Maybe stroll outside a bit more. Breath. Some of us may spend some of this time to see other places. We may get some extra time to spend on fixing bugs or working on new code. Fun stuff! ## Side-effects As a direct side-effect of this summer of bliss, to allow us some more time to handle the issues that might have piled up for us in early August, **we also push the release date** of 8.22.0 two weeks into the future. Now scheduled to happen on September 2, 2026. ## Vulnerability rate As previously mentioned, we have been under a huge pressure for the last four months or so. Now we need some rest. We do not expect this deluge to be over. ## GitHub curl’s issue and pull-request trackers on GitHub remain open and active like normal. ## You too? If you and your Open Source projects also want to participate in the summer of bliss 2026: just do it and let us know! I would of course encourage you to do so. To take care of yourself as a top priority. ## The bad guys won’t rest Probably not. But we will. ## But what if there is an emergency Then we get to read about it in August. Or you get a support contract and we get to read about it earlier. ## Contracts excluded Everyone with a paid support contracts will of course still get full and appropriate service even during this period. Daniel, in a relaxed state. ## Credits The ice cream image was made by fotografierende from Pixabay