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.
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.
Å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.
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).
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.
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 Källkodsarkiv and
Push-URL för arkiv using the SSH protocol, for example
git@example.com:group/project.git.
Accessing repositories on code-hosting sites (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.
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.
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.
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.
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¶
If you need to access Git repositories over HTTPS using a proxy server, configure the per-protocol environment variables described in HTTP-proxy.
Parametrar för versionshantering¶
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 Parametrar för versionshantering, and only the parameters applicable to the selected Versionshanteringssystem are offered.
List of version control parameters¶
Parameternamn |
Version control systems |
Etikett |
Hjälptext |
|---|---|---|---|
create_merge_request |
|
Skapa sammanslagningsbegäranden |
Skapa en pull- eller sammanslagningsbegäran för översättningsändringarna. När funktionen är avstängd överför Weblate direkt till den översatta grenen, vilket kräver skrivbehörighet till den. |
git_force_push |
|
Tvinga push |
Skriv över fjärrgrenen istället för att vägra att skicka ändringar som inte kan snabbspolas. Använd detta endast med ett förråd dedikerat till översättningar, eftersom det kastar bort uppströmsändringar som inte finns i Weblate. |
merge_request_automerge |
|
Sammanfoga pull-begäranden automatiskt |
Slå på GitHubs automatiska sammanslagning för pull-begäranden skapade av Weblate, så att de slås samman när de nödvändiga kontrollerna har passerat. Pull-begäranden som inte behöver invänta någonting slås samman direkt. |
merge_request_merge_method |
|
Sammanslagningsmetod |
Metod som används när pull-begäranden automatiskt sammanfogas. Förrådet måste tillåta det. Tillgängliga alternativ:
|
Git¶
Råd
Weblate needs Git 2.46 or newer.
Observera
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.
Se även
Se Åtkomst till arkiv för information om hur du kommer åt olika typer av arkiv.
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.
Varning
Använd med försiktighet, eftersom detta lätt kan leda till förlorade commit i ditt uppströmsrepositorium.
Förändrat i version 2026.9: 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.
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å.