Changelog — 2.64–2.73

Releases 2.64.0 through 2.73.0. Current releases are on the main changelog, and every band is listed in the release archive.

Loading audio...

Version 2.73.0

August 5, 2026

We could set a third choice for when the AI is unavailable, but we could never see it or change it

  • Last time we wrote about the second and third choices that step in when the first is unavailable. Fixing them exposed something simpler and more embarrassing: for the third choice there was nowhere to look and no way to change it. The setting existed, it was used when it mattered, and no screen had ever shown it.
  • So one of them had been pointing at something that no longer exists, and nothing could have told us. It only ever gets used when two other things are already unavailable, which is exactly when you least want to discover a fourth problem. It is corrected, and all of these choices are now on screen where a wrong one is obvious rather than hidden.
  • The first choice is now fixed, on purpose, and cannot be changed here. It is always our own equipment — free to run, and nothing leaves our own network. Previously that was a convention rather than a rule, so it was possible to set a paid service as the first port of call for work we can do ourselves at no cost. Now it simply is not offered.
  • Pronunciation gets a stricter rule than everything else, and it earns it. When we ask an AI how a passage should sound before reading it aloud, a wrong answer still sounds like words — it does not look broken, it just quietly says the wrong thing. So changing which AI does that job is now refused unless it has first been run against a set of passages we already know are hard, and passed all of them.
  • We deliberately made that awkward. A warning would have been easier to build and easier to click past, and the moment somebody is most tempted to swap this is during a problem, which is exactly when a check gets skipped. A refusal cannot be skipped. The button that satisfies it sits right next to the one that refused, so the rule is strict without being a dead end.
  • We also widened that set of hard passages to cover Farsi and Russian, and the Russian one found a fault immediately. A stray mark was being inserted into Russian words that a voice would either read out or stumble over. What is worth admitting is why: our own instructions contradicted each other — one said that mark was allowed, another said it was not — so the fault was ours rather than the AI’s. Fixing the wording was not enough, so it is now corrected in the software itself, and it tells us every time it has to.
  • Nothing to do at your end. None of this changes what you read or hear; it changes whether we can see and correct the machinery behind it.

Version 2.72.0

August 5, 2026

We had a second choice for when the AI is unavailable. It had quietly stopped being used

  • Several things on the site are written or translated with AI help — reflections, vignettes, articles, subtitles. If whichever system we ask first is busy or unreachable, there is meant to be a second choice, and a third, so the work carries on instead of failing.
  • Those choices were set up, saved and shown back to us as ready — and none of them were ever tried. The rule deciding whether to switch had been written for an earlier arrangement, and when we changed which system gets asked first, the rule stopped matching without anyone touching it. Nothing broke, nothing complained, and our own logs cheerfully reported that a second choice was standing by.
  • That is the part worth admitting. Every signal we would normally trust looked healthy. The settings were right, the request carried them, the reply came back fine. It failed inside a single line of a decision nobody had cause to re-read, and the only way to find it was to follow the whole path end to end rather than check that each end looked sensible.
  • Article writing had it worst. It had a second and third choice configured and never offered them at all — so if the first system was unavailable, the article simply failed.
  • The menu of alternatives was out of date too. It had been typed out by hand a while ago and never re-checked: half the options on it no longer existed, including two we had marked as recommended. Choosing one would have saved perfectly happily and then failed much later, at the exact moment it was needed. That menu is now read from the source each time rather than remembered.
  • Nothing to do at your end.

Version 2.71.0

August 5, 2026

Four corners of our editing tools had quietly grown into four different designs

  • This one started with a button that was hard to read. On the Reflections list, the Edit button had dark text on a dark background. Measured properly it was well below the accessibility standard for readable text — not a matter of taste, a genuine failure.
  • The cause was not a badly chosen colour, which is the interesting part. That one button was the only place that never said what colour its text should be, so it quietly borrowed one from elsewhere — and what it borrowed was our brand green, which is close to invisible on a dark grey button. The three similar buttons elsewhere escaped by accident rather than by design.
  • Looking properly turned up more than the button. Across the four lists you use most — Reflections, Vignettes, Event series and Event episodes — there were three different Edit buttons and two different Delete buttons, all slightly squarer than the panels they sit in. They now come from one place, so they cannot drift apart again.
  • You can now click the name of anything to open it. Vignettes always let you do that; the other three made you find the Edit button. That difference had no reason behind it — it was simply how each page happened to get written.
  • Deleting now asks properly instead of using the browser’s grey box. We already had a decent confirmation dialog — it turned out exactly one page used it, while everything else fell back to the plain browser prompt that ignores dark mode entirely. Now it shows what you are about to delete, warns you when a whole series of episodes will go with it, and if something goes wrong it tells you in the dialog rather than flashing a message and vanishing.
  • Nothing to do at your end.

