Integration av versionskontroll¶
Weblate currently supports Git (with extended support for GitHub-pullförfrågningar, GitLab-sammanslagningsförfrågningar, Gitea-pullförfrågningar, Gerrit review requests, Subversion, Bitbucket Cloud-pullförfrågningar, Bitbucket Data Center-pullförfrågningar, and Azure DevOps pull-förfrågningar) 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.
Åtkomst till arkiv¶
Det VCS-arkiv du vill använda måste vara tillgängligt för Weblate. För ett offentligt tillgängligt arkiv behöver du bara ange rätt URL (till exempel https://github.com/WeblateOrg/weblate.git), men för privata arkiv eller push-URL:er är inställningarna mer komplexa och kräver autentisering.
Åtkomst till arkiv från Hosted Weblate¶
Observera
Detta avsnitt gäller endast Hosted Weblate (hosted.weblate.org). Om du kör din egen självhostade Weblate-instans, se istället nästa avsnitt.
För Hosted Weblate finns en dedikerad push-användare registrerad på GitHub, Bitbucket, Codeberg och GitLab (med användarnamnet weblate, e-postadressen hosted@weblate.org och namnet eller profilbeskrivningen Weblate push user).
Råd
Det kan finnas fler Weblate-användare på plattformarna, avsedda för andra Weblate-instanser. Vi rekommenderar att du söker efter e-postadressen hosted@weblate.org för att hitta rätt användare för Hosted Weblate.
Du måste lägga till denna användare som medarbetare och ge den lämpliga behörigheter till ditt arkiv (skrivskyddat är tillräckligt för kloning, skrivbehörighet krävs för pushning). Beroende på tjänsten och din organisations inställningar sker detta omedelbart eller kräver bekräftelse från Weblate.
On GitHub, you need to add or invite the Hosted Weblate weblate user with write access even when you use the Hosted Weblate GitHub app. The app handles incoming notifications from GitHub, but pushing changes back still uses the Hosted Weblate weblate user.
Användaren weblate på GitHub accepterar inbjudningar automatiskt inom fem minuter. Manuell bearbetning kan behövas på de andra tjänsterna, så var tålmodig.
När användaren weblate har lagts till i ditt arkiv kan du konfigurera Källkodsarkiv och Push-URL för arkiv med hjälp av SSH-protokollet (till exempel git@github.com:WeblateOrg/weblate.git).
Åtkomst till arkiv på kodhostingsajter (GitHub, GitLab, Bitbucket, Azure DevOps, …)¶
Observera
Detta avsnitt gäller självhostade Weblate-instanser. Om du använder Hosted Weblate (hosted.weblate.org) ska du istället se Åtkomst till arkiv från Hosted Weblate.
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-nyckel). 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-arkiv).
SSH-arkiv¶
One common method to access private repositories is based on SSH. Authorize the public Weblate SSH key (see Weblate SSH-nyckel) to access the upstream repository this way.
Varning
On GitHub, each key can only be used once, see GitHub repository access and Åtkomst till arkiv från Hosted Weblate.
Weblate lagrar också värdens nyckelfingeravtryck vid första anslutningen och misslyckas med att ansluta till värden om det ändras senare (se Verifiera SSH-värdnycklar).
Om justeringar behövs, gör det från Weblate-administratörsgränssnittet:
Weblate SSH-nyckel¶
Förändrat i version 4.17: Weblate genererar nu både RSA- och Ed25519 SSH-nycklar. Vi rekommenderar att du använder Ed25519 för nya installationer.
Weblates publika nyckel är synlig för alla användare som besöker sidan Om.
Administratörer kan generera eller visa den publika nyckel som för närvarande används av Weblate i anslutningen (från SSH-nycklar) på administratörsgränssnittets startsida.
Observera
Den motsvarande privata SSH-nyckeln kan för närvarande inte ha ett lösenord, så se till att den är väl skyddad.
Råd
Gör en säkerhetskopia av den genererade privata Weblate SSH-nyckeln.
Verifiera SSH-värdnycklar¶
Weblate lagrar automatiskt SSH-värdnycklarna vid första åtkomsten och kommer ihåg dem för vidare användning.
Om du vill verifiera nyckelfingeravtrycket innan du ansluter till arkivet, lägg till SSH-värdnycklarna för de servrar du ska komma åt i Lägg till värdnyckel, från samma avsnitt i administratörsgränssnittet. Ange värdnamnet du ska komma åt (t.ex. gitlab.com) och tryck på Skicka. Kontrollera att fingeravtrycket stämmer överens med den server du lagt till.
De tillagda nycklarna med fingeravtryck visas i bekräftelsemeddelandet:
Ansluta till äldre SSH-servrar¶
Senaste versioner av OpenSSH (till exempel den som används i Weblate Docker-containern) inaktiverar RSA-signaturer som använder SHA-1-hashalgoritmen som standard. Denna ändring har gjorts eftersom SHA-1-hashalgoritmen är kryptografiskt knäckt och det är möjligt att skapa hash-kollisioner med valt prefix för mindre än 50 000 USD.
För de flesta användare bör denna ändring vara osynlig och det finns inget behov av att byta ut ssh-rsa-nycklar. OpenSSH har stött RFC8332 RSA/SHA-256/512-signaturer sedan version 7.2 och befintliga ssh-rsa-nycklar kommer automatiskt att använda den starkare algoritmen där det är möjligt.
Inkompatibilitet är mer sannolikt när du ansluter till äldre SSH-implementeringar som inte har uppgraderats eller som inte noggrant har följt förbättringarna i SSH-protokollet. SSH-anslutningen till en sådan server kommer att misslyckas med:
no matching host key type found. Their offer: ssh-rsa
I dessa fall kan det vara nödvändigt att selektivt återaktivera RSA/SHA1 för att tillåta anslutning och/eller användarautentisering via alternativen HostkeyAlgorithms och PubkeyAcceptedAlgorithms. Till exempel kommer följande strof i DATA_DIR/ssh/config att aktivera RSA/SHA1 för värd- och användarautentisering för en enskild destinationsvärd:
Host legacy-host
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
Vi rekommenderar att RSA/SHA1 endast aktiveras som en tillfällig åtgärd tills äldre implementationer kan uppgraderas eller konfigureras om med en annan nyckeltyp (t.ex. ECDSA eller Ed25519).
GitHub-arkiv¶
Detailed GitHub repository access is covered in GitHub repository access.
GitLab-arkiv¶
Detailed GitLab repository access is covered in GitLab repository access.
Weblates interna URL:er¶
Dela en repositorieinställning mellan olika komponenter genom att hänvisa till dess placering som weblate://project/component i andra (länkade) komponenter. På så sätt använder länkade komponenter VCS-repositoriekontfigurationen för den huvudsakliga (refererade) komponenten.
Varning
Om du tar bort huvudkomponenten tas även länkade komponenter bort.
Weblate justerar automatiskt URL:en till arkivet när en komponent skapas om den hittar en komponent med en matchande arkivkonfiguration. Du kan åsidosätta detta i det sista steget av komponentkonfigurationen.
Skäl att använda detta:
Sparar diskutrymme på servern, eftersom arkivet endast lagras en gång.
Gör uppdateringarna snabbare, endast ett arkiv uppdateras.
Det finns bara ett enda exporterat arkiv med Weblate-översättningar (se Git-exportör).
Vissa tillägg kan fungera på flera komponenter som delar ett arkiv, till exempel Squasha Git arkiveringar.
HTTPS-arkiv¶
För att komma åt skyddade HTTPS-arkiv, ange användarnamn och lösenord i URL:en. Oroa dig inte, Weblate tar bort denna information när URL:en visas för användarna (om de överhuvudtaget får se arkivets URL).
Till exempel kan GitHub-URL:en med autentisering se ut så här: https://user:your_access_token@github.com/WeblateOrg/weblate.git.
Om du inte anger inloggningsuppgifter i URL:en och arkivet kräver det, kommer Git att misslyckas med ett felmeddelande:
fatal: could not read Username for 'https://github.com': terminal prompts disabled
Förändrat i version 5.10.2: Weblate använder proaktiv autentisering med Git 2.46.0 och nyare när HTTP-autentiseringsuppgifter anges.
Detta gör det möjligt att komma åt Azure DevOps-arkiv och gör åtkomsten till autentiserade arkiv snabbare.
Observera
Om ditt användarnamn eller lösenord innehåller specialtecken måste dessa URL-kodas, till exempel https://user%40example.com:%24password%23@bitbucket.org/….
Använda proxy¶
Om du behöver komma åt HTTP/HTTPS VCS-arkiv med hjälp av en proxyserver, konfigurera VCS så att den använder den.
Detta kan göras med hjälp av miljövariablerna http_proxy, https_proxy och all_proxy (som beskrivs i cURL-dokumentationen) eller genom att tvinga fram det i VCS-konfigurationen, till exempel:
git config --global http.proxy http://user:password@proxy.example.com:80
Observera
Proxykonfigurationen måste göras under användaren som kör Weblate (se även Filssystemets behörigheter) och med HOME=$DATA_DIR/home (se DATA_DIR), annars kommer Git som körs av Weblate inte att använda den.
Git¶
Råd
Weblate kräver Git 2.28 eller nyare.
Se även
Se Åtkomst till arkiv för information om hur du kommer åt olika typer av arkiv.
Git med kraft push¶
Detta fungerar precis som Git själv, med den enda skillnaden att det alltid tvingar fram pushar. Detta är endast avsett för fall där ett separat arkiv används för översättningar.
Varning
Använd med försiktighet, eftersom detta lätt kan leda till förlorade commit i ditt uppströmsrepositorium.
Anpassa Git-konfigurationen¶
Weblate anropar alla VCS-kommandon med HOME=$DATA_DIR/home (se DATA_DIR), därför måste redigering av användarkonfigurationen göras i DATA_DIR/home/.git.
GitHub-pullförfrågningar¶
Detailed GitHub pull request setup is covered in GitHub-pullförfrågningar.
GitLab-sammanslagningsförfrågningar¶
Detailed GitLab merge request setup is covered in GitLab-sammanslagningsförfrågningar.
Gitea-pullförfrågningar¶
Detailed Gitea pull request setup is covered in Gitea-pullförfrågningar.
Bitbucket Data Center-pullförfrågningar¶
Detailed Bitbucket Data Center pull request setup is covered in Bitbucket Data Center-pullförfrågningar.
Bitbucket Cloud-pullförfrågningar¶
Detailed Bitbucket Cloud pull request setup is covered in Bitbucket Cloud-pullförfrågningar.
Pagure-sammanslagningsförfrågningar¶
Detailed Pagure merge request setup is covered in Pagure-sammanslagningsförfrågningar.
Gerrit¶
Detailed Gerrit review request setup is covered in Gerrit review requests.
Azure DevOps pull-förfrågningar¶
Detailed Azure DevOps pull request setup is covered in Azure DevOps pull-förfrågningar.
Mercurial¶
Mercurial är ett annat VCS som du kan använda direkt i Weblate.
Observera
Det bör fungera med alla versioner av Mercurial, men ibland förekommer inkompatibla ändringar i kommandoradsgränssnittet som stör integrationen med Weblate.
Se även
Se Åtkomst till arkiv för information om hur du kommer åt olika typer av arkiv.
Subversion¶
Weblate använder git-svn för att interagera med subversion-arkiv. Det är ett Perl-skript som gör det möjligt att använda subversion med en Git-klient, vilket gör att användare kan underhålla en fullständig klon av det interna arkivet och göra lokala commit.
Observera
Weblate försöker automatiskt upptäcka Subversion-arkivets layout – det stöder både direkta URL:er för grenar eller arkiv med standardlayout (grenar/, taggar/ och stam/). Mer information om detta finns i git-svn-dokumentationen. Om ditt arkiv inte har en standardlayout och du stöter på fel, försök att inkludera grennamnet i arkivets URL och lämna grenen tom.
Subversion-autentiseringsuppgifter¶
Weblate förväntar sig att du har godkänt certifikatet i förväg (och dina inloggningsuppgifter om det behövs). Det kommer att försöka infoga dem i katalogen DATA_DIR. Godkänn certifikatet genom att använda svn en gång med miljövariabeln $HOME inställd på 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
Se även
Lokala filer¶
Råd
Under ytan använder detta Git. Det kräver att Git är installerat och gör det möjligt för dig att byta till att använda Git inbyggt med fullständig historik över dina översättningar.
Weblate kan även fungera utan ett fjärrstyrt VCS. De initiala översättningarna importeras genom att ladda upp dem. Senare kan du ersätta enskilda filer genom att ladda upp dem, eller lägga till översättningssträngar direkt från Weblate (för närvarande endast tillgängligt för enspråkiga översättningar).
I bakgrunden skapar Weblate ett Git-arkiv åt dig och alla ändringar spåras där. Om du senare bestämmer dig för att använda ett VCS för att lagra översättningarna har du redan ett arkiv i Weblate som du kan basera din integration på.