The pane arrived at v10.79 as five tables, one per category. Five tables size their columns independently: “WeKan ® Version” made the first one’s label column wide and “OS Type” made the next one’s narrow, so the values started at a different x in every group and the pane read as five unrelated things.

One table now, and each category is a row in it — a th with colspan=2, bold and start-aligned, so it says what the rows under it are about instead of being a label with an empty cell beside it. A colgroup of two 50% columns plus table-layout: fixed puts every label and every value in the same place down the whole pane; the 240px header cap the other admin tables carry is undone for this one, since its width is now stated outright and the cap would fight it.

The category title keeps the table’s own font size deliberately: at the pane title’s size, five of them would read as five pane titles and “Version” would be lost among them.

Two of the repository’s own guards caught mistakes on the way, which is what they are for. The jade compile check refused th(colspan=2) — the Meteor jade dialect wants the value quoted, and an unquoted one is a build failure rather than a rendering difference — and the RTL check refused text-align: left, because the label column is on the RIGHT in Arabic and Hebrew, so it is start.

The pane drew its title and then empty space, while Summary went on reporting “7 new problems” for it.

Everything about it looked right, which is why it survived: the menu has a report-integrity entry, clicking it is handled, the handler sets tmpl.showIntegrity, and the template has else if showIntegrity.get with an integrity event stream under it. The missing piece was the helper. showIntegrity() was never added beside showDatabase() and the eight others, and in Blaze an undefined helper is not an error — it is falsy. So the branch never ran, the page was blank, and nothing anywhere said why.

The guard added with it is the class rather than this one pane: every show*.get branch in a settings template must have a helper of that name in that template’s own .js, and a ReactiveVar behind it. The templates are FOUND rather than listed, so a pane added later is covered without editing the test.

A snap upgraded onto a database left by a MongoDB 4.x or 5.x snap served 502 Bad Gateway indefinitely, with the reason only in snap logs:

This version of MongoDB is too recent to start up on the existing data files.
Try MongoDB 4.2 or earlier.

The snap carries two readers — mongod 7, the server it runs, and the MongoDB 3.2 tools for a 6.09-era database — and nothing in between, so 4.x data opens in neither. What the code did then is the one thing that cannot work: the migration found that neither reader could open it and handed back to mongodb-control, which started mongod, which failed the same way, which re-ran the migration — three times by its own counter — and then exited for snapd to restart. Nothing in that loop can succeed, because reading those files needs a binary the snap does not have.

It stops now. The migration tells “no reader for this vintage” from “unreadable or corrupt” by mongod’s own words, records the version mongod named as still able to read the data, pauses auto-migration and exits 0 — zero, because snapd restarts a failing service forever and no restart can help here. mongodb-control will not start a mongod it knows cannot start, and WeKan serves an explanatory page on the web port, both at startup and from inside the database wait loop, so an instance already waiting switches over without a restart.

The page names the MongoDB version that can still read the files and gives the two ways forward — go back to the revision that worked, or dump with a MongoDB that can read it and restore into this version — says plainly that nothing was changed and that attachments and avatars are files on disk, and drops the auto-refresh and the spinner the other two maintenance pages carry: this is a stop, not a wait, and the page should not promise that something is happening.

Nothing is deleted or modified on this path: the source data is exactly as it was, the marker file is the only thing written, and removing it lets the snap try again. The snap documentation gains the section an admin searching for that mongod line will find, with the commands.

The test covers the wiring in all three scripts and then RUNS the page — it is standalone Node with no dependencies — to check what an admin actually sees: 503, the version, “untouched”, both remedies, no refresh, no spinner.

The entry above stopped the crash loop and explained it. This removes the reason for it in the case that was actually reported.

A MongoDB server only starts on data whose featureCompatibilityVersion is at most one major behind it, so what the snap can READ is decided by which servers it carries: mongod 7 (FCV 6.0, 7.0) and the MongoDB 3.2 tools (3.2). Everything in between was unreadable — and the WeKan snap has shipped 3.6, 4.0, 4.2, 4.4 and 5.0 over the years. The reported error names the gap exactly: “Try MongoDB 4.2 or earlier”, which is FCV 4.0.

mongod 4.2 is now bundled as a third reader, used only to read the old data during a migration and never as the running database. It opens FCV 4.0 and 4.2, and the modern importer reads it with the bundled driver, which supports servers from 4.2 up — the same importer that reads a 6/7 source, not a second copy of it. The probes run newest-first: 7, then 4.2, then the 3.2 tools, then the page.

amd64 and arm64 only. MongoDB publishes no 4.2 for the others, and they have been FerretDB from their first boot, so there is nothing there to migrate from.

It carries its own OpenSSL 1.1. The 4.2 build links libssl.so.1.1 and libcrypto.so.1.1, and core24 is Ubuntu 24.04, which ships OpenSSL 3 — without them the binary does not even load. Both come from one Debian libssl1.1 package, staged beside the binary and put on LD_LIBRARY_PATH exactly as the 3.2 tools already are, with the filename resolved by listing the pool rather than pinned, because point releases roll and a pinned name 404s the day they do.

Optional by design: every failure in that part — download, checksum, OpenSSL, or the binary not running — ends it with a message and no binary, and the migration simply does not find one. A release is never failed over a migration aid.

Verified as far as a machine without a snap allows: mongod 4.2.25 aarch64 was downloaded, staged with the Debian libssl1.1 and RUN — “db version v4.2.25, OpenSSL version: OpenSSL 1.1.1w” — then started on a dbpath, forked and listened on a port. That is the whole mechanism, on a 2026 system. The build repeats the check and unstages the binary if it fails.

Still unreadable, and still answered by the page rather than a migration: 3.4, 3.6, 4.4 and 5.0. Bundling mongod 5.0 beside this one would close 4.4 and 5.0 the same way, at the same cost in size.

The pane’s five category labels and the packaging row arrived in English only, so every other language showed them in English. Three of the six needed translating at all: Platform, package (“Package”) and OS. Database was already translated in 131 languages — the key existed before and this revived it — and Meteor and Node are product names that stay as they are in every language, which is also why the filler ignores a value equal to the English source.

Translated directly, with no external service, using each language’s own existing strings as the reference. Its OS_Type and OS_Platform show the form that language’s translators use — “Typ des Betriebssystems”, “Tipo SO”, “Тип ОС”, “Käyttöjärjestelmän tyyppi” — so OS is Betriebssystem in German, SO in Italian and Portuguese, ОС in Russian and Käyttöjärjestelmä in Finnish, rather than one spelling imposed on all of them.

Two files were deliberately NOT copied from: Greek’s OS_Type and OS_Platform hold Italian, and Korean’s hold Japanese. Propagating that would have spread somebody else’s mistake into three more strings, so those two got proper Greek and Korean instead.

Applied through fill-translations.mjs --apply, which writes only into a placeholder, so no human translation could be overwritten even by accident — and the diff shows it: 292 changed lines across 106 files, every one of them Platform, package or OS. Key order and indentation are unchanged, every file still parses, and verify-human-preference.mjs passes 10/10.

40 files keep the English placeholder on purpose — ace, ary, br, gu-IN, ig, km, mn, oc, or_IN, pa, tk_TM, tlh, ug, ve, vl-SS, vo, wa, wo, xh, yi, yo, zgh, zu and the en-* variants, which are English by design. A placeholder that says so is better than a translation nobody can stand behind, and Transifex can still replace any of them with a human one: nothing here is pushed there.