Integration av versionskontroll¶
Weblate stöder för närvarande Git (med utökat stöd för GitHub-pullförfrågningar, GitLab-sammanslagningsförfrågningar, Gitea-pullförfrågningar, Gerrit, Subversion, Bitbucket Cloud-pullförfrågningar, Bitbucket Data Center-pullförfrågningar och Azure DevOps pull-förfrågningar) och Mercurial som versionshanteringsbackend.
Å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.
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.
För självhostad Weblate sker åtkomst till arkiv på kodhostingsajter vanligtvis genom att skapa en dedikerad användare som är associerad med en Weblate SSH-nyckel (se Weblate SSH-nyckel). På så sätt associerar du Weblate SSH-nyckeln med en enda användare (plattformar kräver ofta att en SSH-nyckel endast används av en användare) och ger denna användare åtkomst till arkivet. Du kan sedan använda SSH-URL för att få åtkomst till arkivet (se SSH-arkiv).
SSH-arkiv¶
Den vanligaste metoden för att komma åt privata arkiv baseras på SSH. Auktorisera den offentliga Weblate SSH-nyckeln (se Weblate SSH-nyckel) för att komma åt uppströmsarkivet på detta sätt.
Varning
På GitHub kan varje nyckel endast användas en gång, se GitHub-arkiv och Å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¶
Det finns två huvudsakliga metoder för att komma åt GitHub-arkiv med Weblate:
Alternativ 1: HTTPS med personlig åtkomsttoken (enklare att komma igång med)
Använd HTTPS-autentisering med en personlig åtkomsttoken och ditt GitHub-konto. Detta fungerar både för skrivskyddad åtkomst (kloning) och läs- och skrivåtkomst (skicka ändringar eller skapa pull-förfrågningar).
För att använda denna metod:
Skapa en personlig åtkomsttoken enligt beskrivningen i Skapa en åtkomsttoken för användning i kommandoraden.
Inkludera token i din repository-URL:
https://username:token@github.com/owner/repo.git
Detta är lämpligt när du börjar använda Weblate eller arbetar med ett enda arkiv.
Alternativ 2: SSH med dedikerad användare (rekommenderas för flera arkiv)
För installationer med flera arkiv rekommenderas det att skapa en dedikerad användare för Weblate. Detta undviker GitHubs begränsning att varje SSH-nyckel endast kan användas en gång per plattform.
För att använda denna metod:
Skapa ett dedikerat GitHub-användarkonto (t.ex.
weblate-bot)Lägg till Weblates offentliga SSH-nyckel till denna användare (se Weblate SSH-nyckel)
Ge denna användare åtkomst till alla arkiv som du vill översätta
Använd SSH-URL:er för dina arkiv:
git@github.com:owner/repo.git
Denna metod används även för Hosted Weblate, som har en dedikerad weblate-användare för detta ändamål.
Observera
När du använder GitHub-pullförfrågningar för pull-förfrågningar påverkar konfigurationen Pusha gren beteendet: om den inte är inställd förgrenas projektet och ändringarna pushas via en förgrening. Om den är inställd pushas ändringarna till uppströmsrepositoriet och den valda grenen.
GitLab-arkiv¶
Åtkomst via SSH är möjlig (se SSH-arkiv), men om du behöver åtkomst till mer än ett arkiv kommer du att stöta på en begränsning i GitLab vad gäller tillåten användning av SSH-nycklar (eftersom varje nyckel endast kan användas en gång).
Om Pusha gren inte är inställt, förgrenas projektet och ändringarna skickas via en förgrening. Om det är inställt skickas ändringarna till uppströmsrepositoriet och den valda grenen.
Det är även möjligt att använda personliga eller projektbaserade åtkomsttoken. Token behöver write_repository-behörighet för att kunna överföra ändringar till repositoriet. Projektåtkomsttoken kräver Developer-rollen för överföring.
URL:en måste innehålla ett användarnamn. För personliga åtkomsttoken är det det faktiska användarnamnet (https://user:personal_access_token@gitlab.com/example/example.git) och för projektåtkomsttoken kan det vara ett icke-tomt värde (https://example:project_access_token@gitlab.com/example/example.git).
Observera
Reglerna för användning av projektåtkomsttoken har ändrats mellan olika GitLab-versioner. Det aktuella kravet är ett icke-tomt värde, men äldre versioner hade andra krav (projektnamn, botanvändarnamn). Kontrollera GitLab-dokumentationen för din version om du är osäker.
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¶
Se även
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¶
Detta lägger till ett tunt lager ovanpå Git med hjälp av GitHub API för att möjliggöra att översättningsändringar kan skickas som pull-förfrågningar, istället för att skickas direkt till arkivet.
Git skickar ändringar direkt till ett arkiv, medan GitHub-pullförfrågningar skapar pull-förfrågningar. Det senare behövs inte för att bara komma åt Git-arkiv.
Du måste konfigurera API-autentiseringsuppgifter (GITHUB_CREDENTIALS) i Weblate-inställningarna för att detta ska fungera. När det är konfigurerat kommer du att se ett GitHub-alternativ när du väljer Versionshanteringssystem.
GitLab-sammanslagningsförfrågningar¶
Detta lägger bara till ett tunt lager ovanpå Git med hjälp av GitLab API för att möjliggöra att översättningsändringar kan skickas som sammanfogningsförfrågningar istället för att skickas direkt till arkivet.
Det finns ingen anledning att använda detta för att komma åt Git-arkiv, vanliga Git fungerar på samma sätt, den enda skillnaden är hur överföringen till ett arkiv hanteras. Med Git överförs ändringarna direkt till arkivet, medan GitLab-sammanslagningsförfrågningar skapar en sammanfogningsbegäran.
Du måste konfigurera API-autentiseringsuppgifter (GITLAB_CREDENTIALS) i Weblate-inställningarna för att detta ska fungera. När du har konfigurerat detta kommer du att se ett GitLab-alternativ när du väljer Versionshanteringssystem.
Gitea-pullförfrågningar¶
Added in version 4.12.
Detta lägger bara till ett tunt lager ovanpå Git med hjälp av Gitea API för att möjliggöra att översättningsändringar kan skickas som pull-förfrågningar istället för att skickas direkt till arkivet.
Det finns inget behov av att använda detta för att komma åt Git-arkiv, vanliga Git fungerar på samma sätt, den enda skillnaden är hur pushning till ett arkiv hanteras. Med Git pushas ändringar direkt till arkivet, medan Gitea-pullförfrågningar skapar pull-förfrågningar.
Du måste konfigurera API-autentiseringsuppgifter (GITEA_CREDENTIALS) i Weblate-inställningarna för att detta ska fungera. När du har konfigurerat detta kommer du att se ett Gitea-alternativ när du väljer Versionshanteringssystem.
Bitbucket Data Center-pullförfrågningar¶
Added in version 4.16.
Detta lägger bara till ett tunt lager ovanpå Git med hjälp av Bitbucket Data Center API för att möjliggöra att översättningsändringar kan skickas som pull-förfrågningar istället för att skickas direkt till arkivet.
Varning
Detta stöder inte Bitbucket Cloud API.
Det finns inget behov av att använda detta för att komma åt Git-arkiv, vanliga Git fungerar på samma sätt, den enda skillnaden är hur överföringen till ett arkiv hanteras. Med Git överförs ändringar direkt till arkivet, medan Bitbucket Data Center-pullförfrågningar skapar en pull-begäran.
Du måste konfigurera API-autentiseringsuppgifter (BITBUCKETSERVER_CREDENTIALS) i Weblate-inställningarna för att detta ska fungera. När du har konfigurerat detta kommer du att se alternativet Bitbucket Data Center när du väljer Versionshanteringssystem.
Bitbucket Cloud-pullförfrågningar¶
Added in version 5.8.
Detta lägger bara till ett tunt lager ovanpå Git med hjälp av Bitbucket Cloud API för att möjliggöra att översättningsändringar skickas som pull-förfrågningar istället för att skickas direkt till arkivet.
Varning
Detta skiljer sig från Bitbucket Data Center API.
Det finns inget behov av att använda detta för att komma åt Git-arkiv, vanliga Git fungerar på samma sätt, den enda skillnaden är hur överföringen till ett arkiv hanteras. Med Git överförs ändringarna direkt till arkivet, medan Bitbucket Cloud-pullförfrågningar skapar en pull-begäran.
Du måste konfigurera API-autentiseringsuppgifter (BITBUCKETCLOUD_CREDENTIALS) i Weblate-inställningarna för att detta ska fungera. När det är konfigurerat kommer du att se ett Bitbucket Cloud-alternativ när du väljer Versionshanteringssystem.
Pagure-sammanslagningsförfrågningar¶
Added in version 4.3.2.
Detta lägger bara till ett tunt lager ovanpå Git med hjälp av Pagure API för att möjliggöra att översättningsändringar kan skickas som sammanfogningsförfrågningar istället för att skickas direkt till arkivet.
Det finns inget behov av att använda detta för att komma åt Git-arkiv, vanliga Git fungerar på samma sätt, den enda skillnaden är hur överföringen till ett arkiv hanteras. Med Git överförs ändringarna direkt till arkivet, medan Pagure-sammanslagningsförfrågningar skapar en sammanfogningsbegäran.
Du måste konfigurera API-autentiseringsuppgifter (PAGURE_CREDENTIALS) i Weblate-inställningarna för att detta ska fungera. När du har konfigurerat detta kommer du att se ett Pagure-alternativ när du väljer Versionshanteringssystem.
Gerrit¶
Lägger till ett tunt lager ovanpå Git med hjälp av verktyget git-review för att möjliggöra att översättningsändringar skickas som Gerrit-granskningsförfrågningar, istället för att skickas direkt till arkivet.
Gerrit-dokumentationen innehåller detaljerad information om den konfiguration som krävs för att skapa sådana arkiv.
Azure DevOps pull-förfrågningar¶
Detta lägger till ett tunt lager ovanpå Git med hjälp av Azure DevOps API för att möjliggöra att översättningsändringar kan skickas som pull-förfrågningar, istället för att skickas direkt till arkivet.
Git skickar ändringar direkt till ett arkiv, medan Azure DevOps pull-förfrågningar skapar pull-förfrågningar. Det senare behövs inte för att bara komma åt Git-arkiv.
Du måste konfigurera API-autentiseringsuppgifter (AZURE_DEVOPS_CREDENTIALS) i Weblate-inställningarna för att detta ska fungera. När du har konfigurerat detta kommer du att se ett Azure DevOps-alternativ när du väljer Versionshanteringssystem.
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å.