Version 2.70.0

August 5, 2026

If you closed the tab while something was still being made, we now offer it back

  • Some of the things our editors ask for take a long time to make — a story, or a piece of artwork. Until now, if you closed the tab or your laptop went to sleep before it finished, the finished result had nowhere to go. It was made, and then quietly lost.
  • Now, when you come back, the page tells you. You get a short note saying what finished and when, with a button to bring it in.
  • It asks rather than does. We deliberately do not drop the recovered work into the page for you. You may well have rewritten the thing in the meantime, and quietly replacing it would mean losing something without ever being told.
  • There are two answers, and we changed our minds about the second one after actually using it. Originally you could say “not now” and the result stayed put. That sounded careful and was annoying: the same prompt came back every time you opened the page for the next hour, and a prompt you cannot get rid of is one people stop reading. So the choice is now Restore or Discard, and Discard really does throw it away. The button says so, because a button that deletes half an hour of work should never read as “remind me later”.
  • And you now get one card per kind of thing, not a pile of them. We were showing every finished item, which meant two stories half an hour apart and no way to tell which was which — the card shows what it is and when it finished, never the story itself. Choosing between them was a guess.
  • The card tells you how many it stands for, and your answer covers all of them. If three stories finished while you were away, it says so: restoring keeps the newest, discarding removes all three. We went back and forth on showing you the older ones so you could pick, and decided against it — it would have meant a whole second screen for something you almost never need. Telling you the number costs nothing and means you are never deleting something you did not know about.
  • The first time we pressed our own Restore button, it broke the page. We are saying so because of what it took to find: our automated checks were entirely happy, and had been all along. The stored result travels through a part of the system where those checks cannot follow, so the only thing that could have caught it was a person clicking the button. That is now covered by a test that we deliberately broke first, to prove it would actually notice.
  • And it was the worst possible way to fail. This whole feature exists so that work is not lost — and the fault threw away whatever you happened to have open at the time. A safety net that empties your pockets is worse than no safety net, so it was fixed before anything shipped.
  • We also found that we had written down “three” where the answer was four, in the note describing which kinds of work needed this. The number had been recorded before we built the thing that could actually count it, and then quietly copied elsewhere. Both places now work it out instead of restating it.
  • Nothing to do at your end.

Version 2.69.1

August 5, 2026

Writing down what actually shipped, rather than what we meant to build

  • Nothing you can see on the site changed today. This is our own written record catching up with yesterday’s work, which we treat as part of finishing a job rather than as tidying up afterwards.
  • We have a rule that a piece of work is not done when it goes live — it is done when the documentation describes what actually went live. That step sits at the very end, which makes it the one most likely to be skipped, so we say plainly that it blocks. This is us doing it.
  • The document describing how non-English passages are prepared for reading aloud now covers the checking tools we added yesterday — and, more usefully, what those tools found within an hour of existing: a rule we had written down but never actually checked, an instruction elsewhere that contradicted it, and passages in Persian being handled as though they were Arabic.
  • One table in it was deliberately left alone rather than updated. It records how the system performed on a particular day, and the instructions have changed since. Rewriting it would have swapped one out-of-date snapshot for another; instead it now says when it was taken and how to take a fresh one. We would rather a reader knew the age of a number than trusted a new-looking one.
  • Nothing to do at your end.

Version 2.69.0

August 4, 2026

