"Cannot update via web" warning not shown when language pack is used

[ThiefMaster]

Bug description

The message with the language pack is the default one instead of the Docker mention.

Steps to reproduce

• Use a language pack (only tested w/ the German one)

Expected behavior

The docker message shows up. Even if it's not translated, having it would still be much better than the default one.

Container metadata

n/a

Relevant log output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[ThiefMaster]

After looking at https://github.com/felddy/foundryvtt-docker/blob/develop/src/patch_lang.ts I think a possible fix could be patching Foundry so it does not use SETUP.UpdateHint but a different label. However, considering how ugly that would be, maybe it's better to automatically patch lang-* modules and inject the English message there instead of the translated default one (or if you want to be fancy: inject translated messages).

Another - much cleaner - alternative could be asking the foundry dev @aaclayton to add a config option or env var to disable the built-in update logic/UI, which your container could then set.

[aaclayton]

The core software exposes a --noupdate launch flag which disables update checks and other behaviors. Perhaps this flag should be set in docker environments?

[felddy]

Thank you @aaclayton, the container does use the --noupdate flag as you suggested:

foundryvtt-docker/Dockerfile

Lines 97 to 100 in b8334b2

	ENTRYPOINT ["./entrypoint.sh"]
	CMD ["resources/app/main.mjs", "--port=30000", "--headless", "--noupdate",\
	"--dataPath=/data"]
	HEALTHCHECK --start-period=3m --interval=30s --timeout=5s CMD ./check_health.sh

The issue here is that I can only patch the languages that exist when the distribution is installed. As you pointed out @ThiefMaster this is only en.json:

foundryvtt-docker/src/patch_lang.ts

Line 5 in b8334b2

const LANGUAGE_FILENAME: string = `${process.env.FOUNDRY_HOME}/resources/app/public/lang/en.json`;

One my the goals of this project is to have a "light touch" as to avoid any side-effects. Once things are up and running the container only provides continuous health checks. To patch other languages as they are installed would require something more invasive than I would be comfortable with.

I'm open to other suggestions on how to implement this feature for more languages. Perhaps there is a robust way for the container to overlay its own set of language files for these few labels.

[ThiefMaster]

Upstream support for something like --noupdate="message why updates are not possible" could be a clean option :)