Localization admin duties
Localization team members with admin rights on both Forgejo and Weblate are expected to make sure the translations land in the Forgejo repository and resolve conflicts when they arise.
Merging translations in Forgejo
Weblate is configured to propose pull requests to the Forgejo repository with new translations. These pull requests should be squash merged into the Forgejo development branch as follows:
- announce in the chatroom:
@room the translations will be locked for maintenance in about 15 minutes. Make sure you don't try to save a translation when that happens as it will be lost.
- go to the Weblate repository admin page
- click
Commit
. This is done optionally to make tests run before interrupting anyone, to reduce the total maintenance time - post an announcement in Weblate:
The translations will be locked for maintenance soon. Make sure you don't try to save a translation when that happens as it will be lost.
- wait 15 minutes
- click
Lock
- reload the page
- check the number of commits
- verify there are 0 pending changes
- go to the pull request and wait until it is rebased and has the same number of commits
- squash-merge the pending
[I18N]
pull request (similar to this example) - click
Reset
- click
Unlock
- remove Weblate announcement
Merging a pull request that changes translations
When a Forgejo pull
request modifies files in
options/locale
other than locale_en-US.ini
for which it is
authoritative, it must be merged after all pending changes in Weblate
are merged as explained above. Only the end of the sequence changes:
- squash merge the pending
[I18N]
pull request (similar to this example) - merge the PR (after resolving conflicts due to the merge of the Weblate changes)
- click
Reset
- click
Unlock
Resolving failures
Weblate locked due to network error
Sometimes a connectivity error with Codeberg or it’s unavailability can cause Weblate to lock. The lock error looks like this:
Weblate will retry connection attempts but it takes hours before it does that. If Codeberg is currently available and working, the project can simply be unlocked manually to allow the translators to keep working.
Weblate was not reset before unlocking
If Weblate was not reset after a translation squash-merge was performed, and it already has new edits, the following steps must be taken to resolve failing rebase and save the new edits:
- Lock Weblate if it didn’t lock itself yet due to a rebase error
- Make sure there are no pending changes. If there are, click
Commit
- Download current translation files just in case something goes wrong
- Add internal Weblate git repository to your remotes and fetch it:
git remote add weblate https://translate.codeberg.org/git/forgejo/forgejo
,git fetch -u weblate
- Checkout into it’s branch to see which commits it contains:
git checkout weblate/forgejo
. Identify the new commits that were not squash-merged into the Forgejo repository yet - Checkout a new branch from
forgejo
branch:git switch forgejo
,git checkout -b i18n-weblate-recovery
- Cherry-pick the new commits into this new branch:
git cherry-pick <commit>
- Publish this branch and open a PR
- Wait for the PR to be merged
- Click
Reset
- Click
Update
- Click unlock
Commit changing non-base locales was merged before Weblate
If a commit changing translation files other than en_US.ini
was merged before all changes from Weblate were merged, it could have caused Weblate to lock itself due to failed rebase.
If the rebase did succeed, everything is ok and no steps need to be taken, just be more cautious with merges next time.
If Weblate failed to rebase, the following steps must be taken:
- Make a PR that reverts the commit that caused the breakage
- Merge this PR
- Make Weblate commit and push all changes
- Merge the Weblate PR
- Rebase the commit(s) of the PR that caused the breakage on top of the new Weblate commit, open a new PR
Alternatively the same steps as in Weblate was not reset before unlocking
can be taken, except that the conflicts must be resolved with Weblate commits instead of the breaking PR commits.