We named things Athenaeum and Odeum and then never told anyone what those words mean

  • There is a new page explaining what our sections are called and why — you will find it in the Help Centre as Our Names. It covers Reflections, Vignettes and Events, and the three larger sections we are building: the Athenaeum for reading, the Lyceum for video, and the Odeum for audio.
  • The names are English or classical on purpose, and the reason is worth saying out loud. We publish Islamic learning in proper English for people who live their lives in English. Islam is too often made to feel foreign here — something that turns up with its own vocabulary and asks you to learn it before you are allowed in. We would rather someone who has never met a Muslim could read the name of a page and know roughly what is behind it.
  • But a name nobody explains teaches nobody anything. “Athenaeum” and “Odeum” are unfamiliar words to a good part of our own audience, including plenty of people from Muslim backgrounds. Without this page we had the worst of both: names that were unfamiliar to Muslims and unexplained to everyone else. That was our mistake and this fixes it.
  • Some of our tools carry Arabic names, and the page explains that as the same principle rather than an exception to it. The rule we follow is to name a thing for the people it is actually for. Usually that produces an English name. For a page used by researchers, or by someone asking their marja a question, the Arabic word is the ordinary everyday one and a Greek substitute would be the strange, distancing choice. Same rule, different audience, opposite answer.
  • The names we rejected are on the page too, because they show the thinking rather than just the conclusion — including one we nearly chose and dropped because it would have put people off before they had read a single word of what it described.
  • The page is honest that three of those sections are still being built. It says so plainly rather than in small print. Explaining a name before it arrives is helpful; implying you can go and use it today would not be.
  • We also fixed something small and self-inflicted while we were there. The Help Centre described its own contents in a hand-written sentence listing the guides — in three separate places. Every one of them would have quietly become out of date the moment we added this guide, and nothing would have looked broken. The description is now worked out from the actual list of guides, so it cannot fall behind again.
  • Nothing to do at your end.

Version 2.68.0

August 4, 2026

Our check on how Arabic and other scripts get read aloud was quietly enforcing only half of its own rules

  • When a page carries Arabic, Hebrew, Greek or Japanese and you ask for it to be read aloud, we write those passages out phonetically first — so the voice pronounces the words rather than mangling them into noise. It is an unusually unforgiving thing to get right, because a mispronunciation still sounds like words. It does not announce itself the way a missing image does; it simply says something slightly wrong, confidently.
  • Until now there was no way to check it was still working without generating audio and listening to it. There is now a page where we can run a small set of passages we already know are difficult and see exactly what the voice would be handed — alongside a box for pasting in any passage and checking it on the spot.
  • The first time we ran it, it found a fault in our own checking rather than in the output. We have a rule that the phonetic spelling must use plain unaccented letters, because accented characters are precisely what a reading voice tends to skip or spell out one letter at a time. That rule had been written down and never actually checked. So accented output was sailing through and being marked correct. It is checked now.
  • Within the hour it had found two more faults, which is the whole argument for building it. Our own instructions for Greek told the system to use the scholarly spelling convention — and that convention is precisely the one that puts accents on letters, which we had just finished banning. The instruction was contradicting the rule, and had been for months. And separately, most Persian was being treated as Arabic: we were recognising it by four letters that a great deal of perfectly ordinary Persian simply does not contain.
  • The Persian one is the more interesting, because the output looked fine. Nothing was garbled; the passage was merely being handled under the wrong set of instructions, and the system quietly worked around it from context. Once corrected, the same line came out with the right vowels and the right Persian grammar rather than an Arabic approximation of them. A fault that produces acceptable results is the hardest kind to notice and the easiest kind to leave in place for years.
  • The page also insists on measuring rather than remembering. It does not display anything typed in by hand; it asks the system directly, every time you open it, and says plainly when it could not get an answer. We have been caught out more than once by a note that was accurate when written and wrong by the time somebody read it, with nothing anywhere going red in between.
  • We corrected an inconsistency we only noticed because that page put it on a screen. This particular job had been set up differently from the equivalent work elsewhere on the site — not by anyone’s decision, just by never having been looked at side by side. It now matches.
  • And one internal settings page could be opened by people who were not permitted to use it. Nothing was exposed: every piece of information on it refused them correctly, as it should. But the page itself opened and then failed at everything on it, which is confusing rather than safe. It now declines at the door instead.
  • Nothing to do at your end.

Version 2.67.1

August 4, 2026

