Version control integration (2024)

Accessing repositories from Hosted Weblate¶

For Hosted Weblate, there is a dedicated push user registered on GitHub,Bitbucket, Codeberg, and GitLab (with the username weblate, e-mailhosted@weblate.org, and a name or profile description Weblate push user).

You need to add this user as a collaborator and give it appropriate permissions to yourrepository (read-only is okay for cloning, write is required for pushing).Depending on the service and your organization’s settings, this happens immediately,or requires confirmation on the Weblate side.

The weblate user on GitHub accepts invitations automatically within five minutes.Manual processing might be needed on the other services, so please be patient.

Once the weblate user is added to your repository, you can configureSource code repository and Repository push URL using the SSH protocol (for examplegit@github.com:WeblateOrg/weblate.git).

Accessing repositories on code hosting sites (GitHub, GitLab, Bitbucket, Azure DevOps, …)¶

Accessing repositories on code hosting sites is typically done by creating adedicated user who is associated with a Weblate SSH key (seeWeblate SSH key). This way you associate Weblate SSH key with a singleuser (this of frequently enforced by the platform) and grant this user accessto the repository. You can then use SSH URL to access the repository (seeSSH repositories).

SSH repositories¶

The most frequently used method to access private repositories is based on SSH.Authorize the public Weblate SSH key (see Weblate SSH key) to access the upstreamrepository this way.

Weblate also stores the host key fingerprint upon first connection, and fails toconnect to the host should it be changed later (see Verifying SSH host keys).

In case adjustment is needed, do so from the Weblate admin interface:

Verifying SSH host keys¶

Weblate automatically stores the SSH host keys on first access and remembersthem for further use.

In case you want to verify the key fingerprint before connecting to therepository, add the SSH host keys of the servers you are going to access inAdd host key, from the same section of the admin interface. Enterthe hostname you are going to access (e.g. gitlab.com), and pressSubmit. Verify its fingerprint matches the server you added.

The added keys with fingerprints are shown in the confirmation message:

no matching host key type found. Their offer: ssh-rsa

Host legacy-host HostkeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms +ssh-rsa

GitHub repositories¶

Access via SSH is possible (see SSH repositories), but in case you need toaccess more than one repository, you will hit a GitHub limitation on allowedSSH key usage (since each key can be used only once).

In case the Push branch is not set, the project is forked andchanges pushed through a fork. In case it is set, changes are pushed to theupstream repository and chosen branch.

For smaller deployments, use HTTPS authentication with a personal accesstoken and your GitHub account, see Creating an access token for command-line use.

For bigger setups, it is usually better to create a dedicated user for Weblate,assign it the public SSH key generated in Weblate (see Weblate SSH key)and grant it access to all the repositories you want to translate. Thisapproach is also used for Hosted Weblate, there is dedicatedweblate user for that.

Weblate internal URLs¶

Share one repository setup between different components by referring toits placement as weblate://project/component in other(linked) components. This way linked componentsuse the VCS repository configuration of the main(referenced) component.

Weblate automatically adjusts the repository URL when creating a component if itfinds a component with a matching repository setup. You can override this inthe last step of the component configuration.

Reasons to use this:

• Saves disk space on the server, the repository is stored just once.

• Makes the updates faster, only one repository is updated.

• There is just single exported repository with Weblate translations (see Git exporter).

• Some add-ons can operate on multiple components sharing one repository, for example Squash Git commits.

HTTPS repositories¶

To access protected HTTPS repositories, include the username and passwordin the URL. Don’t worry, Weblate will strip this info when the URL is shownto users (if even allowed to see the repository URL at all).

For example the GitHub URL with authentication added might look like:https://user:your_access_token@github.com/WeblateOrg/weblate.git.

Using proxy¶

If you need to access HTTP/HTTPS VCS repositories using a proxy server,configure the VCS to use it.

This can be done using the http_proxy, https_proxy, and all_proxyenvironment variables, (as described in the cURL documentation)or by enforcing it in the VCS configuration, for example:

git config --global http.proxy http://user:password@proxy.example.com:80

Git with force push¶

This behaves exactly like Git itself, the only difference being that it alwaysforce pushes. This is intended only in the case of using a separate repositoryfor translations.

Customizing Git configuration¶

Weblate invokes all VCS commands with HOME=$DATA_DIR/home (seeDATA_DIR), therefore editing the user configuration needs to be donein DATA_DIR/home/.git.

Git remote helpers¶

You can also use Git remote helpers for additionally supporting other versioncontrol systems, but be prepared to debug problems this may lead to.

At this time, helpers for Bazaar and Mercurial are available within separaterepositories on GitHub: git-remote-hg and git-remote-bzr.Download them manually and put somewhere in your search path(for example ~/bin). Make sure you have the corresponding version controlsystems installed.

Once you have these installed, such remotes can be used to specify a repositoryin Weblate.

To clone the gnuhello project from Launchpad using Bazaar:

bzr::lp:gnuhello

For the hello repository from selenic.com using Mercurial:

hg::http://selenic.com/repo/hello

Subversion credentials¶

Weblate expects you to have accepted the certificate up-front (and yourcredentials if needed). It will look to insert them into the DATA_DIRdirectory. Accept the certificate by using svn once with the $HOMEenvironment variable set to the DATA_DIR:

# Use DATA_DIR as configured in Weblate settings.py, it is /app/data in the DockerHOME=${DATA_DIR}/home svn co https://svn.example.com/example