Verziókezelő integráció¶
A Weblate jelenleg támogatja a Git rendszert (kiterjesztett támogatással: 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, Subversion, Bitbucket Cloud módosítási kérelmek (pull request), Bitbucket Data Center módosítási kérelmek (pull request), valamint Azure DevOps egyesítési kérelmek (pull request)) és a Mercurial verziókezelő háttérrendszert.
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.
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.
A Hosted Weblate számára dedikált feltöltési felhasználó van regisztrálva a GitHub, Bitbucket, Codeberg és GitLab felületeken (felhasználónév: weblate, e-mail cím: hosted@weblate.org, név vagy profil leírás: 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.
A GitHubon a weblate felhasználó automatikusan elfogadja a meghívást öt percen belül. Más szolgáltatások esetén manuális feldolgozásra lehet szükséges, ezért kérjük, legyen türelmes.
Miután a weblate felhasználót hozzáadta a tárolóhoz, konfigurálhatja az Forráskód tároló és Tároló feltöltési URL beállításokat SSH-protokoll használatával (például: git@github.com:WeblateOrg/weblate.git).
Tárolók elérése kódtároló szolgáltatásokon (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, accessing repositories on code hosting sites is typically done by creating a dedicated user who is associated with a Weblate SSH key (see Weblate SSH-kulcs). This way you associate Weblate SSH key with a single user (platforms frequently enforce single use of a SSH key) and grant this user access to the repository. You can then use SSH URL to access the repository (see SSH-tárolók).
SSH-tárolók¶
A privát tárolók elérésének leggyakoribb módja az SSH-alapú hozzáférés. Ilyenkor a Weblate nyilvános SSH-kulcsát kell engedélyezni (lásd: Weblate SSH-kulcs) a forrástárolóhoz való hozzáféréshez.
Figyelem
GitHubon minden kulcs csak egyszer használható, lásd: GitHub tárolók és 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.
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¶
There are two main approaches to accessing GitHub repositories with Weblate:
Option 1: HTTPS with Personal Access Token (simpler for getting started)
Use HTTPS authentication with a personal access token and your GitHub account. This works for both read-only access (cloning) and read-write access (pushing changes or creating pull requests).
To use this approach:
Create a personal access token as described in Creating an access token for command-line use.
Include the token in your repository URL:
https://username:token@github.com/owner/repo.git
This is suitable when you’re starting with Weblate or working with a single repository.
Option 2: SSH with Dedicated User (recommended for multiple repositories)
For setups with multiple repositories, it is recommended to create a dedicated user for Weblate. This avoids GitHub’s limitation that each SSH key can only be used once per platform.
To use this approach:
Create a dedicated GitHub user account (e.g.,
weblate-bot)Add Weblate’s public SSH key to this user (see Weblate SSH-kulcs)
Grant this user access to all repositories you want to translate
Use SSH URLs for your repositories:
git@github.com:owner/repo.git
This approach is also used for Hosted Weblate, which has a dedicated weblate user for that purpose.
Megjegyzés
When using GitHub módosítási kérelmek (pull request) for pull requests, the Feltöltési ág configuration affects the behavior: if not set, the project is forked and changes are pushed through a fork. If set, changes are pushed to the upstream repository and the chosen branch.
GitLab repositories¶
Access via SSH is possible (see SSH-tárolók), but in case you need to access more than one repository, you will hit a GitLab limitation on allowed SSH key usage (since each key can be used only once).
Ha a Feltöltési ág nincs beállítva, a projekt egy másolatba (fork) kerül, és a módosítások ezen a másolaton keresztül kerülnek feltöltésre. Ha be van állítva, a módosítások közvetlenül a forrás tárolóba és a megadott ágra lesznek feltöltve.
Using personal or project access tokens is possible as well. The token needs write_repository scope to be able to push changes to the repository. The project access token requires Developer role for pushing.
The URL needs to contain an username, for personal access token it is the
actual username (
https://user:personal_access_token@gitlab.com/example/example.git) for
project access tokens it can be non-blank value
(https://example:project_access_token@gitlab.com/example/example.git).
Megjegyzés
The rules for using project access tokens has changed between GitLab releases, the non-blank value is the current requirement, but older versions had different expectations (project name, bot user name). Check GitLab documentation matching your version if unsure.
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.
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¶
Lásd még
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¶
Ha HTTP/HTTPS VCS-tárolókhoz proxyn keresztül kell csatlakozni, állítsa be a VCS-t ennek megfelelően.
Ez történhet a http_proxy, https_proxy és all_proxy környezeti változók használatával (lásd a cURL dokumentációt) vagy közvetlenül a VCS konfigurációban, például így:
git config --global http.proxy http://user:password@proxy.example.com:80
Megjegyzés
A proxy beállítást annak a felhasználónak a környezetében kell elvégezni, aki a Weblate-et futtatja (lásd: Fájlrendszer jogosultságok), továbbá a HOME=$DATA_DIR/home beállítással (lásd: DATA_DIR), különben a Weblate által meghívott Git nem fogja használni a beállítást.
Lásd még
Git¶
Tipp
A Weblate a Git 2.28-as vagy újabb verzióját igényli.
Lásd még
Különféle tárolók eléréséhez lásd: Tárolók elérése.
Git kényszerített feltöltéssel¶
Ez ugyanúgy működik, mint a normál Git, azzal a különbséggel, hogy mindig kényszerített feltöltést hajt végre. Ez csak akkor javasolt, ha a fordítások külön tárolóban vannak.
Figyelem
Óvatosan használja, mivel könnyen adatvesztéshez vezethet a forrástárolóban.
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)¶
Ez egy vékony réteget ad a Git fölé, a GitHub API segítségével, amely lehetővé teszi, hogy a fordítási változások módosítási kérelemként kerüljenek feltöltésre, ne közvetlenül a tárolóba.
A Git közvetlenül a tárolóba küldi a módosításokat, míg a GitHub módosítási kérelmek (pull request) módosítási kérelmet hoz létre. Ez utóbbi nem szükséges a Git tárolók eléréséhez.
A működéshez API hitelesítő adatok ( GITHUB_CREDENTIALS ) megadása szükséges a Weblate beállításaiban. A beállítás után a GitHub lehetőség megjelenik a Verziókezelő rendszer kiválasztásakor.
GitLab egyesítési kérelmek (merge request)¶
Ez egy vékony réteget ad a Git fölé, a GitLab API használatával, hogy a fordítási módosításokat közvetlen feltöltés helyett egyesítési kérelemként lehessen beküldeni.
A Git tárolók eléréséhez nem szükséges ezt használni, az alapértelmezett Git ugyanúgy működik. A különbség csupán abban van, hogyan történik a feltöltés: a Git közvetlenül tölti fel a változásokat, míg a GitLab egyesítési kérelmek (merge request) egyesítési kérelmet hoz létre.
A működéshez API hitelesítő adatok megadása szükséges ( GITLAB_CREDENTIALS ) a Weblate beállításaiban. A konfiguráció után a Verziókezelő rendszer kiválasztásakor megjelenik a GitLab lehetőség.
Gitea módosítási kérelmek (pull request)¶
Added in version 4.12.
Ez egy vékony réteget ad a Git fölé, a Gitea API használatával, hogy a fordítási módosításokat közvetlen feltöltés helyett módosítási kérelemként lehessen beküldeni.
A Git tárolók eléréséhez nem szükséges ezt használni, az alapértelmezett Git ugyanúgy működik. A különbség csupán abban van, hogyan történik a feltöltés: a Git közvetlenül tölti fel a változásokat, míg a Gitea módosítási kérelmek (pull request) egyesítési kérelmet hoz létre.
A működéshez API hitelesítő adatok megadása szükséges ( GITEA_CREDENTIALS ) a Weblate beállításaiban. A konfiguráció után a Verziókezelő rendszer kiválasztásakor megjelenik a Gitea lehetőség.
Bitbucket Data Center módosítási kérelmek (pull request)¶
Added in version 4.16.
Ez egy vékony réteget ad a Git fölé, a Bitbucket Data Center API használatával, hogy a fordítási módosításokat közvetlen feltöltés helyett módosítási kérelemként lehessen beküldeni.
Figyelem
Ez nem támogatja a Bitbucket Cloud API-t.
A Git tárolók eléréséhez nem szükséges ezt használni, az alapértelmezett Git ugyanúgy működik. A különbség csupán abban van, hogyan történik a feltöltés: a Git közvetlenül tölti fel a változásokat, míg a Bitbucket Data Center módosítási kérelmek (pull request) módosítási kérelmet hoz létre.
A működéshez API hitelesítő adatok megadása szükséges ( BITBUCKETSERVER_CREDENTIALS ) a Weblate beállításaiban. A konfiguráció után a Verziókezelő rendszer kiválasztásakor megjelenik a Bitbucket Data Center lehetőség.
Bitbucket Cloud módosítási kérelmek (pull request)¶
Added in version 5.8.
Ez egy vékony réteget ad a Git fölé, a Bitbucket Cloud API használatával, hogy a fordítási módosításokat közvetlen feltöltés helyett módosítási kérelemként lehessen beküldeni.
Figyelem
Ez eltér a Bitbucket Data Center API-tól.
A Git tárolók eléréséhez nem szükséges ezt használni, az alapértelmezett Git ugyanúgy működik. A különbség csupán abban van, hogyan történik a feltöltés: a Git közvetlenül tölti fel a változásokat, míg a Bitbucket Cloud módosítási kérelmek (pull request) módosítási kérelmet hoz létre.
A működéshez API hitelesítő adatok megadása szükséges ( BITBUCKETCLOUD_CREDENTIALS ) a Weblate beállításaiban. A konfiguráció után a Verziókezelő rendszer kiválasztásakor megjelenik a Bitbucket Cloud lehetőség.
Pagure egyesítési kérelmek (merge request)¶
Added in version 4.3.2.
Ez egy vékony réteget ad a Git fölé, a Pagure API használatával, hogy a fordítási módosításokat közvetlen feltöltés helyett egyesítési kérelemként lehessen beküldeni.
A Git tárolók eléréséhez nem szükséges ezt használni, az alapértelmezett Git ugyanúgy működik. A különbség csupán abban van, hogyan történik a feltöltés: a Git közvetlenül tölti fel a változásokat, míg a Pagure egyesítési kérelmek (merge request) egyesítési kérelmet hoz létre.
A működéshez API hitelesítő adatok megadása szükséges ( PAGURE_CREDENTIALS ) a Weblate beállításaiban. A konfiguráció után a Verziókezelő rendszer kiválasztásakor megjelenik a Pagure lehetőség.
Gerrit¶
Ez egy vékony réteget ad a Git fölé, a git-review eszköz segítségével, hogy a fordítási módosítások Gerrit ellenőrzési kérelemként (review request) kerüljenek beküldésre, ahelyett hogy közvetlenül a tárolóba kerülnének.
A Gerrit dokumentáció tartalmazza az ilyen tárolók beállításához szükséges részleteket.
Azure DevOps egyesítési kérelmek (pull request)¶
Ez egy vékony réteget ad a Git fölé, az Azure DevOps API használatával, hogy a fordítási módosításokat közvetlen feltöltés helyett, egyesítési kérelemként lehessen beküldeni.
A Git közvetlenül a tárolóba küldi a változásokat, míg a Azure DevOps egyesítési kérelmek (pull request) egyesítési kérelmet hoz létre. Ez utóbbi nem szükséges, ha csak Git tárolók eléréséről van szó.
A működéshez API hitelesítő adatok megadása szükséges ( AZURE_DEVOPS_CREDENTIALS ) a Weblate beállításaiban. A konfiguráció után a Verziókezelő rendszer kiválasztásakor megjelenik az Azure DevOps lehetőség.
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.