Our own instructions for putting the site live described one part of the job and never mentioned the thing that does all of it

  • Nothing you can see on the site changed today. This is about the written instructions we follow when we publish an update.
  • Publishing an update has several ordered steps, and we built something a while ago that runs all of them for us — in the right order, stopping to explain each one and confirm before it acts. The trouble is that the two documents anyone actually reaches for still opened by naming a single step of the job, and never mentioned the thing that runs the whole of it.
  • The problem is not the missing sentence. It is which wrong conclusion the omission made sound reasonable. Forgetting the all-in-one tool and doing the steps by hand is fine — every safety check is still in the individual step, including the one that takes a verified backup and refuses to continue without it. But concluding the opposite — that the all-in-one tool has replaced those steps and they can be tidied away — would break it outright, because it does not contain any of that work itself. It only arranges it. And that was the direction our own writing pointed.
  • It came up as a question rather than as an incident, which is the good outcome. Somebody asked, sensibly, whether the older instruction was still current. That is precisely the moment a thing should stop being folklore and get written down, so we wrote it down.
  • The instructions now say plainly that these are not alternatives. One arranges, the others do the work, and neither is spare. We also recorded that this relationship is not a matter of good intentions: the arranging tool inspects itself and refuses to run if any route to publishing skips the check that proves our verification would actually notice a problem.
  • Both documents keep the step-by-step version. It is what you need for a publish that is not a full release, for when the all-in-one tool refuses, and for anyone who wants to understand why a step is there rather than just perform it.
  • Nothing to do at your end.

Version 2.67.0

August 4, 2026

Last time we split these notes with room to spare. This time we ran out first.

  • This page holds our release notes, and it had filled up completely. There is a size beyond which it becomes slow, so it gets divided periodically. We split it a couple of days ago with a comfortable margin — and used every bit of that margin before we split it again. The next set of notes could not be written until this was done.
  • The estimate we made last time was not wrong. It just measured the wrong thing. It worked out how many more releases would fit, and that arithmetic held. What it could not know was how quickly those releases would arrive: enough landed in two days to fill the space we thought would last a while. A limit on size tells you nothing about time.
  • Releases 2.55 to 2.63 have moved to a page of their own. This page keeps the newest ones, and every older page is listed in the release archive, linked at the foot.
  • Where we divided is the part worth explaining. We could have cut higher and bought ourselves more room. We deliberately did not: several of these releases have been finished but not yet published to the live site, and cutting higher would have filed them into the archive in the very same moment they first appeared. So we cut at the version the site is actually running — nothing gets archived until it has had its turn on the front page. That is now written down as the rule rather than as this week’s decision.
  • Any link you have saved still works. A link to an older release is forwarded automatically to whichever page now holds it, and lands on the release itself rather than the top of the page. We check both, in a real browser, because the failure here is completely silent — nothing errors, you simply end up somewhere you did not ask for.
  • Our own written instructions for doing this said “nothing else changes”, and that was not true. Doing it turned up four things that do change, none of which announces itself if forgotten. They are now listed, in the instructions, in the order you meet them.
  • And, once again, we found counts written down that this change made wrong. One was inside the very sentence advising against writing counts down — and had been wrong once before, in the same place, for the same reason. It no longer states a number at all. This keeps happening, so we keep replacing the numbers with instructions for measuring.
  • Nothing to do at your end. Nothing about the site itself changed — only how these notes are filed.

Version 2.66.0

August 4, 2026

Long jobs now say what they are doing, and a recovery feature we thought we had turned out never to have worked

  • Some of the work behind this site takes a long time — making artwork, rendering a video, preparing audio. We had built the part that keeps a record of that work, so nothing is lost if you close the tab. What we had never built was anything that reads those records back and tells you about them.
  • There is now a single place showing everything in progress. What is running, who started it, how far along it is, and what finished recently. It also says when the machinery that makes pictures and video is busy, who is using it, and roughly how much longer — so if you were wondering why a button is greyed out, the answer is now on a page instead of a guess.
  • The part meant to tell you “this finished while you were away” had never once worked. It asked for a list of jobs that were still running, and then looked through that list for jobs that had finished — something that list could never contain. It had been written that way for four and a half months, and the reason nobody noticed is that nothing had ever used it. Code being present is not the same as a feature working.
  • Fixing it turned up a subtler version of the same mistake. The plan was to only mention things that finished in the last hour, so you are not pestered about something from last week. Done the obvious way, that would have measured from when a job started — which would have silently hidden anything that took more than an hour. In other words, exactly the long jobs the whole feature exists for. It now measures from when the job actually finished.
  • The new page found a real problem within seconds of first being switched on. Two jobs from a couple of days ago had been recorded as failures, when in fact they had done all their work and were shut down while still going. They had stopped sending the regular “still alive” signal, while visibly continuing to report progress — so everything watching them concluded they were dead. We have not fixed that yet; the point is that until now there was nowhere it could have been seen at all.
  • We also threw away a very tidy explanation for it. A problem we fixed last week would have accounted for it perfectly, and it was tempting. Checking properly showed it could not have been the cause. An explanation fitting neatly is not evidence that it is right, and writing down the one we rejected matters as much as the one we kept.
  • Nothing to do at your end. This is all behind the scenes, in the tools we use to run the site.

