Verziókezelő integráció¶
Weblate currently supports Git (with extended support for GitHub módosítási kérelmek (pull request), GitLab egyesítési kérelmek (merge request), Gitea módosítási kérelmek (pull request), Gerrit review requests, Subversion, Bitbucket Cloud módosítási kérelmek (pull request), Bitbucket Data Center módosítási kérelmek (pull request), and Azure DevOps egyesítési kérelmek (pull request)) and Mercurial as version control back-ends.
For provider-specific setup steps that combine repository access, incoming notifications, and pushing translations back, see Code-hosting integrations.
Tárolók elérése¶
A használni kívánt VCS-tárolónak elérhetőnek kell lennie a Weblate számára. Nyilvános tároló esetén elegendő a megfelelő URL megadása (például: https://github.com/WeblateOrg/weblate.git), de privát tárolók vagy feltöltési URL-ek esetén a beállítás összetettebb, és hitelesítést igényel.
Troubleshooting repository URLs¶
Weblate validates repository and push URLs before connecting. HTTPS and SSH
are permitted by default; instance administrators can adjust this using
VCS_ALLOW_SCHEMES.
Repository hostnames have to resolve from the Weblate server. When
VCS_RESTRICT_PRIVATE is enabled, Weblate also rejects destinations
which resolve to internal or otherwise non-public addresses. Use a publicly
reachable repository URL where possible. For an intentionally private
repository on a trusted network, ask the instance administrator to add its
hostname to VCS_ALLOW_HOSTS.
Git over HTTPS and SSH can bind connections to addresses approved during
validation. Backends which cannot do this safely, including Mercurial and
Subversion, require the trusted repository hostname in
VCS_ALLOW_HOSTS while private-address restrictions are enabled.
Configure the final repository URL directly when possible. Weblate can automatically accept a permanent HTTP redirect only when it stays on the same host and the target is successfully validated. Redirects to another host or protocol have to be configured manually.
Tárolók elérése a Hosted Weblate szolgáltatásból¶
Megjegyzés
This section applies only to Hosted Weblate (hosted.weblate.org). If you are running your own self-hosted Weblate instance, please see the next section instead.
For GitHub repositories on Hosted Weblate, use the Hosted Weblate app from Weblate’s Connect GitHub account flow whenever possible. The App grants repository access, receives incoming notifications, pushes translation branches, and creates pull requests without inviting the Hosted Weblate weblate user. See GitHub repository access for the full setup.
For direct SSH access outside the GitHub App workflow, and for Bitbucket,
Codeberg, and GitLab repositories, Hosted Weblate has a dedicated push user
(with the username weblate, e-mail hosted@weblate.org, and a
name or profile description Weblate push user).
Tipp
Több Weblate-felhasználó is előfordulhat ezeken a platformokon, amelyek más Weblate-példányokhoz tartoznak. Ajánlott a hosted@weblate.org e-mail cím alapján keresni a Hosted Weblate helyes felhasználójának megtalálásához.
A felhasználót hozzá kell adnia a tárolóhoz, mint együttműködőt, és a megfelelő jogosultságokat is biztosítani kell számára (a klónozáshoz elég az olvasási jog, a feltöltéshez írási jog szükséges). A szolgáltatótól és a szervezet beállításaitól függően ez azonnal megtörténik vagy a Weblate oldalon visszaigazolás szükséges.
The weblate user on GitHub accepts invitations automatically within five minutes when you intentionally use direct SSH access there. Manual processing might be needed on the other services, so please be patient.
For this direct SSH-user setup, once the weblate user is added to
your repository, you can configure Forráskód tároló and
Tároló feltöltési URL using the SSH protocol, for example
git@example.com:group/project.git.
Accessing repositories on code-hosting sites (GitHub, GitLab, Bitbucket, Azure DevOps, …)¶
Megjegyzés
This section applies to self-hosted Weblate instances. If you are using Hosted Weblate (hosted.weblate.org), see Tárolók elérése a Hosted Weblate szolgáltatásból instead.
For self-hosted Weblate, a single private repository is often easiest to set up using an HTTPS repository URL with an access token, see Code-hosting integrations.
For multiple repositories, create a dedicated code-hosting user associated with a Weblate SSH key (see Weblate SSH-kulcs). This way you associate Weblate SSH key with a single user, because platforms frequently enforce single use of an SSH key. Grant this user access to the repositories, and use SSH URLs to access them (see SSH-tárolók).
SSH-tárolók¶
One common method to access private repositories is based on SSH. Authorize the public Weblate SSH key (see Weblate SSH-kulcs) to access the upstream repository this way.
Figyelem
On GitHub, each key can only be used once, see GitHub repository access and Tárolók elérése a Hosted Weblate szolgáltatásból.
A Weblate az első csatlakozáskor elmenti a kiszolgáló kulcsának ujjlenyomatát, és a kapcsolat meghiúsul, ha az később megváltozik (lásd: SSH kiszolgálókulcsok ellenőrzése).
Ha módosítás szükséges, azt a Weblate adminisztrációs felületéről lehet elvégezni:
Weblate SSH-kulcs¶
A 4.17 verzióban változott: A Weblate mostantól RSA és Ed25519 típusú SSH-kulcsokat is generál. Új telepítés esetén az Ed25519 használata javasolt.
A Weblate nyilvános kulcsa minden felhasználó számára látható a Névjegy oldalon.
A rendszergazdák az adminisztrációs felület kezdőoldalán, az SSH kulcsok menüpontból generálhatják vagy megtekinthetik a Weblate által jelenleg használt nyilvános kulcsot.
Megjegyzés
A hozzátartozó privát SSH-kulcs jelenleg nem lehet jelszóval védett, ezért gondoskodjon megfelelő biztonságról.
Tipp
Készítsen biztonsági mentést a generált Weblate privát SSH-kulcsról.
SSH kiszolgálókulcsok ellenőrzése¶
A Weblate az első eléréskor automatikusan elmenti az SSH kiszolgálókulcsot és később is ezeket használja.
When VCS_RESTRICT_PRIVATE is enabled, Weblate resolves and validates
the repository host before scanning its key and connects ssh-keyscan only
to the approved addresses. The stored key remains associated with the original
hostname.
For Git connections, Weblate also applies HostName and Port from
DATA_DIR/ssh/config before validating and pinning the effective
destination. SSH configuration and SSH_EXTRA_ARGS are trusted
administrator-controlled inputs. They can alter connection routing, and
SSH_EXTRA_ARGS can override Weblate’s address pinning;
administrators are responsible for their effects.
Ha előre ellenőrizni szeretné a kulcs ujjlenyomatát, a hozzáférni kívánt szerver SSH-kulcsait adja hozzá az adminfelületen található Kiszolgálókulcs hozzáadása menüpontban. Adja meg a hozzáférendő kiszolgáló nevét (pl. gitlab.com), majd kattintson a Küldés gombra. Ellenőrizze, hogy az ujjlenyomat egyezik-e a szerverével.
A hozzáadott kulcsok és ujjlenyomataik a visszaigazoló üzenetben jelennek meg:
Kapcsolódás régi SSH-kiszolgálókhoz¶
Az OpenSSH legutóbbi kiadásai (például a Weblate Docker-konténerben használt verzió) alapértelmezetten letiltják az RSA-aláírásokat, amelyek a SHA-1 kivonatoló algoritmust használják. Erre a módosításra azért került sor, mert a SHA-1 algoritmus kriptográfiailag nem biztonságos: már lehetséges előre meghatározott előtaggal rendelkező kivonatütközéseket létrehozni, körülbelül 50 000 USD költséggel.
A legtöbb felhasználó számára ez a változás nem lesz észrevehető, és nincs szükség az ssh-rsa kulcsok cseréjére. Az OpenSSH a 7.2-es kiadástól kezdve támogatja az RFC8332 szerinti RSA/SHA-256/512 aláírásokat, így az ssh-rsa kulcsok automatikusan az erősebb algoritmust használják, ha lehetséges.
Kompatibilitási probléma akkor léphet fel, ha elavult SSH-implementációhoz csatlakozik, amely nem lett frissítve vagy nem követi szorosan a protokoll fejlődését. Az ilyen szerverhez való SSH-kapcsolat hibával megszakad:
no matching host key type found. Their offer: ssh-rsa
Ilyen esetekben szükség lehet az RSA/SHA1 támogatásának szelektív visszaengedélyezésére, hogy a kapcsolatfelvétel és/vagy a felhasználó hitelesítése lehetővé váljon a HostkeyAlgorithms és PubkeyAcceptedAlgorithms beállítások segítségével. Például az alábbi bejegyzés a DATA_DIR/ssh/config fájlban engedélyezi az RSA/SHA1 használatát kiszolgáló- és felhasználói hitelesítéshez egyetlen célállomás esetében:
Host legacy-host
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
Javasoljuk, hogy az RSA/SHA1 engedélyezése csak átmeneti megoldás legyen, amíg a régi rendszerek frissítése vagy más kulcstípusra (pl. ECDSA vagy Ed25519) való áttérés meg nem történik.
GitHub tárolók¶
Detailed GitHub repository access is covered in GitHub repository access.
GitLab repositories¶
Detailed GitLab repository access is covered in GitLab repository access.
Weblate belső URL-ek¶
Egy tárolóbeállítás megosztható több összetevő között is, ha annak helyét weblate://projekt/összetevő formában adja meg a hivatkozott (összekapcsolt) összetevőkben. Így ezek az összetevők a hivatkozott főösszetevő VCS-beállításait használják.
Figyelem
A főösszetevő törlése esetén a hivatkozott összetevők is törlésre kerülnek.
Linked components share the complete repository checkout; the link does not isolate them to particular files or directories. Users allowed to administer a linked component can configure operations affecting files anywhere in the shared checkout. For example, they can change file masks, formats, and templates, or install and configure add-ons that read, generate, or modify repository files. Weblate can commit and push resulting changes using the main component’s repository configuration.
Only link components when the repository owner trusts the administrators of every linked component with the complete checkout. Use separate repositories when components require file-level isolation.
A Weblate automatikusan beállítja a tároló URL-jét, ha összetevő létrehozásakor talál egy másik, azonos tárolóra beállított összetevőt. Ez a beállítás felülírható az összetevő konfigurációjának utolsó lépésében.
Ennek előnyei:
Tárhelyet takarít meg a szerveren, mivel a tároló csak egyszer kerül mentésre.
Gyorsabb frissítések, mivel csak egy tárolót kell frissíteni.
Csak egyetlen exportált tároló van a Weblate-fordításokkal (lásd: Git exportáló).
Bizonyos kiegészítők több összetevőn is működnek, ha ugyanazt a tárolót használják – például: Git véglegesítések összevonása.
HTTPS tárolók¶
Védett HTTPS-tárolókhoz való hozzáféréshez adja meg a felhasználónevet és jelszót az URL-ben. Nem kell aggódni, a Weblate eltávolítja ezeket az adatokat a megjelenített URL-ből (ha a felhasználó egyáltalán láthatja azt).
Például egy GitHub URL hitelesítéssel így nézhet ki: https://user:your_access_token@github.com/WeblateOrg/weblate.git.
In case you don’t provide credentials in the URL and the repository requires it, Git will fail with an error:
fatal: could not read Username for 'https://github.com': terminal prompts disabled
A 5.10.2 verzióban változott: A Weblate proaktív hitelesítést alkalmaz a Git 2.46.0 és újabb verziókkal, ha HTTP-hitelesítési adatok vannak megadva.
Ez lehetővé teszi például az Azure DevOps tárolók elérését, illetve gyorsabbá teszi a hitelesített tárolókhoz való hozzáférést.
Megjegyzés
Ha a felhasználónév vagy jelszó speciális karaktereket tartalmaz, azokat URL-kódolni kell, például: https://user%40example.com:%24password%23@bitbucket.org/….
Proxy használata¶
If you need to access Git repositories over HTTPS using a proxy server, configure the per-protocol environment variables described in HTTP proxy.
Version control parameters¶
Added in version 2026.9.
Version control parameters tune how a component interacts with its repository without having to choose a different version control system. They are configured per component in Version control parameters, and only the parameters applicable to the selected Verziókezelő rendszer are offered.
List of version control parameters¶
Parameter name |
Version control systems |
Label |
Help text |
|---|---|---|---|
create_merge_request |
|
Create merge requests |
Open a pull or merge request for the translation changes. When turned off, Weblate pushes to the translated branch directly, which requires write access to it. |
git_force_push |
|
Force push |
Overwrite the remote branch instead of refusing to push non-fast-forward changes. Only use this with a repository dedicated to translations, as it discards upstream commits which are not present in Weblate. |
merge_request_automerge |
|
Merge pull requests automatically |
Turn on GitHub auto-merge for pull requests created by Weblate, so that they are merged once the required checks pass. Pull requests with nothing to wait for are merged right away. |
merge_request_merge_method |
|
Beolvasztási módszer |
Method used when merging pull requests automatically. The repository has to allow it. Elérhető lehetőségek:
|
Git¶
Tipp
Weblate needs Git 2.46 or newer.
Megjegyzés
Weblate validates permanent HTTP redirects which stay on the repository hostname and automatically stores the canonical repository URL. The change is recorded in the component history as repository maintenance. Redirects to another hostname have to be configured manually.
Lásd még
Különféle tárolók eléréséhez lásd: Tárolók elérése.
Git LFS¶
Weblate does not support files tracked by Git LFS as translation files. It does not download or upload Git LFS objects. Git LFS smudging and pre-push uploads are disabled for Weblate-managed repositories, so LFS-tracked files remain pointer files. This behavior applies to every Git hosting provider.
A repository can use Git LFS for files that Weblate does not need to read or modify. The upstream repository remains the authoritative source for these LFS objects. Clone from upstream when you need the actual files rather than their pointers because repositories served by Weblate do not include LFS objects.
For the GitLab merge request workflow, Weblate disables Git LFS in its managed fork. This prevents GitLab from rejecting pointer-only translation branches when the upstream repository added LFS objects after the fork was created. Existing managed forks are reconfigured on their next push. This does not change the Git LFS configuration of the upstream project.
Git submodules¶
Weblate does not populate Git submodules when cloning repositories. It does not initialize or update submodules, and it does not recurse into submodule repositories during file discovery or translation updates. Files stored inside a submodule are therefore not available to file masks when Weblate is connected to the parent repository.
If translation files live in a submodule, add the submodule repository to Weblate as its own component instead of reaching it through the parent repository. Weblate can then clone, update, commit, and push to the repository that actually stores the translation files. The parent repository only records the submodule commit pointer, so updating that pointer has to happen outside Weblate, for example in your normal development workflow or CI.
Force pushing¶
Turn on the git_force_push version control parameter to
make Weblate always force push. This is intended only in the case of using a
separate repository for translations.
Figyelem
Óvatosan használja, mivel könnyen adatvesztéshez vezethet a forrástárolóban.
A 2026.9 verzióban változott: This used to be a separate Git with force push version control
system. Existing components were migrated to Git with the git_force_push
parameter turned on.
Git beállításainak testreszabása¶
A Weblate minden VCS-parancsot HOME=$DATA_DIR/home környezettel hajt végre (lásd: DATA_DIR), ezért a felhasználói konfigurációt a DATA_DIR/home/.git könyvtárban kell szerkeszteni.
GitHub módosítási kérelmek (pull request)¶
Detailed GitHub pull request setup is covered in GitHub módosítási kérelmek (pull request).
GitLab egyesítési kérelmek (merge request)¶
Detailed GitLab merge request setup is covered in GitLab egyesítési kérelmek (merge request).
Gitea módosítási kérelmek (pull request)¶
Detailed Gitea pull request setup is covered in Gitea módosítási kérelmek (pull request).
Bitbucket Data Center módosítási kérelmek (pull request)¶
Detailed Bitbucket Data Center pull request setup is covered in Bitbucket Data Center módosítási kérelmek (pull request).
Bitbucket Cloud módosítási kérelmek (pull request)¶
Detailed Bitbucket Cloud pull request setup is covered in Bitbucket Cloud módosítási kérelmek (pull request).
Pagure egyesítési kérelmek (merge request)¶
Detailed Pagure merge request setup is covered in Pagure egyesítési kérelmek (merge request).
Gerrit¶
Detailed Gerrit review request setup is covered in Gerrit review requests.
Azure DevOps egyesítési kérelmek (pull request)¶
Detailed Azure DevOps pull request setup is covered in Azure DevOps egyesítési kérelmek (pull request).
Mercurial¶
A Mercurial egy másik verziókezelő rendszer, amelyet közvetlenül lehet használni a Weblate-ben.
Megjegyzés
Általában bármilyen Mercurial-verzióval működik, de időnként előfordulhatnak inkompatibilis változások a parancssori felületen, amelyek megszakíthatják az integrációt.
Lásd még
Különféle tárolók eléréséhez lásd: Tárolók elérése.
Subversion¶
A Weblate a git-svn eszközt használja subversion tárolók kezeléséhez. Ez egy Perl script, amely lehetővé teszi, hogy a Subversion rendszerrel Git kliensen keresztül dolgozzon, így a felhasználók teljes másolatot tarthatnak fenn a belső tárolóról, és helyben véglegesíthetnek.
Megjegyzés
A Weblate megpróbálja automatikusan felismerni a Subversion tároló szerkezetét – támogatja az ágakra mutató közvetlen URL-eket, valamint a szabványos szerkezetű tárolókat (branches/, tags/ és trunk/). Erről további információ a git-svn dokumentációban található. Ha a tároló nem szabványos szerkezetű és hibát tapasztal, próbálja meg az ág nevét is megadni az URL-ben, ilyenkor a Weblate-n hagyja üresen az ág mezőt.
Subversion hitelesítő adatok¶
A Weblate elvárja, hogy a tanúsítványt előzetesen elfogadja (és szükség esetén a hitelesítő adatokat is). Ezeket a DATA_DIR könyvtárba próbálja menteni. A tanúsítvány elfogadásához egyszer futtassa az svn parancsot úgy, hogy a $HOME környezeti változót a DATA_DIR értékére állítja:
# 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
Lásd még
Helyi fájlok¶
Tipp
A háttérben ez is a Git használatán alapul. Git telepítése szükséges, és lehetőséget ad arra, hogy natívan Git-et használjon a fordítások teljes előzményével.
A Weblate akkor is működik, ha nincs távoli VCS. Az első fordításokat feltöltéssel lehet importálni. Később az egyes fájlokat cserélheti fájlfeltöltéssel vagy közvetlenül is hozzáadhat fordítási szövegeket a Weblate felületén (jelenleg csak egynyelvű fordítások esetén).
A háttérben a Weblate létrehoz egy Git-tárolót, amelyben minden változás nyomon követhető. Ha később verziókezelő rendszert kíván használni a fordításokhoz, már rendelkezik egy tárolóval, amelyre az integrációt alapozhatja.