update.locales: false is overwritten by checkVersion task

[MilanVolf]

Description

Setting the following configuration:

update:
  locales: false

does not reliably disable automatic locale updates.

The updateLocales task correctly checks the configuration:

if (WIKI.config.update?.locales === false) {
  return
}

However, the checkVersion task later replaces the entire WIKI.config.update object:

WIKI.config.update = {
  lastCheckedAt: new Date().toISOString(),
  version: strictVersion,
  versionDate: resp.published_at
}

await WIKI.configSvc.saveToDb(['update'])

As a result, the existing locales: false property is removed.

After checkVersion has run, the condition in updateLocales effectively becomes:

undefined === false

and updateFromRemote() is executed again.

Steps to reproduce

1. Configure Wiki.js with:

update:
  locales: false

2. Restart Wiki.js.

3. Run the checkVersion scheduled task.

4. Run the updateLocales scheduled task.

5. The installed locale is downloaded / updated despite update.locales being set to false.

I reproduced this with a locally customized cs-CZ.json locale. After manually running the scheduled tasks, the customized locale was overwritten.

Expected behavior

With:

update:
  locales: false

configured, automatic locale updates should remain disabled, including after the checkVersion task runs.

Version checks and other online functionality should continue to work normally.

Actual behavior

checkVersion replaces the complete WIKI.config.update object and therefore removes the locales: false property.

The subsequent updateLocales task no longer sees:

WIKI.config.update.locales === false

and downloads the locale again.

Suggested fix

Preserve the existing properties of WIKI.config.update.

Instead of:

WIKI.config.update = {
  lastCheckedAt: new Date().toISOString(),
  version: strictVersion,
  versionDate: resp.published_at
}

use:

WIKI.config.update = {
  ...WIKI.config.update,
  lastCheckedAt: new Date().toISOString(),
  version: strictVersion,
  versionDate: resp.published_at
}

This would preserve:

update:
  locales: false

while still updating lastCheckedAt, version and versionDate.

[Dv2Corn]

I can confirm this on the current scarlett branch (fc365d6), and the cause is a bit wider than the overwrite in memory.

What happens:

1. On boot, config.yml is merged first and the settings table is deep-merged over it (loadFromDb, toMerged(WIKI.config, conf)). The update row in the database has no locales key, so update.locales: false from config.yml survives the boot.
   

   wiki/backend/core/config.ts

   Lines 119 to 128 in fc365d6

   	async loadFromDb(): Promise<boolean> {
   	WIKI.logger.info('Loading settings from DB...')
   	const conf = await WIKI.models.settings.getConfig()
   	if (conf) {
   	WIKI.config = toMerged(WIKI.config, conf)
   	return true
   	} else {
   	return false
   	}
   	},

2. checkVersion replaces WIKI.config.update with a new object and saves it. saveToDb then emits reloadConfig, which deep-merges the database row over the in-memory config again. Both already lack locales, so the flag is gone for the rest of the process lifetime.
   

   wiki/backend/tasks/simple/check-version.ts

   Lines 16 to 21 in fc365d6

   	WIKI.config.update = {
   	lastCheckedAt: new Date().toISOString(),
   	version: strictVersion,
   	versionDate: resp.published_at
   	}
   	await WIKI.configSvc.saveToDb(['update'])

3. After a restart the flag comes back from config.yml and stays until the next checkVersion. Both tasks are scheduled at 0 0 * * *, so in practice locales stop being protected at the first or second midnight after a restart, depending on which of the two jobs runs first. The "Check for updates" button in the admin area also runs checkVersion, so clicking it has the same effect.
   

   wiki/backend/models/jobs.ts

   Line 37 in fc365d6

   { task: 'checkVersion', cron: '0 0 * * *' },

   
   

   wiki/backend/models/jobs.ts

   Line 69 in fc365d6

   { task: 'updateLocales', cron: '0 0 * * *' },

   
   

   wiki/backend/api/system.ts

   Lines 2303 to 2307 in fc365d6

   	const renderJob = await WIKI.scheduler.addJob({
   	task: 'checkVersion',
   	maxRetries: 0,
   	promise: true
   	})

This is why your customized cs-CZ was replaced: an uploaded locale is stored with an empty hash, so the next updateLocales run sees a hash different from upstream and downloads the published file over it.

wiki/backend/models/locales.ts

Lines 542 to 548 in fc365d6

	hash: '',
	completeness: null,
	strings
	})
	.onConflictDoUpdate({
	target: localesTable.code,
	set: { strings, isInstalled: true, hash: '', completeness: null, updatedAt: sql`now()` }

wiki/backend/models/locales.ts

Line 421 in fc365d6

if (!dbLang.isInstalled || dbLang.hash === entry.hash) {

One thing to watch with the suggested spread fix: saveToDb(['update']) writes the whole WIKI.config.update object, so with the spread locales: false from config.yml gets persisted into the settings table. Because the database row is merged over config.yml on boot, removing update.locales from config.yml later would no longer turn locale updates back on; you would have to edit the update row in the database. I checked this by running the same merge sequence with es-toolkit 1.53.0 (the version pinned in backend/package.json).

A variant that keeps the file setting out of the database:

const latest = {
  lastCheckedAt: new Date().toISOString(),
  version: strictVersion,
  versionDate: resp.published_at
}
// -> Persist only what this task owns, so a flag that comes from config.yml stays there
await WIKI.models.settings.updateConfig('update', latest)
WIKI.config.update = { ...WIKI.config.update, ...latest }
WIKI.events.outbound.emit('reloadConfig')

With this, locales: false survives checkVersion, the database row only holds the three version fields, and removing the line from config.yml re-enables updates after a restart. Other HA instances also keep their own config.yml value, since reloadConfig deep-merges the row over their config.

Until a fix is merged, the only config-only way to stop the nightly download is offline: true, but that also turns off the version check (and other remote fetches), which is what you wanted to avoid. Otherwise, patching backend/tasks/simple/check-version.ts locally as above and keeping a copy of your cs-CZ.json to re-upload is the practical option. A restart alone only helps until the next checkVersion run.

[MilanVolf]

Thanks for confirming this and for the detailed analysis.

This exactly matches the behavior I observed on my installation, including the custom cs-CZ locale being replaced after checkVersion / updateLocales runs.

For now, I have a temporary workaround in place that restores my custom cs-CZ.json after the nightly locale update, so I can safely wait for an upstream fix.

The proposed approach of keeping the locales setting in config.yml and persisting only the version-related fields to the database makes sense to me.

Thanks for looking into this!

[NGPixel]

Fixed via c1d4dfe. Will land in next release.