Version 2.65.0

August 4, 2026

We renamed some folders, and very nearly took down the part of the site that writes things

  • Two folders in our code were named after machines that do not exist. Both came from the same old mistake — reading two different lists as though they described the same thing, and inventing a name that was never real. It has misled us more than once, including into recording a perfectly healthy machine as dead, so we finally renamed them.
  • The rename should have been the dullest possible job. It was not. Some of our tooling identifies a running service by the name of the folder it was started from — a connection that is written down nowhere, is invented automatically behind the scenes, and cannot be found by searching our own code. Renaming the folder would therefore have quietly cut a central part of our written-content machinery off from everything it had already prepared, and forced it to start again from nothing.
  • Nothing would have gone red. That is the part worth saying plainly. It would not have failed at the moment we made the change; it would have waited, and gone wrong later for whoever next did something entirely routine — with nothing to connect the failure back to its cause. We found it by going and looking at the running systems rather than reading our own notes.
  • We then found the same thing had already happened once, and nobody noticed. A similar reorganisation some time ago quietly abandoned things in exactly this way, and the leftovers are still sitting there. It never produced an error, so nothing ever told us.
  • The fix removes the trap rather than avoiding it. These services are now told their own identity explicitly, instead of having it inferred from where their files happen to live — so the next person to move a folder cannot be caught by this at all. We tested it in both directions before believing it, including deliberately breaking it to confirm the problem was real and not imagined.
  • A safety check we built last week paid for itself. Part of our release tooling works out which services a change affects, and it is deliberately built to read that from configuration rather than a list we maintain by hand. It needed no updating at all — and its own test refused to pass halfway through the rename, pointing straight at the two things still outstanding. A check that fails loudly in the right place is worth a great deal more than one that is merely present.
  • Nothing to do at your end. This is entirely about the machinery behind the site, and nothing you can see has changed.

Version 2.64.0

August 4, 2026

One of our build machines was quietly filling up, and the tidying job we already had could never have kept pace

  • The machine that assembles every update to this site was running out of space, and had been for under a week. If it fills completely, nothing can be built and nothing can be published. We found it while looking at something else entirely.
  • The nightly tidy-up was working perfectly, which is exactly why nobody spotted the problem. It ran, it cleaned, it reported success. It simply cleared a fraction of what a busy day was adding — so the machine crept upwards every day while every check said “fine”. Asking “is the cleanup working?” would never have found this; only comparing the two rates against each other did.
  • It now runs four times a day instead of once, and clears a second, larger pile it had never been told about. We also cleared a great deal by hand while we were there, which brought it comfortably back down.
  • The tidy-up used to run at a fixed time without checking whether anything was in progress. That was safe by luck rather than by design — some builds genuinely run through that hour, and deleting files underneath one produces a confusing failure that looks like a completely unrelated bug. It now checks first, and refuses to run while work is in flight.
  • The obvious way to write that check would have silently switched the cleanup off forever. There is always one helper process running on that machine, so “is anything running?” would always have answered yes — and because the old script said nothing when it skipped, we would never have found out. The check is now specific about what it looks for, it records every time it skips, and we have a test that deliberately proves the always-present helper does not count.
  • Separately, every one of our nine build jobs was storing several gigabytes of data that nothing would ever read back. Eight of them were configured for a kind of build they do not do. Fixing that removes roughly two minutes of pointless work from each one and is a large part of what was filling the disk in the first place.
  • And we found the safety net missing from the one build that matters most. A protection added last week to the eight smaller builds had not been applied to the main website build — the one that gates every release. A harmless storage hiccup could have failed it outright.
  • Nothing to do at your end. This is entirely about the machinery behind the site.

Our Release Philosophy

"We aim to build with excellence, patience, and continuous improvement. Each release represents careful development, thorough testing, and a commitment to serving the Muslim community with quality technology."

← All releases