Integració del control de versions¶
Weblate currently supports Git (with extended support for GitHub pull requests, GitLab merge requests, Gitea pull requests, Gerrit review requests, Subversion, Bitbucket Cloud pull requests, Bitbucket Data Center pull requests, and Azure DevOps pull requests) and Mercurial as version control back-ends.
Per obtenir els passos de configuració específics del proveïdor que combinen l’accés al repositori, les notificacions entrants i la remissió de traduccions, consulteu Code-hosting integrations.
Accés als repositoris¶
El repositori VCS que voleu utilitzar ha de ser accessible per Weblate. Amb un repositori disponible públicament només cal que introduïu l’URL correcte (per exemple https://github.com/WeblateOrg/weblate.git), però per als repositoris privats o per a URL push la configuració és més complexa i requereix autenticació.
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.
Accés als repositoris des de Hosted Weblate¶
Nota
Aquesta secció s’aplica només a Hosted Weblate (hosted.weblate.org). Si esteu executant la vostra pròpia instància de Weblate autoallotjada, consulteu la següent secció.
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).
Suggeriment
Hi pot haver més usuaris de Weblate a les plataformes, designats per a altres instàncies de Weblate. Es recomana cercar per correu electrònic hosted@weblate.org per trobar l’usuari correcte per Hosted Weblate.
Heu d’afegir aquest usuari com a col·laborador i donar-li els permisos adequats al vostre repositori (només de lectura és correcte per a la clonació, es requereix escriptura per enviar). Depenent del servei i de la configuració de la vostra organització, això passa immediatament o requereix confirmació al costat de 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 Repositori del codi font and
URL de pujada al repositori using the SSH protocol, for example
git@example.com:group/project.git.
Accessing repositories on code-hosting sites (GitHub, GitLab, Bitbucket, Azure DevOps, …)¶
Nota
Aquesta secció s’aplica a les instàncies de Weblate autoallotjades. Si utilitzeu Hosted Weblate (hosted.weblate.org), consulteu Accés als repositoris des de Hosted Weblate.
Per a Weblate autoallotjat, sovint és més fàcil configurar un únic dipòsit privat mitjançant un URL de dipòsit HTTPS amb un testimoni d’accés, vegeu Code-hosting integrations.
For multiple repositories, create a dedicated code-hosting user associated with a Weblate SSH key (see Clau SSH de Weblate). 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 Repositoris SSH).
Repositoris SSH¶
Un mètode comú per accedir als repositoris privats es basa en SSH. Autoritzeu la clau pública Weblate SSH (vegeu Clau SSH de Weblate) per accedir al repositori amunt d’aquesta manera.
Avís
A GitHub, cada clau només es pot utilitzar una vegada, vegeu GitHub repository access i Accés als repositoris des de Hosted Weblate.
Weblate també emmagatzema l’empremta digital de la clau de l’amfitrió a la primera connexió i no es pot connectar a l’amfitrió si es canvia més tard (vegeu Verificació de les claus d’amfitrió SSH).
En cas que calgui un ajust, feu-ho des de la interfície d’administració de Weblate:
Clau SSH de Weblate¶
Canviat a la versió 4.17: Weblate ara genera les claus SSH RSA i Ed25519. Es recomana utilitzar Ed25519 per a noves configuracions.
La clau pública de Weblate és visible per a tots els usuaris que naveguin per la pàgina Quant a.
Els administradors poden generar o mostrar la clau pública que actualment utilitza Weblate a la connexió (des de claus SSH) a la pàgina de destinació de la interfície d’administració.
Nota
Actualment, la clau SSH privada corresponent no pot tenir una contrasenya, així que assegureu-vos que estigui ben protegida.
Suggeriment
Feu una còpia de seguretat de la clau SSH de Weblate privada generada.
Verificació de les claus d’amfitrió SSH¶
Weblate emmagatzema automàticament les claus de l’amfitrió SSH en el primer accés i les recorda per a un ús posterior.
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.
En cas que vulgueu verificar l’empremta digital de la clau abans de connectar-vos al repositori, afegiu les claus d’amfitrió SSH dels servidors als quals accedireu a Afegeix una clau d’amfitrió, des de la mateixa secció de la interfície d’administració. Introduïu el nom d’amfitrió al qual voleu accedir (per exemple, gitlab.com) i premeu Envia. Verifiqueu que la seva empremta digital coincideixi amb el servidor que heu afegit.
Les tecles afegides amb empremtes dactilars es mostren al missatge de confirmació:
Connexió a servidors SSH heretats¶
Les versions recents d’OpenSSH (per exemple, la que s’utilitza al contenidor Weblate Docker) desactiven les signatures RSA mitjançant l’algoritme hash SHA-1 de manera predeterminada. Aquest canvi s’ha fet perquè l’algoritme hash SHA-1 està trencat criptogràficament i és possible crear col·lisions de hash amb el prefix escollit per <USD$50K.
Per a la majoria dels usuaris, aquest canvi hauria de ser invisible i no cal substituir les claus ssh-rsa. L’OpenSSH admet signatures RFC8332 RSA/SHA-256/512 des de la versió 7.2 i les claus ssh-rsa existents utilitzaran automàticament l’algorisme més fort sempre que sigui possible.
La incompatibilitat és més probable quan es connecta a implementacions SSH antigues que no s’han actualitzat o que no han fet un seguiment de prop de les millores del protocol SSH. La connexió SSH a aquest servidor fallarà amb:
no matching host key type found. Their offer: ssh-rsa
En aquests casos, pot ser necessari tornar a activar selectivament RSA/SHA1 per permetre la connexió i/o l’autenticació d’usuari mitjançant les opcions HostkeyAlgorithms i PubkeyAcceptedAlgorithms. Per exemple, l’estrofa següent a DATA_DIR/ssh/config habilitarà RSA/SHA1 per a l’autenticació d’usuari i amfitrió per a un únic host de destinació:
Host legacy-host
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
Recomanem habilitar RSA/SHA1 només com a mesura provisional fins que les implementacions heretades es puguin actualitzar o reconfigurar amb un altre tipus de clau (com ara ECDSA o Ed25519).
Repositoris GitHub¶
L’accés detallat al repositori de GitHub es tracta a GitHub repository access.
GitLab repositories¶
L’accés detallat al repositori de GitLab es tracta a GitLab repository access.
URL interns del lloc web¶
Compartiu una configuració de repositori entre diferents components fent referència a la seva ubicació com a weblate://project/component en altres components (enllaçats). D’aquesta manera, els components enllaçats utilitzen la configuració del repositori VCS del component principal (referenciat).
Avís
L’eliminació del component principal també elimina els components enllaçats.
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 ajusta automàticament l’URL del dipòsit quan es crea un component si troba un component amb una configuració de dipòsit coincident. Podeu anul·lar-ho en l’últim pas de la configuració del component.
Raons per utilitzar això:
Estalvia espai al disc al servidor, el dipòsit només s’emmagatzema una vegada.
Fa que les actualitzacions siguin més ràpides, només s’actualitza un dipòsit.
Només hi ha un únic repositori exportat amb traduccions de Weblate (vegeu Exportador de Git).
Alguns complements poden funcionar amb diversos components compartint un dipòsit, per exemple Fes comissions «squash» al Git.
Repositoris HTTPS¶
Vegeu també
Per accedir als repositoris HTTPS protegits, incloeu el nom d’usuari i la contrasenya a l’URL. No us preocupeu, Weblate eliminarà aquesta informació quan es mostri l’URL als usuaris (si fins i tot es permet veure l’URL del repositori).
Per exemple, l’URL de GitHub amb l’autenticació afegida podria semblar: https://user:your_access_token@github.com/WeblateOrg/weblate.git.
En cas que no proporcioneu les credencials a l’URL i el repositori ho requereixi, Git fallarà amb un error:
fatal: could not read Username for 'https://github.com': terminal prompts disabled
Canviat a la versió 5.10.2: Weblate utilitza l’autenticació proactiva amb Git 2.46.0 i posteriors quan es proporcionen credencials HTTP.
Això fa possible accedir als repositoris Azure DevOps i fa que l’accés als dipòsits autenticats sigui més ràpid.
Nota
Si el vostre nom d’usuari o contrasenya conté caràcters especials, aquests s’han de codificar per URL, per exemple https://user%40example.com:%24password%23@bitbucket.org/….
Utilitzant proxy¶
If you need to access Git repositories over HTTPS using a proxy server, configure the per-protocol environment variables described in Proxy HTTP.
Version control parameters¶
Afegit a la versió 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 Version control parameters, and only the parameters applicable to the selected Sistema de control de versions are offered.
List of version control parameters¶
Parameter name |
Version control systems |
Label |
Help text |
|---|---|---|---|
create_merge_request |
|
Create merge requests |
Open a pull or merge request for the translation changes. When turned off, Weblate pushes to the translated branch directly, which requires write access to it. |
git_force_push |
|
Force push |
Overwrite the remote branch instead of refusing to push non-fast-forward changes. Only use this with a repository dedicated to translations, as it discards upstream commits which are not present in Weblate. |
merge_request_automerge |
|
Merge pull requests automatically |
Turn on GitHub auto-merge for pull requests created by Weblate, so that they are merged once the required checks pass. Pull requests with nothing to wait for are merged right away. |
merge_request_merge_method |
|
Mètode de fusió |
Method used when merging pull requests automatically. The repository has to allow it. Available choices:
|
Git¶
Suggeriment
Weblate needs Git 2.46 or newer.
Nota
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.
Vegeu també
Vegeu Accés als repositoris per obtenir informació sobre com accedir a diferents tipus de repositoris.
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.
Avís
Utilitzeu-lo amb precaució, ja que això condueix fàcilment a la pèrdua de commits al vostre repositori amunt.
Canviat a la versió 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.
Personalització de la configuració de Git¶
Weblate invoca totes les ordres VCS amb HOME=$DATA_DIR/home (vegeu DATA_DIR), per tant, l’edició de la configuració de l’usuari s’ha de fer a DATA_DIR/home/.git.
GitHub pull requests¶
La configuració detallada de la sol·licitud d’extracció de GitHub es tracta a GitHub pull requests.
GitLab merge requests¶
La configuració detallada de la sol·licitud de fusió de GitLab es tracta a GitLab merge requests.
Gitea pull requests¶
La configuració detallada de la sol·licitud d’extracció de Gitea es tracta a Gitea pull requests.
Bitbucket Data Center pull requests¶
La configuració detallada de la sol·licitud d’extracció del centre de dades de Bitbucket es tracta a Bitbucket Data Center pull requests.
Bitbucket Cloud pull requests¶
La configuració detallada de la sol·licitud d’extracció de Bitbucket Cloud es tracta a Bitbucket Cloud pull requests.
Pagure merge requests¶
La configuració detallada de la sol·licitud de fusió de Pagure es tracta a Pagure merge requests.
Gerrit¶
La configuració detallada de la sol·licitud de revisió de Gerrit es tracta a Gerrit review requests.
Azure DevOps pull requests¶
La configuració detallada de la sol·licitud d’extracció d’Azure DevOps es tracta a Azure DevOps pull requests.
Mercurial¶
Mercurial és un altre VCS que podeu utilitzar directament a Weblate.
Nota
Hauria de funcionar amb qualsevol versió de Mercurial, però de vegades hi ha canvis incompatibles a la interfície de línia d’ordres que trenca la integració de Weblate.
Vegeu també
Vegeu Accés als repositoris per obtenir informació sobre com accedir a diferents tipus de repositoris.
Subversion¶
Weblate utilitza git-svn per interactuar amb els repositoris subversion. És un script Perl que permet que un client Git utilitzi la subversió, permetent als usuaris mantenir un clon complet del dipòsit intern i comprometre’s localment.
Nota
Weblate intenta detectar automàticament el disseny del dipòsit de Subversion: admet tant URL directes per a branques com dipòsits amb disseny estàndard (branches/, etiquetes/ i tronc/). Trobareu més informació sobre això a la documentació git-svn. Si el vostre dipòsit no té un disseny estàndard i trobeu errors, proveu d’incloure el nom de la branca a l’URL del dipòsit i deixeu la branca buida.
Credencials de subversió¶
Weblate espera que hàgiu acceptat el certificat per endavant (i les vostres credencials si cal). Es buscarà inserir-los al directori DATA_DIR. Accepteu el certificat utilitzant svn una vegada amb la variable d’entorn $HOME establerta a 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
Vegeu també
Fitxers locals¶
Suggeriment
A sota, això utilitza Git. Requereix Git instal·lat i us permet canviar a utilitzar Git de manera nativa amb l’historial complet de les vostres traduccions.
Weblate també pot funcionar sense un VCS remot. Les traduccions inicials s’importen penjant-les. Més endavant podeu substituir fitxers individuals per la càrrega de fitxers o afegir cadenes de traducció directament des de Weblate (actualment disponible només per a traduccions monolingües).
En segon pla, Weblate us crea un repositori Git i es fa un seguiment de tots els canvis. En cas que després decidiu utilitzar un VCS per emmagatzemar les traduccions, ja teniu un repositori a Weblate en què podeu basar la vostra integració.