[i18n] Tracked `.mo` binaries conflict on every parallel i18n PR

[skkzsh]

Friction

#4092 reduced the .po-side merge conflicts, but all 14 .mo binaries still produce conflicts.
Because binaries can't be merged textually, parallel PRs that run compile_catalog conflict on the regenerated .mo files.
The fix is mechanical (re-run compile_catalog, re-stage) but the conflict recurs on every i18n PR.

Question

Is tracking .mo intentional?
It looks like they're tracked to be shipped via sdist/wheel:

changedetection.io/MANIFEST.in

Line 15 in 7831a49

recursive-include changedetectionio/translations *

Possible direction

Meanwhile, the Dockerfile already runs pybabel compile on every build, so the tracked .mo files are overwritten there:

changedetection.io/Dockerfile

Line 123 in 7831a49

RUN pybabel compile -d /app/changedetectionio/translations

With a compile_catalog step in CI, .mo would be generated at build time, mirroring Docker.

changedetection.io/.github/workflows/pypi-release.yml

Lines 21 to 22 in 7831a49

	- name: Build a binary wheel and a source tarball
	run: python3 -m build

Alternatively, hooking compile_catalog into BuildPyCommand.run() in setup.py might also work.

Could .mo then be untracked?

[dgtlmoon]

I saw this too :(