Diagnosing Weblate Repository Synchronization Failures When Translations Are Not Pulled

Recognizable condition

You have a Weblate component linked to a Git repository. New commits pushed to the repository never appear as translation suggestions or updated strings in the Weblate UI. The activity log shows no “Pull repository” entries, and manual pulls from the component page also return no changes.

Short cause/diagnostic table

Possible cause	What to look for
(a) Incorrect VCS URL or branch in component settings	The URL points to a different repository or the branch does not exist.
(b) Missing or invalid SSH key/token credentials	Authentication fails when Weblate tries to clone or fetch.
(c) Celery worker not running	Background tasks that perform pulls are idle or stopped.
(d) Pull/push schedule disabled or set to manual	Component is configured to wait for a manual trigger only.
(e) Server‑side hooks blocking Weblate's access	Pre‑receive or update hooks reject the push/fetch from Weblate’s IP or key.

Ordered checks

1. Verify component settings → Source code repository URL and branch
   1. Log in to Weblate as an administrator.
   2. Navigate to Components → <your component> → Source code repository.
   3. Confirm that the Repository URL matches the exact Git remote (e.g., [contact removed]:org/project.git or https://github.com/org/project.git) and that the Branch field contains an existing branch name (commonly main or master).
   4. If the URL uses SSH, ensure the hostname matches the key you have configured; if it uses HTTPS, verify that the token or username/password is correct.
2. Test SSH/HTTP credentials via Weblate admin → “Test repository credentials”
   1. On the same component settings page, click the Test repository credentials button.
   2. Weblate will attempt a clone/fetch and report success or failure.
   3. Note any error messages (e.g., Permission denied (publickey), Host key verification failed, or 401 Unauthorized).
3. Check Celery worker status
   1. SSH to the server hosting Weblate (you need a user with sudo privileges, typically the weblate system user).
   2. Run:

   celery -A weblate worker status

   3. Expected output includes lines like celery@host ready and a count of active processes. If you see Node: ... down or no output, the worker is not running.
   4. Risk: Restarting the worker will interrupt any ongoing translation tasks; schedule this during low‑usage periods.
4. Review component's “Pull” and “Push” schedule in component settings
   1. In the component’s Repository maintenance tab, locate the Pull interval and Push interval fields.
   2. Ensure they are not set to Manual or 0 (disabled). A typical automated interval is 15 minutes.
   3. If you intend to rely on automatic sync, set a non‑zero value and save.
5. Inspect Weblate logs for authentication or network errors
   1. Log files are usually located at /var/log/weblate/celery.log (worker) and /var/log/weblate/error.log (Django).
   2. Use tail -f or grep to look for recent entries around the time you attempted a manual pull:

   grep -i "pull\|auth\|ssh" /var/log/weblate/celery.log | tail -20

   3. Typical problematic lines include:
   • ERROR: Repository error: [Errno 13] Permission denied
   • WARNING: Failed to fetch from remote: Host key verification failed
   • INFO: Pull repository completed successfully
   4. If you see repeated authentication failures despite correct credentials, the issue may be with the stored key or token.

Fixes tied to findings

• URL/branch mismatch – Edit the component, correct the Repository URL and/or Branch fields, then click Save. After saving, trigger a manual pull (Repository → Pull) to verify that new commits appear.
• Credentials fail – In the component’s Access control tab, regenerate the SSH key or update the API token. Use the Test repository credentials button again until it reports success. Remember to store the private key only in Weblate’s credential vault; never copy it into logs or comments.
• Celery worker down – Restart the worker:

sudo systemctl restart weblate-celery

Then re‑run celery -A weblate worker status to confirm it shows ready. Monitor celery.log for the next pull task.

• Schedule disabled – Change the Pull interval to a suitable value (e.g., 15) and save. Weblate will schedule the next pull automatically; you can also force an immediate pull to confirm the setting took effect.
• Server‑side hooks blocking access – Contact the repository administrator to examine any pre-receive, update, or push hooks. If Weblate’s key or IP is being rejected, either adjust the hook to allow Weblate’s credentials or disable the hook for the Weblate deploy key (only if your security policy permits). After hook changes, test credentials again.

Escalation criteria

Escalate to a system administrator if:

• After applying the relevant fix, the component still shows no activity for more than 30 minutes.
• Logs continue to show authentication errors even though credentials have been validated externally (e.g., you can clone the repository manually with the same key/token).
• Multiple components across different projects exhibit the same symptom, suggesting a platform‑wide issue such as a broken Celery broker (Redis/RabbitMQ) or network firewall blocking outbound Git traffic.

Verification

1. From the component page, click Repository → Pull (manual trigger).
2. Wait up to the pull interval (or a few minutes if manual) and check the activity log for a Pull repository entry with a timestamp matching your trigger.
3. Open the Translations view and confirm that newly committed strings appear as suggestions or are already translated according to your workflow.
4. If you rely on automatic sync, wait for the next scheduled interval and verify that subsequent commits are reflected without further manual action.

Example scenario

Suppose a component is configured with:

• Repository URL: [contact removed]:example/docs.git
• Branch: staging
• Pull interval: Manual
• SSH key stored in Weblate under the deploy key “weblate‑gitlab”.

After a commit to staging, no suggestions appear. Following the ordered checks:

1. The URL and branch are correct.
2. Testing credentials fails with Permission denied (publickey).
3. Celery worker is running (celery -A weblate worker status shows active).
4. Schedule is manual (identified in step 4).
5. Logs show the same permission error.

The fix is to regenerate the deploy key in GitLab, copy the new public key into Weblate’s credential store, and retest. After success, change the Pull interval to 15 minutes and save. A subsequent manual pull shows the new commit as a suggestion, confirming the fix.