Налаштування інтеграції із керуванням версіями¶
Weblate currently supports Git (with extended support for GitHub, Gerrit and Subversion) and Mercurial as version control backends.
Доступ до сховищ¶
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¶
For Hosted Weblate there is a dedicated push user registered on GitHub, Bitbucket, Codeberg and GitLab (with username weblate 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 from Weblate side.
Запрошення на GitHub приймаються автоматично протягом п’яти хвилин. У інших службах може знадобитися обробка вручну, тому, будь ласка, майте терпіння.
Once the weblate user is added, you can configure
Сховище з джерелами and Адреса для записування до сховища using SSH protocol (for example
git@github.com:WeblateOrg/weblate.git
).
Сховища із доступом за SSH¶
The most frequently used method to access private repositories is based on SSH. Authorize the public Weblate SSH key (see Ключ SSH Weblate) to access the upstream repository this way.
Попередження
On GitHub, each key can be added to only one repository, see Сховища GitHub and Доступ до сховищ з Hosted Weblate.
Weblate also stores the host key fingerprint upon first connection, and fails to connect to the host should it be changed later (see Перевірка ключів SSH вузла).
Якщо потрібні якісь коригування, виконайте їх за допомогою адміністративного інтерфейсу Weblate:
Ключ SSH Weblate¶
Відкритий ключ Weblate доступний до перегляду усіма користувачами на сторінці Про програму.
Admins can generate or display the public key currently used by Weblate in the (from SSH keys) on the admin interface landing page.
Примітка
У поточній версії відповідний закритий ключ SSH не захищено паролем, тому вам слід переконатися, що його добре захищено.
Підказка
Make a backup of the generated private Weblate SSH key.
Перевірка ключів SSH вузла¶
Weblate автоматично запам’ятовує ключів SSH вузла при першому доступі і використовує їх у подальшому.
In case you want to verify them before connecting to the repository, verify 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. They are shown in the
confirmation message:
Сховища GitHub¶
Access via SSH is possible (see Сховища із доступом за SSH), but in case you need to access more than one repository, you will hit a GitHub limitation on allowed SSH key usage (since one key can be used only for one repository).
In case the Гілка для запису 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 Ключ SSH Weblate) 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.
Дивись також
Внутрішні адреси Weblate¶
To share one repository between different components you can use a special URL
like weblate://project/component
. This way, the component will share the
VCS repository configuration with the referenced component
(project/component
in the example).
Weblate automatically adjusts repository URL when creating component when it finds component with matching repository setup. You can override this in last step of component configuration.
Reasons to use this:
Заощаджує місце на диску сервера — сховище зберігається лише один раз.
Пришвидшує оновлення — оновлюється лише одне сховище.
There is just single exported repository with Weblate translations (see Засіб експортування Git).
Some addons can operate on more components sharing single repository, for example Сполучити Git подання.
Сховища HTTPS¶
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
.
Примітка
If you username or password contains special characters, those have to be
URL encoded, for example
https://user%40example.com:%24password%23@bitbucket.org/…
.
Використання проксі-сервера¶
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
Примітка
The proxy configuration needs to be done under user running Weblate (see
also Права доступу у файловій системі) and with HOME=$DATA_DIR/home
(see
DATA_DIR
), otherwise Git executed by Weblate will not use it.
Дивись також
Git¶
Дивись також
Див. розділ Доступ до сховищ, щоб дізнатися більше про доступ до сховищ різних типів.
Git з примусовим «push»¶
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.
Попередження
Будьте обережні із використанням, оскільки так можна дуже просто втратити внески до вашого основного сховища.
Налаштовування Git¶
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
.
Git remote helpers¶
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.
Клонування проєкту gnuhello
з Launchpad за допомогою Bazaar:
bzr::lp:gnuhello
For the hello
repository from selenic.com using Mercurial:
hg::http://selenic.com/repo/hello
Попередження
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¶
Нове в версії 2.3.
This adds a thin layer atop Git using the hub tool to allow pushing translation changes as pull requests, instead of pushing directly to the repository.
Git pushes changes directly to a repository, while GitHub creates pull requests. The latter is not needed for merely accessing Git repositories.
Дивись також
Записування змін до GitHub у формі запитів щодо об’єднання¶
If not wanting to push translations to a GitHub repository, they can be sent as either one or many pull requests instead.
Дивись також
GITHUB_USERNAME
, Налаштовування концентратора — настанови з налаштовування
Налаштовування концентратора¶
Записування змін до GitHub у формі запитів щодо об’єднання requires a configured hub installation on your server. Follow the installation instructions at https://hub.github.com/ use hub to finish the configuration, for example:
# Use DATA_DIR as configured in Weblate settings.py, it is /app/data in the Docker
HOME=${DATA_DIR}/home hub clone octocat/Spoon-Knife
The hub will ask you for your GitHub credentials, retrieve a token and store
it in ~/.config/hub
. This file has to be readable by the user running
Weblate.
Примітка
Use the username you configured hub with, as
GITHUB_USERNAME
(WEBLATE_GITHUB_USERNAME
for the
Docker image).
GitLab¶
Нове в версії 3.9.
This just adds a thin layer atop Git using the lab tool to allow pushing translation changes as merge requests instead of pushing directly to the repository.
There is no need to use this 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 creates merge request.
Дивись також
Записування змін до GitLab у формі запитів щодо злиття¶
If not wanting to push translations to a GitLab repository, they can be sent as either one or many merge requests instead.
Configure the lab command line tool and set GITLAB_USERNAME
for this to work.
Дивись також
GITLAB_USERNAME
, Налаштовування Lab щодо настанов з налаштовування
Налаштовування Lab¶
Записування змін до GitLab у формі запитів щодо злиття requires a configured lab installation on your server. Follow the installation instructions at lab and run it without any arguments to finish the configuration, for example:
# Use DATA_DIR as configured in Weblate settings.py, it is /app/data in the Docker
$ HOME=${DATA_DIR}/home lab
Enter GitLab host (default: https://gitlab.com):
Create a token here: https://gitlab.com/profile/personal_access_tokens
Enter default GitLab token (scope: api):
(Config is saved to ~/.config/lab.hcl)
The lab will ask you for your GitLab access token, retrieve it and
store it in ~/.config/lab.hcl
. The file has to be readable by
the user running Weblate.
Примітка
Use the username you configured lab with, as
GITLAB_USERNAME
(WEBLATE_GITLAB_USERNAME
for the
Docker image).
Gerrit¶
Нове в версії 2.2.
Adds a thin layer atop Git using the git-review tool to allow pushing translation changes as Gerrit review requests, instead of pushing a directory to the repository.
The Gerrit documentation has the details on the configuration necessary to set up such repositories.
Mercurial¶
Нове в версії 2.1.
Mercurial is another VCS you can use directly in Weblate.
Примітка
It should work with any Mercurial version, but there are sometimes incompatible changes to the command-line interface which breaks Weblate integration.
Дивись також
Див. розділ Доступ до сховищ, щоб дізнатися більше про доступ до сховищ різних типів.
Subversion¶
Нове в версії 2.8.
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.
Примітка
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 foud 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: Before this, there was only support for standard layout repositories.
Реєстраційні дані Subversion¶
Weblate expects you to have accepted the certificate up-front and if needed, your credentials. 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
Дивись також
Локальні файли¶
Нове в версії 3.8.
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.