The staleness guard added for #6583 had the opposite failure of the bug it fixed:

A couple of weeks ago, I did a snap revert … but then completed the migration successfully. Today, my database suddenly reverted to an old version from what looks like weeks ago. Upgrading to 10.83 did not fix the problem automatically.

Their FerretDB was the live database and had been for two weeks; MongoDB was the frozen one. The guard decided otherwise because it compared exactly two things: the newest mtime under the MongoDB data directory, and the migration marker. Starting mongod rewrites those files - recovery, and the checkpoint it writes on startup - so one service start during a refresh put MongoDB’s newest mtime at today against a marker from two weeks ago. The guard called the live copy stale, wekan-control set database=mongodb, and what came up was the data as it stood on the day of the migration. Upgrading could not help, because the upgrade was the cause: this runs at every start, so every start re-applied it.

An mtime cannot tell somebody used this database from this database was started, so asking it of one copy cannot answer the question. Asking it of both can, because the case the guard exists for has a shape the mistaken one does not. The migrated copy untouched since the migration while MongoDB moved on is STALE - nothing has been using FerretDB. The migrated copy moved on while MongoDB did not is CURRENT, the normal state after a successful switch. Both moved on is AMBIGUOUS: two databases have been written to since they were copies of each other, and there is no answer there, only a choice, and it is the admin’s.

Only the first may be acted on automatically. The ambiguous case switches nothing, prints both databases’ last-written times and the two commands to look at each, and says that nothing was changed or deleted - both copies live in $SNAP_COMMON, which snap revert does not roll back. That restraint matters most in the branch of mongodb-control that DELETES files/db to migrate again when mongod cannot start at all: on ambiguity the SQLite holds work of its own, so wiping it would destroy the very copy in doubt.

The message has no database=ferretdb condition on it, deliberately. An instance the old guard already moved to database=mongodb is sitting on the wrong copy now and that setting persists, so speaking up only when FerretDB is selected would leave it there silently. Whichever side is selected, the admin hears that the other one holds writes of its own.

tests/ferretdbMigrationStale.test.cjs gains the reported regression - a two-week-old migration, a FerretDB written to a minute ago, a mongod started an hour ago - and pins that ambiguity can never reach the deletion.

invalid-year, collapse-checklist and expand-checklist shipped in en.i18n.json with the card-date fix and the collapsible checklists; every other language file carried them as English placeholders. Translated directly, as CLAUDE.md requires - no external translation service, API or key - from each language’s OWN existing strings, so the wording matches what that file already says rather than being invented beside it.

Three anchors did most of the work. checklist and collapse / uncollapse give each language its established terms, and invalid-domain is the same shape of sentence as the new one - a rejection, then an instruction with an example - so its phrasing, punctuation and register carried over directly.

Where an anchor was itself wrong the correct term was used instead of copying the mistake forward. Several files have terms that drifted in from another language: Italian Non collassare in the Greek and Romanian files, Russian in the Georgian and Mongolian ones, Vietnamese in the Thai one, Serbian in the Slovenian and Bulgarian ones. Others use a literal sense of “collapse” that is not the UI one - Azerbaijani Yıxılma, Estonian Kokkupõrge, Khmer ដួលរលំ and Chinese 崩溃 are structural collapse, a building falling down. The new strings use the folding sense each language actually uses for this control.

Nine languages are deliberately left as English placeholders rather than guessed at: Klingon, Volapük, Tamazight, Walloon, Wolof, Uzbek in Arabic script, and the three ve files, whose contents disagree with their own locale tags - ve-CC reads as Venetian and ve-PP as Veps, so which language to write is a question about the file, not about the string. A placeholder says “nobody has translated this yet”, which is true; a fabrication would say something false in a shipped product.

Applied with fill-translations.mjs --apply, which writes ONLY into placeholders: every language reported filled 3, skipped 0 existing human translation(s), so no human translation was touched. Key order and the 2-space indent are preserved, all 154 files still parse, and verify-human-preference.mjs passes 10/10.