Sürüm denetimi bütünleştirmesi
Weblate currently supports Git (with extended support for GitHub çekme istekleri, GitLab birleştirme istekleri, Gitea çekme isteği, Gerrit, Subversion and Bitbucket sunucusu çekme isteği) and Mercurial as version control back-ends.
Depolara erişmek
The VCS repository you want to use has to be accessible to Weblate. With a
publicly available repository you just need to enter the correct URL (for
example https://github.com/WeblateOrg/weblate.git), but for private
repositories or for push URLs the setup is more complex and requires
authentication.
Hosted Weblate üzerinden depolara erişmek
For Hosted Weblate there is a dedicated push user registered on GitHub,
Bitbucket, Codeberg and GitLab (with the username weblate, e-mail
hosted@weblate.org and, named Weblate push user). You need to
add this user as a collaborator and give it appropriate permission to your
repository (read-only is okay for cloning, write is required for pushing).
Depending on service and your organization 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, you can configure
Kaynak kod deposu and Depo itme adresi using the SSH protocol (for example
git@github.com:WeblateOrg/weblate.git).
SSH depoları
The most frequently used method to access private repositories is based on SSH. Authorize the public Weblate SSH key (see Weblate SSH anahtarı) to access the upstream repository this way.
Uyarı
On GitHub, each key can only be used once, see GitHub depoları and Hosted Weblate üzerinden depolara erişmek.
Weblate also stores the host key fingerprint upon first connection, and fails to connect to the host should it be changed later (see SSH sunucu anahtarlarını doğrulamak).
In case adjustment is needed, do so from the Weblate admin interface:
Weblate SSH anahtarı
The Weblate public key is visible to all users browsing the About page.
Admins can generate or display the public key currently used by Weblate in the connection (from SSH keys) on the admin interface landing page.
Not
The corresponding private SSH key can not currently have a password, so make sure it is well protected.
İpucu
Make a backup of the generated private Weblate SSH key.
SSH sunucu anahtarlarını doğrulamak
Weblate automatically stores the SSH host keys on first access and remembers them for further use.
In case you want to verify the key fingerprint before connecting to the
repository, add the SSH host keys of the servers you are going to access in
Add host key, from the same section of the admin interface. Enter
the hostname you are going to access (e.g. gitlab.com), and press
Submit. Verify its fingerprint matches the server you added.
The added keys with fingerprints are shown in the confirmation message:
GitHub depoları
Access via SSH is possible (see SSH depoları), but in case you need to access more than one repository, you will hit a GitHub limitation on allowed SSH key usage (since each key can be used only once).
In case the İtme işleminin yapılacağı dal is not set, the project is forked and changes pushed through a fork. In case it is set, changes are pushed to the upstream repository and chosen branch.
For smaller deployments, use HTTPS authentication with a personal access token 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 anahtarı) and grant it access to all the repositories you want to translate. This approach is also used for Hosted Weblate, there is dedicated weblate user for that.
Ayrıca bakınız
İç Weblate adresleri
Share one repository setup between different components by referring to
its placement as weblate://project/component in other(linked) components. This way linked components
use the VCS repository configuration of the main(referenced) component.
Uyarı
Removing main component also removes linked components.
Weblate automatically adjusts the repository URL when creating a component if it finds a component with a matching repository setup. You can override this in the last step of the component configuration.
Bunu kullanma nedenleri:
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 Git işlemelerini bir araya toplar.
HTTPS depoları
To access protected HTTPS repositories, include the username and password in the URL. Don’t worry, Weblate will strip this info when the URL is shown to 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.
Not
If your username or password contains special characters, those have to be
URL encoded, for example
https://user%40example.com:%24password%23@bitbucket.org/….
Vekil sunucu kullanmak
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_proxy
environment 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
Not
The proxy configuration needs to be done under user running Weblate (see
also Dosya sistemi izinleri) and with HOME=$DATA_DIR/home (see
DATA_DIR), otherwise Git executed by Weblate will not use it.
Ayrıca bakınız
Git
İpucu
Weblate needs Git 2.12 or newer.
Ayrıca bakınız
See Depolara erişmek for info on how to access different kinds of repositories.
Git (itme dayatması ile)
This behaves exactly like Git itself, the only difference being that it always force pushes. This is intended only in the case of using a separate repository for translations.
Uyarı
Use with caution, as this easily leads to lost commits in your upstream repository.
Git yapılandırmasını özelleştirmek
Weblate invokes all VCS commands with HOME=$DATA_DIR/home (see
DATA_DIR), therefore editing the user configuration needs to be done
in DATA_DIR/home/.git.
Uzak Git yardımcıları
You can also use Git remote helpers for additionally supporting other version control systems, but be prepared to debug problems this may lead to.
At this time, helpers for Bazaar and Mercurial are available within separate
repositories 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 control
systems installed.
Once you have these installed, such remotes can be used to specify a repository in 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
Uyarı
The inconvenience of using Git remote helpers is for example with Mercurial, the remote helper sometimes creates a new tip when pushing changes back.
GitHub çekme istekleri
2.3 sürümünde geldi.
This adds a thin layer atop Git using the GitHub API to allow pushing translation changes as pull requests, instead of pushing directly to the repository.
Git pushes changes directly to a repository, while GitHub çekme istekleri creates pull requests. The latter is not needed for merely accessing Git repositories.
You need to configure API credentials (GITHUB_CREDENTIALS) in the
Weblate settings to make this work. Once configured, you will see a
GitHub option when selecting Sürüm denetimi sistemi.
Ayrıca bakınız
GitLab birleştirme istekleri
3.9 sürümünde geldi.
This just adds a thin layer atop Git using the GitLab API to allow pushing translation changes as merge requests instead of pushing directly to the repository.
There is no need to use this to access Git repositories, ordinary Git works the same, the only difference is how pushing to a repository is handled. With Git changes are pushed directly to the repository, while GitLab birleştirme istekleri creates merge request.
You need to configure API credentials (GITLAB_CREDENTIALS) in the
Weblate settings to make this work. Once configured, you will see a
GitLab option when selecting Sürüm denetimi sistemi.
Ayrıca bakınız
Gitea çekme isteği
4.12 sürümünde geldi.
This just adds a thin layer atop Git using the Gitea API to allow pushing translation changes as pull requests instead of pushing directly to the repository.
There is no need to use this to access Git repositories, ordinary Git works the same, the only difference is how pushing to a repository is handled. With Git changes are pushed directly to the repository, while Gitea çekme isteği creates pull requests.
You need to configure API credentials (GITEA_CREDENTIALS) in the
Weblate settings to make this work. Once configured, you will see a
Gitea option when selecting Sürüm denetimi sistemi.
Ayrıca bakınız
Bitbucket sunucusu çekme isteği
4.16 sürümünde geldi.
This just adds a thin layer atop Git using the Bitbucket Server API to allow pushing translation changes as pull requests instead of pushing directly to the repository.
Uyarı
This does not support Bitbucket Cloud API.
There is no need to use this to access Git repositories, ordinary Git works the same, the only difference is how pushing to a repository is handled. With Git changes are pushed directly to the repository, while Bitbucket sunucusu çekme isteği creates pull request.
You need to configure API credentials (BITBUCKETSERVER_CREDENTIALS) in the
Weblate settings to make this work. Once configured, you will see a
Bitbucket Server option when selecting Sürüm denetimi sistemi.
Ayrıca bakınız
Weblate üzerindeki değişiklikleri itmek,
BITBUCKETSERVER_CREDENTIALS
Pagure birleştirme istekleri
4.3.2 sürümünde geldi.
This just adds a thin layer atop Git using the Pagure API to allow pushing translation changes as merge requests instead of pushing directly to the repository.
There is no need to use this to access Git repositories, ordinary Git works the same, the only difference is how pushing to a repository is handled. With Git changes are pushed directly to the repository, while Pagure birleştirme istekleri creates merge request.
You need to configure API credentials (PAGURE_CREDENTIALS) in the
Weblate settings to make this work. Once configured, you will see a
Pagure option when selecting Sürüm denetimi sistemi.
Ayrıca bakınız
Gerrit
2.2 sürümünde geldi.
Adds a thin layer atop Git using the git-review tool to allow pushing translation changes as Gerrit review requests, instead of pushing them directly to the repository.
The Gerrit documentation has the details on the configuration necessary to set up such repositories.
Mercurial
2.1 sürümünde geldi.
Mercurial is another VCS you can use directly in Weblate.
Not
It should work with any Mercurial version, but there are sometimes incompatible changes to the command-line interface which breaks Weblate integration.
Ayrıca bakınız
See Depolara erişmek for info on how to access different kinds of repositories.
Subversion
2.8 sürümünde geldi.
Weblate uses git-svn to interact with subversion repositories. It is a Perl script that lets subversion be used by a Git client, enabling users to maintain a full clone of the internal repository and commit locally.
Not
Weblate tries to detect Subversion repository layout automatically - it supports both direct URLs for branch or repositories with standard layout (branches/, tags/ and trunk/). More info about this is to be found in the git-svn documentation. If your repository does not have a standard layout and you encounter errors, try including the branch name in the repository URL and leaving branch empty.
2.19 sürümünde değişti: Before this, only repositories using the standard layout were supported.
Subversion kimlik doğrulama bilgileri
Weblate expects you to have accepted the certificate up-front (and your
credentials if needed). It will look to insert them into the DATA_DIR
directory. Accept the certificate by using svn once with the $HOME
environment variable set to the DATA_DIR:
# Use DATA_DIR as configured in Weblate settings.py, it is /app/data in the Docker
HOME=${DATA_DIR}/home svn co https://svn.example.com/example
Ayrıca bakınız
Yerel dosyalar
Git
İpucu
Underneath, this uses Git. It requires Git installed and allows you to switch to using Git natively with full history of your translations.
3.8 sürümünde geldi.
Weblate can also operate without a remote VCS. The initial translations are imported by uploading them. Later you can replace individual files by file upload, or add translation strings directly from Weblate (currently available only for monolingual translations).
In the background Weblate creates a Git repository for you and all changes are tracked in. In case you later decide to use a VCS to store the translations, you already have a repository within Weblate can base your integration on.