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¶
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, …)¶
A kódtároló szolgáltatásokhoz való hozzáférés jellemzően úgy történik, hogy egy dedikált felhasználót hoz létre, amelyhez hozzárendeli a Weblate SSH-kulcsot (lásd: Weblate SSH-kulcs). Így a Weblate SSH-kulcs egyetlen felhasználóhoz tartozik (a platformok gyakran csak egyszer engedélyeznek egy SSH-kulcsot), és ennek a felhasználónak ad hozzáférést a tárolóhoz. Ezután SSH-URL használható a tároló eléréséhez (lásd: SSH-tárolók).
Tipp
A Hosted Weblate esetén ez a legtöbb nyilvános oldalon előre be van állítva, lásd: Tárolók elérése a Hosted Weblate szolgáltatásból.
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¶
Az SSH-hozzáférés lehetséges (lásd: SSH-tárolók), de ha több tárolót kell elérnie, akkor a GitHub korlátozása miatt gond adódhat, mivel minden SSH-kulcs csak egyszer használható.
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.
Kisebb telepítéseknél használjon HTTPS-alapú hitelesítést személyes hozzáférési tokennel és GitHub-fiókkal, lásd: Creating an access token for command-line use.
Nagyobb telepítések esetén célszerű külön felhasználót létrehozni a Weblate számára, hozzárendelni a Weblate által generált nyilvános SSH-kulcsot (lásd: Weblate SSH-kulcs), és hozzáférést adni minden fordítani kívánt tárolóhoz. Ezt az eljárást használja a Hosted Weblate is, ahol dedikált weblate felhasználó van.
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¶
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.
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.
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.
Git távoli segédprogramok (remote helper)¶
A Git remote helpers használatával további verziókezelő rendszerek is támogathatók, de készüljön fel arra, hogy ez hibákhoz vezethet, amelyekhez hibakeresésre lehet szükség.
Jelenleg a Bazaar és a Mercurial rendszerekhez léteznek ilyen segédeszközök, külön GitHub-tárolókban: git-remote-hg és git-remote-bzr. Ezeket kézzel kell letölteni, majd elérhetővé tenni a keresési útvonalon (például: ~/bin). Ügyeljen rá, hogy a megfelelő verziókezelő rendszer is telepítve legyen.
Miután ezeket telepítette, ilyen típusú távoli elérést is megadhat a Weblate-ben.
Például a gnuhello projekt klónozása a Launchpadról Bazaar segítségével:
bzr::lp:gnuhello
A hello tároló klónozása a selenic.com oldalról Mercurial használatával:
hg::https://selenic.com/repo/hello
Figyelem
A Git remote helpers (távoli segédprogramok) használatának egyik kellemetlensége – például Mercurial esetén –, hogy a segédprogram visszatöltéskor olykor új tip-et (legutolsó változatot) hoz létre.
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.