[CI] Ensure messages.pot stays updated

[Chaitanya-Keyal]

Description

This PR introduces a new CI job to ensure that the messages.pot file is always up to date. It also adds a pre-commit hook that automatically runs the extract_messages step before each commit.

Pre-commit hook

The hook runs a Python script that does the following:

• Runs python3 setup.py extract_messages.
• Checks if the updated messages.pot differs from the previous version, ignoring changes to the metadata fields POT-Creation-Date and Generated-By.
• If there are meaningful changes, the hook ends with a "failed" status because it modified tracked files (this is expected). The developer can then review and commit the updated messages.pot.
• If the only differences are in the ignored metadata fields, the file is reverted to its previous state, preventing unnecessary diffs.

Github Action

Similarly, the GitHub workflow runs the pre-commit hook. If it results in any changes, they will appear as a diff in the logs, and the action will fail. This makes it clear that the PR must be updated to include the corresponding changes to messages.pot.

Other changes

• Added setuptools as a dependency in requirements-l10n.txt.
• Updated messages.pot since the dev branch was not up to date.
• Updated documentation with instructions for setting up the pre-commit hook.

I also considered adding pre-commit itself to requirements-l10n.txt, but decided against it. It’s not strictly an l10n dependency. We may want to add a requirements-dev.txt instead, or even better, migrate fully to pyproject.toml and/or a tool like uv.

---

This pull request is categorized as a:

• Other

Checklist

• I’ve run pytest and made sure all unit tests pass before submitting the PR

If you modified or added functionality/workflow, did you add new unit tests?

• N/A

I have tested this PR on the following platforms/os:

• Other

[newtonick]

LGTM, ACK and Tested locally and in my forked repo with some test PRs.

[kdmukai]

Separate TODO item (not part of this PR) but I don't see any basic instructions to make sure the submodules are initialized.

Should this instruction include --recursive?

[Chaitanya-Keyal]

Good point. I remember being confused about this when I first started contributing as well. We should definitely add instructions for cloning with submodules and/or initializing them if the repo was cloned without submodules.

I’m also not completely sure, but I think the newer flag is --recurse-submodules rather than --recursive?

[kdmukai]

I'm sure you're right. I was just going by memory (ALSO why I need everything documented; my memory is terrible!).

[Chaitanya-Keyal]

Also, I see there’s some relevant documentation on this: l10n/README.md that covers initializing submodules. It might be worth linking to this or adding a CONTRIBUTING.md with general instructions, possibly reusing some of the messages you shared in the Telegram group earlier this year during Summer of Bitcoin. This would make it easier for new contributors.

[kdmukai]

After some offline discussion, we have a slightly different view of how we'd like to pursue this.

Your PR would effectively says that an up to date messages.pot file must be part of any PR that touches text. But as other PRs are merged, any open PRs would then need to ensure that there are no merge conflicts with the just-updated messages.pot. Since our PRs tend to stay open for quite a while, that could create multiple rounds of rebasing and regenerating the messages.pot. That feels like an unnecessary additional maintenance task for all PR authors.

That being said, there IS value in surfacing any expected changes in the messages.pot due to a given PR.

So we were wondering if instead we could just do a Github Action that would act somewhat like the screenshot diff generator in the translations repo: Generate the new messages.pot and then compare that against a version generated from the latest dev. Then output some report format for the diffs.

The screenshot diff generator only went as far as outputting an html summary of the screenshot diffs, but you still have to dig a bit into the workflow results to get that report in the downloadable CI artifacts.

Ideally this messages.pot diff Action would write a comment in the PR and report the results there. That's beyond my Github Actions know-how, though. And then on each new commit in the PR, the Action should be able to update its comment in place with the latest diff. For example, bitcoin core has some kind of automation that dynamically updates the list of ACKs and NACKs in the first comment in a PR.

But note that with the approach described here, we are explicitly avoiding making the messages.pot a requirement to include in the PR.

In fact, we'd like to move towards another automation that will rebuild messages.pot on each merge. Though now that I think of it, the only way for that to work would be for the Action to open a new PR with the resulting change.

If you're onboard with this approach, I'd suggest splitting it into two PRs:

1. Github Action to show the messages.pot diff for each PR as a comment and keep that diff report comment up to date.
2. Github Action to generate the new messages.pot after a merge to dev and if there are changes, open a PR with just that file.

This would mean that we would abandon the pre-commit approach. But I think a lot of that python script can be adapted for the Step 1 job.

[Chaitanya-Keyal]

That makes sense. I agree that requiring every PR to stay fully up to date with dev would be inconvenient.

I still think there is value in keeping a pre-commit hook for developers. It removes the manual step of remembering to update messages.pot, and for well-maintained branches, it should prevent the bot from needing to open a separate PR.

So, aligning with your suggestion, I would propose the following:

1. GitHub Action (PR level): Generate and post a diff of messages.pot between the current branch and dev. It should also check whether the PR already includes an up-to-date messages.pot.
2. GitHub Action (post-merge): After each merge to dev, regenerate messages.pot. If there are changes, either open or update a single existing PR for that file so the bot does not create multiple open PRs.
3. Pre-commit hook: Keep a local pre-commit step that runs the extraction automatically before commits to keep developer workflows smooth.

For this specific PR, that would mean keeping the entire pre-commit setup, but removing the current GitHub workflow and replacing it with the above two workflows.

Let me know what you think, and I can start implementing this. I am not fully sure yet what permissions the GitHub Actions bot will need, but it should be manageable.