# Code-hosting integrations Weblate integrates with code-hosting sites in several separate places: repository access, incoming notifications, and pushing translations back. The exact setup depends on whether you use Hosted Weblate or run your own Weblate instance, and on whether Weblate should push directly or create pull or merge requests. Utilitzeu aquesta pàgina com a llista de verificació orientada al proveïdor. Les pàgines de configuració individuals continuen sent la referència canònica per configurar la sintaxi. ## Setup overview 1. Grant Weblate access to the repository. * For GitHub repositories on Hosted Weblate, use the [Hosted Weblate app](https://github.com/apps/hosted-weblate) from Weblate’s Connect GitHub account flow. The App gives Hosted Weblate repository access without inviting the hosted weblate user. * For other Hosted Weblate repositories, and for direct SSH pushes outside the GitHub App workflow, add the hosted weblate user where it is available, see [Accés als repositoris des de Hosted Weblate](https://docs.weblate.org/ca/latest/vcs.md#hosted-push). * For self-hosted Weblate, create a dedicated code-hosting user and grant access using Weblate’s SSH key or an HTTPS token, see [Accessing repositories on code-hosting sites (GitHub, GitLab, Bitbucket, Azure DevOps, …)](https://docs.weblate.org/ca/latest/vcs.md#vcs-repos-code-hosting). 2. Configureu [Repositori del codi font](https://docs.weblate.org/ca/latest/admin/projects.md#component-repo) perquè Weblate pugui clonar el repositori. 3. Configure incoming notifications so Weblate pulls changes soon after a push. The repository webhook or app must point to the matching Weblate hook URL, and the project must have [Activa els punts d’inserció](https://docs.weblate.org/ca/latest/admin/projects.md#project-enable-hooks) enabled. Component [Repositori del codi font](https://docs.weblate.org/ca/latest/admin/projects.md#component-repo) must match a repository URL from the webhook payload; see [Matching webhook targets](https://docs.weblate.org/ca/latest/admin/continuous.md#hooks-target-matching). 4. Decidiu com Weblate hauria de retrocedir les traduccions: * Utilitzeu [Git](https://docs.weblate.org/ca/latest/vcs.md#vcs-git) o [Mercurial](https://docs.weblate.org/ca/latest/vcs.md#vcs-mercurial) i [URL de pujada al repositori](https://docs.weblate.org/ca/latest/admin/projects.md#component-push) per empènyer directament. * Utilitzeu un backend VCS específic del proveïdor, com ara GitHub o GitLab, per crear sol·licituds d’extracció o fusió. Aquests backends necessiten credencials de l’API a la configuració de Weblate. 5. Opcionalment, configureu [Branca per a la pujada](https://docs.weblate.org/ca/latest/admin/projects.md#component-push-branch) quan Weblate hauria d’empènyer a una branca del dipòsit amunt en lloc d’utilitzar una bifurcació quan sigui compatible. ## Impulsant canvis des de Weblate Cada component de traducció pot tenir configurat un URL push (vegeu [URL de pujada al repositori](https://docs.weblate.org/ca/latest/admin/projects.md#component-push)), i en aquest cas Weblate podrà enviar canvis al repositori remot. Weblate també es pot configurar per introduir canvis automàticament a cada commit; això està habilitat per defecte, vegeu [Puja en fer una comissió](https://docs.weblate.org/ca/latest/admin/projects.md#component-push-on-commit). Si no voleu que els canvis s’enviïn automàticament, podeu enviar manualment a Manteniment del repositori o utilitzant l’API mitjançant [`wlc push`](https://docs.weblate.org/ca/latest/wlc.md#cmdoption-wlc-arg-push). In case you do not want direct pushes by Weblate, there is support for [GitHub pull requests](#code-hosting-github-pull-requests), [GitLab merge requests](#code-hosting-gitlab-merge-requests), [Gitea pull requests](#code-hosting-gitea-pull-requests), [Pagure merge requests](#code-hosting-pagure-merge-requests), [Azure DevOps pull requests](#code-hosting-azure-devops-pull-requests), or [Gerrit review requests](#code-hosting-gerrit) reviews. You can activate these by choosing GitHub, GitLab, Gitea, Gerrit, Azure DevOps, or Pagure as [Sistema de control de versions](https://docs.weblate.org/ca/latest/admin/projects.md#component-vcs) in [Configuració dels components](https://docs.weblate.org/ca/latest/admin/projects.md#component). En general, les opcions següents estan disponibles amb Git, Mercurial, GitHub, GitLab, Gitea, Pagure, Azure DevOps, Gerrit, Bitbucket Data Center i Bitbucket Cloud: | Configuració desitjada | [Sistema de control de versions](https://docs.weblate.org/ca/latest/admin/projects.md#component-vcs) | [URL de pujada al repositori](https://docs.weblate.org/ca/latest/admin/projects.md#component-push) | [Branca per a la pujada](https://docs.weblate.org/ca/latest/admin/projects.md#component-push-branch) | |-----------------------------------------------------------|-----------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------| | Sense empenta | [Git](https://docs.weblate.org/ca/latest/vcs.md#vcs-git) | “buit” | “buit” | | Empènyer directament | [Git](https://docs.weblate.org/ca/latest/vcs.md#vcs-git) | SSH URL | “buit” | | Push to separate branch | [Git](https://docs.weblate.org/ca/latest/vcs.md#vcs-git) | SSH URL | Nom de la sucursal | | Sense empenta | [Mercurial](https://docs.weblate.org/ca/latest/vcs.md#vcs-mercurial) | “buit” | “buit” | | Empènyer directament | [Mercurial](https://docs.weblate.org/ca/latest/vcs.md#vcs-mercurial) | SSH URL | “buit” | | Sol·licitud d’extracció de GitHub des de la bifurcació | [GitHub pull requests](#code-hosting-github-pull-requests) | “buit” | “buit” | | Sol·licitud d’extracció de GitHub des de la sucursal | [GitHub pull requests](#code-hosting-github-pull-requests) | URL SSH [1](#empty) | Nom de la sucursal | | Sol·licitud de combinació de GitLab des de la bifurcació | [GitLab merge requests](#code-hosting-gitlab-merge-requests) | “buit” | “buit” | | Sol·licitud de combinació de GitLab des de la branca | [GitLab merge requests](#code-hosting-gitlab-merge-requests) | URL SSH [1](#empty) | Nom de la sucursal | | Gitea merge request from fork | [Gitea pull requests](#code-hosting-gitea-pull-requests) | “buit” | “buit” | | Gitea merge request from branch | [Gitea pull requests](#code-hosting-gitea-pull-requests) | URL SSH [1](#empty) | Nom de la sucursal | | Sol·licitud de combinació de pàgines des de la bifurcació | [Pagure merge requests](#code-hosting-pagure-merge-requests) | “buit” | “buit” | | Sol·licitud de combinació de pàgines des de la sucursal | [Pagure merge requests](#code-hosting-pagure-merge-requests) | URL SSH [1](#empty) | Nom de la sucursal | | Azure DevOps pull request from fork | [Azure DevOps pull requests](#code-hosting-azure-devops-pull-requests) | “buit” | “buit” | | Azure DevOps pull request from branch | [Azure DevOps pull requests](#code-hosting-azure-devops-pull-requests) | URL SSH [1](#empty) | Nom de la sucursal | | Gerrit review | [Gerrit review requests](#code-hosting-gerrit) | SSH URL | Target branch name (optional) | | Bitbucket Data Center pull request from fork | [Bitbucket Data Center pull requests](#code-hosting-bitbucket-data-center-pull-requests) | “buit” | “buit” | | Bitbucket Data Center pull request from branch | [Bitbucket Data Center pull requests](#code-hosting-bitbucket-data-center-pull-requests) | URL SSH [1](#empty) | Nom de la sucursal | | Bitbucket Cloud pull request from fork | [Bitbucket Cloud pull requests](#code-hosting-bitbucket-cloud-pull-requests) | “buit” | “buit” | | Bitbucket Cloud pull request from branch | [Bitbucket Cloud pull requests](#code-hosting-bitbucket-cloud-pull-requests) | URL SSH [1](#empty) | Nom de la sucursal | * **[1]** Pot estar buit en cas que [Repositori del codi font](https://docs.weblate.org/ca/latest/admin/projects.md#component-repo) admeti l’empenta. ## GitHub ### GitHub repository access #### Hosted Weblate GitHub App On Hosted Weblate, the recommended setup is to connect the [Hosted Weblate app](https://github.com/apps/hosted-weblate) from the Weblate workspace where your project lives. Use the Connect GitHub account flow, install the App on the GitHub user or organization that owns your repositories, grant it access to the repositories you want to translate, and import components from the connected GitHub account. The App-backed workflow uses GitHub installation access tokens for cloning, pushing translation branches, creating pull requests, and receiving incoming notifications. You do not need to invite the Hosted Weblate weblate GitHub user or configure a separate repository webhook for components imported this way. Use the Hosted Weblate weblate GitHub user only when you intentionally configure direct SSH pushes outside the GitHub App workflow, see [Accés als repositoris des de Hosted Weblate](https://docs.weblate.org/ca/latest/vcs.md#hosted-push). #### HTTPS amb testimoni d’accés personal Per a un únic dipòsit privat, l’accés HTTPS amb un testimoni d’accés sol ser la configuració més senzilla quan el proveïdor admet Git sobre HTTPS. Utilitzeu el nom d’usuari i el testimoni necessaris pel proveïdor a [Repositori del codi font](https://docs.weblate.org/ca/latest/admin/projects.md#component-repo). Configureu [URL de pujada al repositori](https://docs.weblate.org/ca/latest/admin/projects.md#component-push) només quan Weblate hagi d’enviar els canvis directament o quan el flux de treball escollit requereixi un URL push, vegeu [Impulsant canvis des de Weblate](#code-hosting-push-options). El testimoni necessita accés de lectura per a la clonació i accés d’escriptura per push. Els backends VCS específics del proveïdor que creen sol·licituds d’extracció o fusió poden requerir credencials d’API separades. Per utilitzar aquest enfocament: 1. Creeu un testimoni d’accés personal tal com es descriu a [Creació d’un testimoni d’accés per a l’ús de la línia d’ordres](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token). 2. Incloeu el testimoni a l’URL del vostre dipòsit: `https://username:token@github.com/owner/repo.git`. Això és adequat quan comenceu amb Weblate o treballeu amb un únic dipòsit. #### SSH with a dedicated user Per a configuracions amb diversos dipòsits, utilitzeu l’accés SSH amb un usuari d’allotjament de codi dedicat per a Weblate. Afegiu la clau SSH pública de Weblate a aquest usuari, concediu-li accés als repositoris i utilitzeu URL SSH a [Repositori del codi font](https://docs.weblate.org/ca/latest/admin/projects.md#component-repo), per exemple `git@example.com:group/project.git`. Configureu [URL de pujada al repositori](https://docs.weblate.org/ca/latest/admin/projects.md#component-push) només quan Weblate hagi d’enviar els canvis directament o quan el flux de treball escollit requereixi un URL push, vegeu [Impulsant canvis des de Weblate](#code-hosting-push-options). Això també evita les restriccions del proveïdor sobre la reutilització de claus SSH. Alguns llocs d’allotjament de codi permeten afegir una clau SSH pública només una vegada, o només a un sol usuari o implementar una entrada de clau. Mantenir la clau SSH de Weblate en un usuari dedicat permet que aquest usuari tingui accés a diversos dipòsits sense reutilitzar la clau en diversos llocs. Això manté els testimonis d’accés personals, de projecte o d’API fora dels URL del dipòsit. Les credencials de l’API del proveïdor encara són necessàries quan s’utilitza un backend VCS específic del proveïdor per crear sol·licituds d’extracció o fusió; aquestes credencials es configuren per separat de l’URL del dipòsit de Git. Per a GitHub, creeu un usuari dedicat, per exemple `weblate-bot`, i utilitzeu els URL SSH de GitHub per als vostres dipòsits, per exemple `git@github.com:owner/repo.git`. On Hosted Weblate, use this SSH-user workflow only for direct SSH pushes outside the recommended [Hosted Weblate app](https://github.com/apps/hosted-weblate) workflow. #### NOTE Quan s’utilitza GitHub per a sol·licituds d’extracció, la configuració [Branca per a la pujada](https://docs.weblate.org/ca/latest/admin/projects.md#component-push-branch) afecta el comportament: si no s’estableix, el projecte es bifurca i els canvis s’envien a través d’una bifurcació. Si s’estableix, els canvis s’envien al repositori amunt i a la branca escollida. ### GitHub notifications Weblate inclou suport natiu per a GitHub. If you are using Hosted Weblate, use the [Hosted Weblate app](https://github.com/apps/hosted-weblate) from Weblate’s Connect GitHub account flow. It uses GitHub App webhooks, so you do not need to configure a separate Webhook in GitHub. Components imported from the connected GitHub account also use the App for repository access and pull requests, without inviting the Hosted Weblate weblate GitHub user. The [Hosted Weblate legacy app](https://github.com/apps/hosted-weblate-legacy) is kept for existing webhook-only setups. Its deliveries use the generic GitHub webhook URL and are authenticated using a separate webhook secret configured by the Hosted Weblate operator. Use it only when you need the legacy app to deliver GitHub notifications to Hosted Weblate. For self-hosted Weblate, register the GitHub App using the in-app registration flow described below. Weblate generates the App manifest, GitHub returns the credentials, and they are stored in the database - there is no settings-based configuration. #### Registering the GitHub App from Weblate The fastest way to add the GitHub App is to let Weblate generate a GitHub App manifest with the correct permissions, events, and webhook URL pre-filled: 1. Sign in to Weblate with an account that has management access. 2. Open Manage → Code-hosting connections → Register Weblate GitHub App. 3. Fill in the form. The GitHub host defaults to `github.com`; change it to your GitHub Enterprise hostname if needed. Leave Organization blank to register the App under your personal account, or enter an organization slug to register it under that org. 4. Click Continue to GitHub and confirm on GitHub’s Create GitHub App page (you can still rename the App there). 5. GitHub redirects back to Weblate, which exchanges the temporary code for the App ID, private key, webhook secret, and slug and stores them in the database. The Connect GitHub account button is available immediately afterwards. The manifest requests the permissions and event subscriptions Weblate needs (`Contents` and `Pull requests` read/write, `Metadata` read-only, `Organization administration` read-only, `Workflows` read/write, and the `Installation`, `Meta` and `Push` events), and sets the callback, setup and per-app webhook URLs automatically, so no manual GitHub App configuration is required. GitHub delivers the `Installation` and `Installation repositories` events to all GitHub Apps by default. GitHub only offers accounts where the signed-in GitHub user can install or request the app. If an organization is not shown during the install flow, check the user’s organization role and the organization’s GitHub App installation restrictions. On GitHub.com, public apps can be installed on other accounts; private apps can only be installed on the account that owns the app. #### Connecting a workspace Connected GitHub accounts are bound to a Weblate [workspace](https://docs.weblate.org/ca/latest/admin/workspaces.md#workspaces). A user with project administration rights for any project in a workspace can connect a GitHub account on that workspace. After connecting, every project in the workspace can import components from repositories the GitHub App installation has access to. For organization accounts, Weblate verifies that the install-time GitHub user can administer the organization installation. Projects that are not in a workspace cannot connect a GitHub account through the GitHub App. Removing a connected GitHub account also uninstalls the App from GitHub when no other Weblate workspace uses that installation. If another workspace still uses the installation, Weblate removes only the selected workspace connection. Components imported through that connection lose access to their repositories. Removing a workspace uninstalls its connected accounts the same way. Weblate removes the connection even when GitHub no longer knows about the installation, and keeps it only when GitHub could not be reached, so that the removal can be retried. Components imported through the GitHub App flow use the dedicated GitHub (via Weblate GitHub app) VCS backend. The component settings UI keeps the repository URL read-only to prevent the App-issued credentials from being redirected to an unrelated repository. #### Migrating existing components Weblate reports an informational diagnostic for Git and GitHub pull request components that can be migrated to a registered Weblate GitHub App. Follow the Migrate to GitHub App link from the diagnostic to review all eligible components in the workspace. Connect or update the GitHub account for the workspace, grant the App access to the listed repositories, and select the components to migrate. Weblate changes the selected components to the GitHub (via Weblate GitHub app) VCS backend, replaces their repository addresses with canonical HTTPS clone URLs, and removes separate push URLs because the App authenticates pushes to the source repository. #### App webhook URL Each registered Weblate GitHub App has its own webhook URL containing an opaque token that uniquely identifies a single registered App: ```text https://weblate.example.com/hooks/integrations// ``` Components using the GitHub (via Weblate GitHub app) VCS backend are matched only through this dedicated endpoint. All generic forge webhook endpoints exclude them from matching and response diagnostics, including `/hooks/github/`. Legacy GitHub App deliveries sent to the generic endpoint can match only components using a non-App VCS backend. If you are not using a GitHub App, add the Weblate webhook in the repository settings (Webhooks) to receive notifications on every push to a GitHub repository, as shown on the image below: ![image](images/github-settings.png) El Payload URL consisteix en l’URL del vostre lloc web adjunt per `/hooks/github/`, per exemple, per al servei Hosted Weblate, això és `https://hosted.weblate.org/hooks/github/`. Podeu deixar altres valors a la configuració predeterminada. Weblate pot gestionar ambdós tipus de contingut i només consumeix l’esdeveniment push. #### SEE ALSO * [`POST /hooks/github/`](https://docs.weblate.org/ca/latest/api.md#post--hooks-github-) * [Accés als repositoris des de Hosted Weblate](https://docs.weblate.org/ca/latest/vcs.md#hosted-push) ### GitHub pull requests This adds a thin layer atop [Git](https://docs.weblate.org/ca/latest/vcs.md#vcs-git) using the [GitHub API](https://docs.github.com/en/rest) to allow pushing translation changes as pull requests, instead of pushing directly to the repository. [Git](https://docs.weblate.org/ca/latest/vcs.md#vcs-git) envia els canvis directament a un repositori, mentre que el backend de GitHub crea sol·licituds d’extracció. Aquest últim no és necessari només per accedir als repositoris Git. Per crear sol·licituds d’extracció, seleccioneu GitHub com a [Sistema de control de versions](https://docs.weblate.org/ca/latest/admin/projects.md#component-vcs) i configureu [`GITHUB_CREDENTIALS`](https://docs.weblate.org/ca/latest/admin/config.md#std-setting-GITHUB_CREDENTIALS). Per a GitHub.com, utilitzeu `api.github.com` com a amfitrió de l’API. El testimoni ha de permetre a Weblate llegir i escriure continguts del repositori i crear sol·licituds d’extracció. Si Weblate ha de bifurcar els dipòsits privats, el testimoni també pot necessitar accés d’administració. ## GitLab ### GitLab repository access #### HTTPS with personal or project access token Per a un únic dipòsit privat, l’accés HTTPS amb un testimoni d’accés sol ser la configuració més senzilla quan el proveïdor admet Git sobre HTTPS. Utilitzeu el nom d’usuari i el testimoni necessaris pel proveïdor a [Repositori del codi font](https://docs.weblate.org/ca/latest/admin/projects.md#component-repo). Configureu [URL de pujada al repositori](https://docs.weblate.org/ca/latest/admin/projects.md#component-push) només quan Weblate hagi d’enviar els canvis directament o quan el flux de treball escollit requereixi un URL push, vegeu [Impulsant canvis des de Weblate](#code-hosting-push-options). El testimoni necessita accés de lectura per a la clonació i accés d’escriptura per push. Els backends VCS específics del proveïdor que creen sol·licituds d’extracció o fusió poden requerir credencials d’API separades. Per a GitLab, el testimoni necessita l’àmbit write_repository per poder impulsar canvis al dipòsit. El testimoni d’accés al projecte requereix el rol de Desenvolupador per impulsar. L’URL ha de contenir un nom d’usuari. Per a un testimoni d’accés personal, és el nom d’usuari real: `https://user:personal_access_token@gitlab.com/example/example.git`. Per als testimonis d’accés al projecte, pot ser un valor no en blanc: `https://example:project_access_token@gitlab.com/example/example.git`. #### NOTE Les regles per utilitzar fitxes d’accés al projecte han canviat entre les versions de GitLab, el valor no en blanc és el requisit actual, però les versions anteriors tenien expectatives diferents (nom del projecte, nom d’usuari del bot). Comproveu la documentació de GitLab que coincideix amb la vostra versió si no esteu segurs. #### SSH with a dedicated user Per a configuracions amb diversos dipòsits, utilitzeu l’accés SSH amb un usuari d’allotjament de codi dedicat per a Weblate. Afegiu la clau SSH pública de Weblate a aquest usuari, concediu-li accés als repositoris i utilitzeu URL SSH a [Repositori del codi font](https://docs.weblate.org/ca/latest/admin/projects.md#component-repo), per exemple `git@example.com:group/project.git`. Configureu [URL de pujada al repositori](https://docs.weblate.org/ca/latest/admin/projects.md#component-push) només quan Weblate hagi d’enviar els canvis directament o quan el flux de treball escollit requereixi un URL push, vegeu [Impulsant canvis des de Weblate](#code-hosting-push-options). Això també evita les restriccions del proveïdor sobre la reutilització de claus SSH. Alguns llocs d’allotjament de codi permeten afegir una clau SSH pública només una vegada, o només a un sol usuari o implementar una entrada de clau. Mantenir la clau SSH de Weblate en un usuari dedicat permet que aquest usuari tingui accés a diversos dipòsits sense reutilitzar la clau en diversos llocs. Això manté els testimonis d’accés personals, de projecte o d’API fora dels URL del dipòsit. Les credencials de l’API del proveïdor encara són necessàries quan s’utilitza un backend VCS específic del proveïdor per crear sol·licituds d’extracció o fusió; aquestes credencials es configuren per separat de l’URL del dipòsit de Git. Per a GitLab, creeu un usuari dedicat i utilitzeu els URL SSH de GitLab, per exemple `git@gitlab.com:group/project.git`. For Hosted Weblate repositories on GitLab, add the hosted weblate user with the required repository permissions, see [Accés als repositoris des de Hosted Weblate](https://docs.weblate.org/ca/latest/vcs.md#hosted-push). ### GitLab notifications Weblate té suport per a ganxos GitLab. Afegiu un webhook de projecte amb destinació a l’URL `/hooks/gitlab/` a la vostra instal·lació de Weblate, per exemple `https://hosted.weblate.org/hooks/gitlab/`. #### SEE ALSO * [`POST /hooks/gitlab/`](https://docs.weblate.org/ca/latest/api.md#post--hooks-gitlab-) * [Accés als repositoris des de Hosted Weblate](https://docs.weblate.org/ca/latest/vcs.md#hosted-push) ### GitLab merge requests Això afegeix una capa fina a la part superior de [Git](https://docs.weblate.org/ca/latest/vcs.md#vcs-git) utilitzant la [GitLab API](https://docs.gitlab.com/api/) per permetre empènyer els canvis de traducció com a sol·licituds de combinació en lloc d’empènyer directament al repositori. No cal fer-ho servir per accedir als repositoris Git, el normal [Git](https://docs.weblate.org/ca/latest/vcs.md#vcs-git) funciona igual, l’única diferència és com es gestiona l’empensió a un repositori. Amb [Git](https://docs.weblate.org/ca/latest/vcs.md#vcs-git) els canvis s’envien directament al repositori, mentre que el backend de GitLab crea una sol·licitud de combinació. Per crear sol·licituds de combinació, seleccioneu GitLab com a [Sistema de control de versions](https://docs.weblate.org/ca/latest/admin/projects.md#component-vcs) i configureu [`GITLAB_CREDENTIALS`](https://docs.weblate.org/ca/latest/admin/config.md#std-setting-GITLAB_CREDENTIALS). La configuració [Branca per a la pujada](https://docs.weblate.org/ca/latest/admin/projects.md#component-push-branch) afecta on Weblate envia els canvis abans d’obrir la sol·licitud de combinació. Si no s’estableix, el projecte es bifurca i els canvis s’envien a través d’una bifurcació. Si està establert, els canvis s’envien al repositori aigües amunt i a la branca escollida. ## Gitea, Forgejo i Codeberg ### Gitea, Forgejo, and Codeberg repository access #### HTTPS amb un testimoni d’accés Per a un únic dipòsit privat, l’accés HTTPS amb un testimoni d’accés sol ser la configuració més senzilla quan el proveïdor admet Git sobre HTTPS. Utilitzeu el nom d’usuari i el testimoni necessaris pel proveïdor a [Repositori del codi font](https://docs.weblate.org/ca/latest/admin/projects.md#component-repo). Configureu [URL de pujada al repositori](https://docs.weblate.org/ca/latest/admin/projects.md#component-push) només quan Weblate hagi d’enviar els canvis directament o quan el flux de treball escollit requereixi un URL push, vegeu [Impulsant canvis des de Weblate](#code-hosting-push-options). El testimoni necessita accés de lectura per a la clonació i accés d’escriptura per push. Els backends VCS específics del proveïdor que creen sol·licituds d’extracció o fusió poden requerir credencials d’API separades. #### SSH with a dedicated user Per a configuracions amb diversos dipòsits, utilitzeu l’accés SSH amb un usuari d’allotjament de codi dedicat per a Weblate. Afegiu la clau SSH pública de Weblate a aquest usuari, concediu-li accés als repositoris i utilitzeu URL SSH a [Repositori del codi font](https://docs.weblate.org/ca/latest/admin/projects.md#component-repo), per exemple `git@example.com:group/project.git`. Configureu [URL de pujada al repositori](https://docs.weblate.org/ca/latest/admin/projects.md#component-push) només quan Weblate hagi d’enviar els canvis directament o quan el flux de treball escollit requereixi un URL push, vegeu [Impulsant canvis des de Weblate](#code-hosting-push-options). Això també evita les restriccions del proveïdor sobre la reutilització de claus SSH. Alguns llocs d’allotjament de codi permeten afegir una clau SSH pública només una vegada, o només a un sol usuari o implementar una entrada de clau. Mantenir la clau SSH de Weblate en un usuari dedicat permet que aquest usuari tingui accés a diversos dipòsits sense reutilitzar la clau en diversos llocs. Això manté els testimonis d’accés personals, de projecte o d’API fora dels URL del dipòsit. Les credencials de l’API del proveïdor encara són necessàries quan s’utilitza un backend VCS específic del proveïdor per crear sol·licituds d’extracció o fusió; aquestes credencials es configuren per separat de l’URL del dipòsit de Git. For Hosted Weblate repositories on Codeberg, add the hosted weblate user with the required repository permissions, see [Accés als repositoris des de Hosted Weblate](https://docs.weblate.org/ca/latest/vcs.md#hosted-push). ### Gitea notifications Weblate té suport per a webhooks de Gitea. Afegiu un Gitea Webhook per a l’esdeveniment Push events amb destinació a l’URL `/hooks/gitea/` a la vostra instal·lació de Weblate, per exemple `https://hosted.weblate.org/hooks/gitea/`. Això es pot fer a Webhooks al repositori Configuració. #### SEE ALSO * [Webhooks in Gitea manual](https://docs.gitea.com/usage/repository/webhooks) * [`POST /hooks/gitea/`](https://docs.weblate.org/ca/latest/api.md#post--hooks-gitea-) * [Accés als repositoris des de Hosted Weblate](https://docs.weblate.org/ca/latest/vcs.md#hosted-push) ### Forgejo notifications Weblate té suport per als webhooks de Forgejo. Afegiu un Forgejo Webhook per a l’esdeveniment Push events amb destinació a l’URL `/hooks/forgejo/` a la vostra instal·lació de Weblate, per exemple `https://hosted.weblate.org/hooks/forgejo/`. Això es pot fer a Webhooks al repositori Configuració. #### SEE ALSO * [Webhooks a la documentació de Forgejo](https://forgejo.org/docs/latest/user/webhooks/) * [`POST /hooks/forgejo/`](https://docs.weblate.org/ca/latest/api.md#post--hooks-forgejo-) * [Accés als repositoris des de Hosted Weblate](https://docs.weblate.org/ca/latest/vcs.md#hosted-push) ### Gitea pull requests #### Versionadded Afegit a la versió 4.12. Això afegeix una capa fina a la part superior de [Git](https://docs.weblate.org/ca/latest/vcs.md#vcs-git) utilitzant l”[API Gitea](https://docs.gitea.com/development/api-usage) per permetre enviar els canvis de traducció com a sol·licituds d’extracció en lloc d’empènyer directament al repositori. No cal fer-ho servir per accedir als repositoris Git, el normal [Git](https://docs.weblate.org/ca/latest/vcs.md#vcs-git) funciona igual, l’única diferència és com es gestiona l’empensió a un repositori. Amb [Git](https://docs.weblate.org/ca/latest/vcs.md#vcs-git) els canvis s’envien directament al repositori, mentre que el backend de Gitea crea sol·licituds d’extracció. Per crear sol·licituds d’extracció, seleccioneu Gitea com a [Sistema de control de versions](https://docs.weblate.org/ca/latest/admin/projects.md#component-vcs) i configureu [`GITEA_CREDENTIALS`](https://docs.weblate.org/ca/latest/admin/config.md#std-setting-GITEA_CREDENTIALS). ## Bitbucket ### Bitbucket repository access #### HTTPS amb un testimoni d’accés Per a un únic dipòsit privat, l’accés HTTPS amb un testimoni d’accés sol ser la configuració més senzilla quan el proveïdor admet Git sobre HTTPS. Utilitzeu el nom d’usuari i el testimoni necessaris pel proveïdor a [Repositori del codi font](https://docs.weblate.org/ca/latest/admin/projects.md#component-repo). Configureu [URL de pujada al repositori](https://docs.weblate.org/ca/latest/admin/projects.md#component-push) només quan Weblate hagi d’enviar els canvis directament o quan el flux de treball escollit requereixi un URL push, vegeu [Impulsant canvis des de Weblate](#code-hosting-push-options). El testimoni necessita accés de lectura per a la clonació i accés d’escriptura per push. Els backends VCS específics del proveïdor que creen sol·licituds d’extracció o fusió poden requerir credencials d’API separades. #### SSH with a dedicated user Per a configuracions amb diversos dipòsits, utilitzeu l’accés SSH amb un usuari d’allotjament de codi dedicat per a Weblate. Afegiu la clau SSH pública de Weblate a aquest usuari, concediu-li accés als repositoris i utilitzeu URL SSH a [Repositori del codi font](https://docs.weblate.org/ca/latest/admin/projects.md#component-repo), per exemple `git@example.com:group/project.git`. Configureu [URL de pujada al repositori](https://docs.weblate.org/ca/latest/admin/projects.md#component-push) només quan Weblate hagi d’enviar els canvis directament o quan el flux de treball escollit requereixi un URL push, vegeu [Impulsant canvis des de Weblate](#code-hosting-push-options). Això també evita les restriccions del proveïdor sobre la reutilització de claus SSH. Alguns llocs d’allotjament de codi permeten afegir una clau SSH pública només una vegada, o només a un sol usuari o implementar una entrada de clau. Mantenir la clau SSH de Weblate en un usuari dedicat permet que aquest usuari tingui accés a diversos dipòsits sense reutilitzar la clau en diversos llocs. Això manté els testimonis d’accés personals, de projecte o d’API fora dels URL del dipòsit. Les credencials de l’API del proveïdor encara són necessàries quan s’utilitza un backend VCS específic del proveïdor per crear sol·licituds d’extracció o fusió; aquestes credencials es configuren per separat de l’URL del dipòsit de Git. For Hosted Weblate repositories on Bitbucket, add the hosted weblate user with the required repository permissions, see [Accés als repositoris des de Hosted Weblate](https://docs.weblate.org/ca/latest/vcs.md#hosted-push). Per empènyer directament, utilitzeu [Git](https://docs.weblate.org/ca/latest/vcs.md#vcs-git) o [Mercurial](https://docs.weblate.org/ca/latest/vcs.md#vcs-mercurial) amb [URL de pujada al repositori](https://docs.weblate.org/ca/latest/admin/projects.md#component-push). ### Bitbucket notifications Weblate és compatible amb els webhooks de Bitbucket. Afegiu un webhook que s’activa en el repositori, amb destinació a l’URL `/hooks/bitbucket/` a la vostra instal·lació de Weblate, per exemple `https://hosted.weblate.org/hooks/bitbucket/`. ![image](images/bitbucket-settings.png) #### SEE ALSO * [`POST /hooks/bitbucket/`](https://docs.weblate.org/ca/latest/api.md#post--hooks-bitbucket-) * [Accés als repositoris des de Hosted Weblate](https://docs.weblate.org/ca/latest/vcs.md#hosted-push) ### Bitbucket Data Center pull requests #### Versionadded Afegit a la versió 4.16. This adds a thin layer atop [Git](https://docs.weblate.org/ca/latest/vcs.md#vcs-git) using the [Bitbucket Data Center API](https://developer.atlassian.com/server/bitbucket/) to allow pushing translation changes as pull requests instead of pushing directly to the repository. #### WARNING Això no és compatible amb l’API Bitbucket Cloud. No cal fer-ho servir per accedir als repositoris Git, el normal [Git](https://docs.weblate.org/ca/latest/vcs.md#vcs-git) funciona igual, l’única diferència és com es gestiona l’empensió a un repositori. Amb [Git](https://docs.weblate.org/ca/latest/vcs.md#vcs-git) els canvis s’envien directament al repositori, mentre que el backend de Bitbucket Data Center crea una sol·licitud d’extracció. Per crear sol·licituds d’extracció, seleccioneu Bitbucket Data Center com a [Sistema de control de versions](https://docs.weblate.org/ca/latest/admin/projects.md#component-vcs) i configureu [`BITBUCKETSERVER_CREDENTIALS`](https://docs.weblate.org/ca/latest/admin/config.md#std-setting-BITBUCKETSERVER_CREDENTIALS). ### Bitbucket Cloud pull requests #### Versionadded Afegit a la versió 5.8. Això afegeix una capa fina a la part superior de [Git](https://docs.weblate.org/ca/latest/vcs.md#vcs-git) utilitzant la [Bitbucket Cloud API](https://developer.atlassian.com/cloud/bitbucket/) per permetre empènyer els canvis de traducció com a sol·licituds d’extracció en lloc d’empènyer directament al repositori. #### WARNING This is different from Bitbucket Data Center API. No cal fer-ho servir per accedir als repositoris Git, el normal [Git](https://docs.weblate.org/ca/latest/vcs.md#vcs-git) funciona igual, l’única diferència és com es gestiona l’empensió a un repositori. Amb [Git](https://docs.weblate.org/ca/latest/vcs.md#vcs-git) els canvis s’envien directament al repositori, mentre que el backend de Bitbucket Cloud crea una sol·licitud d’extracció. Per crear sol·licituds d’extracció, seleccioneu Bitbucket Cloud com a [Sistema de control de versions](https://docs.weblate.org/ca/latest/admin/projects.md#component-vcs) i configureu [`BITBUCKETCLOUD_CREDENTIALS`](https://docs.weblate.org/ca/latest/admin/config.md#std-setting-BITBUCKETCLOUD_CREDENTIALS). ## Azure DevOps ### Azure Repos repository access #### HTTPS amb un testimoni d’accés Per a un únic dipòsit privat, l’accés HTTPS amb un testimoni d’accés sol ser la configuració més senzilla quan el proveïdor admet Git sobre HTTPS. Utilitzeu el nom d’usuari i el testimoni necessaris pel proveïdor a [Repositori del codi font](https://docs.weblate.org/ca/latest/admin/projects.md#component-repo). Configureu [URL de pujada al repositori](https://docs.weblate.org/ca/latest/admin/projects.md#component-push) només quan Weblate hagi d’enviar els canvis directament o quan el flux de treball escollit requereixi un URL push, vegeu [Impulsant canvis des de Weblate](#code-hosting-push-options). El testimoni necessita accés de lectura per a la clonació i accés d’escriptura per push. Els backends VCS específics del proveïdor que creen sol·licituds d’extracció o fusió poden requerir credencials d’API separades. Utilitzeu l’URL del clon HTTPS mostrat per Azure Repos per al dipòsit. #### SSH with a dedicated user Per a configuracions amb diversos dipòsits, utilitzeu l’accés SSH amb un usuari d’allotjament de codi dedicat per a Weblate. Afegiu la clau SSH pública de Weblate a aquest usuari, concediu-li accés als repositoris i utilitzeu URL SSH a [Repositori del codi font](https://docs.weblate.org/ca/latest/admin/projects.md#component-repo), per exemple `git@example.com:group/project.git`. Configureu [URL de pujada al repositori](https://docs.weblate.org/ca/latest/admin/projects.md#component-push) només quan Weblate hagi d’enviar els canvis directament o quan el flux de treball escollit requereixi un URL push, vegeu [Impulsant canvis des de Weblate](#code-hosting-push-options). Això també evita les restriccions del proveïdor sobre la reutilització de claus SSH. Alguns llocs d’allotjament de codi permeten afegir una clau SSH pública només una vegada, o només a un sol usuari o implementar una entrada de clau. Mantenir la clau SSH de Weblate en un usuari dedicat permet que aquest usuari tingui accés a diversos dipòsits sense reutilitzar la clau en diversos llocs. Això manté els testimonis d’accés personals, de projecte o d’API fora dels URL del dipòsit. Les credencials de l’API del proveïdor encara són necessàries quan s’utilitza un backend VCS específic del proveïdor per crear sol·licituds d’extracció o fusió; aquestes credencials es configuren per separat de l’URL del dipòsit de Git. Utilitzeu l’URL SSH mostrat per Azure Repos per al dipòsit. ### Azure Repos notifications Weblate és compatible amb els webhooks d’Azure Repos. Afegiu un webhook per a l’esdeveniment Code pushed amb destinació a l’URL `/hooks/azure/` a la vostra instal·lació de Weblate, per exemple `https://hosted.weblate.org/hooks/azure/`. Això es pot fer a Servei ganxos a Configuració del projecte. #### SEE ALSO * [Enganxos web al manual Azure DevOps](https://learn.microsoft.com/en-us/azure/devops/service-hooks/services/webhooks?view=azure-devops) * [`POST /hooks/azure/`](https://docs.weblate.org/ca/latest/api.md#post--hooks-azure-) * [Accés als repositoris des de Hosted Weblate](https://docs.weblate.org/ca/latest/vcs.md#hosted-push) ### Azure DevOps pull requests This adds a thin layer atop [Git](https://docs.weblate.org/ca/latest/vcs.md#vcs-git) using the [Azure DevOps API](https://learn.microsoft.com/en-us/rest/api/azure/devops/?view=azure-devops-rest-7.2) to allow pushing translation changes as pull requests, instead of pushing directly to the repository. [Git](https://docs.weblate.org/ca/latest/vcs.md#vcs-git) envia els canvis directament a un repositori, mentre que el backend de Azure DevOps crea sol·licituds d’extracció. Aquest últim no és necessari només per accedir als repositoris Git. Per crear sol·licituds d’extracció, seleccioneu Azure DevOps com a [Sistema de control de versions](https://docs.weblate.org/ca/latest/admin/projects.md#component-vcs) i configureu [`AZURE_DEVOPS_CREDENTIALS`](https://docs.weblate.org/ca/latest/admin/config.md#std-setting-AZURE_DEVOPS_CREDENTIALS). ## Pagure ### Pagure repository access #### HTTPS amb un testimoni d’accés Per a un únic dipòsit privat, l’accés HTTPS amb un testimoni d’accés sol ser la configuració més senzilla quan el proveïdor admet Git sobre HTTPS. Utilitzeu el nom d’usuari i el testimoni necessaris pel proveïdor a [Repositori del codi font](https://docs.weblate.org/ca/latest/admin/projects.md#component-repo). Configureu [URL de pujada al repositori](https://docs.weblate.org/ca/latest/admin/projects.md#component-push) només quan Weblate hagi d’enviar els canvis directament o quan el flux de treball escollit requereixi un URL push, vegeu [Impulsant canvis des de Weblate](#code-hosting-push-options). El testimoni necessita accés de lectura per a la clonació i accés d’escriptura per push. Els backends VCS específics del proveïdor que creen sol·licituds d’extracció o fusió poden requerir credencials d’API separades. #### SSH with a dedicated user Per a configuracions amb diversos dipòsits, utilitzeu l’accés SSH amb un usuari d’allotjament de codi dedicat per a Weblate. Afegiu la clau SSH pública de Weblate a aquest usuari, concediu-li accés als repositoris i utilitzeu URL SSH a [Repositori del codi font](https://docs.weblate.org/ca/latest/admin/projects.md#component-repo), per exemple `git@example.com:group/project.git`. Configureu [URL de pujada al repositori](https://docs.weblate.org/ca/latest/admin/projects.md#component-push) només quan Weblate hagi d’enviar els canvis directament o quan el flux de treball escollit requereixi un URL push, vegeu [Impulsant canvis des de Weblate](#code-hosting-push-options). Això també evita les restriccions del proveïdor sobre la reutilització de claus SSH. Alguns llocs d’allotjament de codi permeten afegir una clau SSH pública només una vegada, o només a un sol usuari o implementar una entrada de clau. Mantenir la clau SSH de Weblate en un usuari dedicat permet que aquest usuari tingui accés a diversos dipòsits sense reutilitzar la clau en diversos llocs. Això manté els testimonis d’accés personals, de projecte o d’API fora dels URL del dipòsit. Les credencials de l’API del proveïdor encara són necessàries quan s’utilitza un backend VCS específic del proveïdor per crear sol·licituds d’extracció o fusió; aquestes credencials es configuren per separat de l’URL del dipòsit de Git. ### Pagure notifications Weblate té suport per a ganxos Pagure. Afegiu un webhook amb destinació a l’URL `/hooks/pagure/` a la vostra instal·lació de Weblate, per exemple `https://hosted.weblate.org/hooks/pagure/`. Això es pot fer a Activar Web-hooks a Opcions del projecte: ![image](images/pagure-webhook.png) #### SEE ALSO * [`POST /hooks/pagure/`](https://docs.weblate.org/ca/latest/api.md#post--hooks-pagure-) * [Accés als repositoris des de Hosted Weblate](https://docs.weblate.org/ca/latest/vcs.md#hosted-push) ### Pagure merge requests #### Versionadded Afegit a la versió 4.3.2. Això afegeix una capa fina a la part superior de [Git](https://docs.weblate.org/ca/latest/vcs.md#vcs-git) utilitzant la [Pagure API](https://pagure.io/api/0/) per permetre empènyer els canvis de traducció com a sol·licituds de combinació en lloc d’empènyer directament al repositori. No cal fer-ho servir per accedir als repositoris Git, el normal [Git](https://docs.weblate.org/ca/latest/vcs.md#vcs-git) funciona igual, l’única diferència és com es gestiona l’empensió a un repositori. Amb [Git](https://docs.weblate.org/ca/latest/vcs.md#vcs-git) els canvis s’envien directament al repositori, mentre que el backend de Pagure crea una sol·licitud de combinació. Per crear sol·licituds de combinació, seleccioneu Pagure com a [Sistema de control de versions](https://docs.weblate.org/ca/latest/admin/projects.md#component-vcs) i configureu [`PAGURE_CREDENTIALS`](https://docs.weblate.org/ca/latest/admin/config.md#std-setting-PAGURE_CREDENTIALS). ## Altres fluxos de treball ### Gitee repository access #### HTTPS amb un testimoni d’accés Per a un únic dipòsit privat, l’accés HTTPS amb un testimoni d’accés sol ser la configuració més senzilla quan el proveïdor admet Git sobre HTTPS. Utilitzeu el nom d’usuari i el testimoni necessaris pel proveïdor a [Repositori del codi font](https://docs.weblate.org/ca/latest/admin/projects.md#component-repo). Configureu [URL de pujada al repositori](https://docs.weblate.org/ca/latest/admin/projects.md#component-push) només quan Weblate hagi d’enviar els canvis directament o quan el flux de treball escollit requereixi un URL push, vegeu [Impulsant canvis des de Weblate](#code-hosting-push-options). El testimoni necessita accés de lectura per a la clonació i accés d’escriptura per push. Els backends VCS específics del proveïdor que creen sol·licituds d’extracció o fusió poden requerir credencials d’API separades. #### SSH with a dedicated user Per a configuracions amb diversos dipòsits, utilitzeu l’accés SSH amb un usuari d’allotjament de codi dedicat per a Weblate. Afegiu la clau SSH pública de Weblate a aquest usuari, concediu-li accés als repositoris i utilitzeu URL SSH a [Repositori del codi font](https://docs.weblate.org/ca/latest/admin/projects.md#component-repo), per exemple `git@example.com:group/project.git`. Configureu [URL de pujada al repositori](https://docs.weblate.org/ca/latest/admin/projects.md#component-push) només quan Weblate hagi d’enviar els canvis directament o quan el flux de treball escollit requereixi un URL push, vegeu [Impulsant canvis des de Weblate](#code-hosting-push-options). Això també evita les restriccions del proveïdor sobre la reutilització de claus SSH. Alguns llocs d’allotjament de codi permeten afegir una clau SSH pública només una vegada, o només a un sol usuari o implementar una entrada de clau. Mantenir la clau SSH de Weblate en un usuari dedicat permet que aquest usuari tingui accés a diversos dipòsits sense reutilitzar la clau en diversos llocs. Això manté els testimonis d’accés personals, de projecte o d’API fora dels URL del dipòsit. Les credencials de l’API del proveïdor encara són necessàries quan s’utilitza un backend VCS específic del proveïdor per crear sol·licituds d’extracció o fusió; aquestes credencials es configuren per separat de l’URL del dipòsit de Git. ### Gitee notifications Weblate és compatible amb els webhooks de Gitee. Afegiu un WebHook per a l’esdeveniment Push amb destinació a l’URL `/hooks/gitee/` a la vostra instal·lació de Weblate, per exemple `https://hosted.weblate.org/hooks/gitee/`. Això es pot fer a WebHooks al repositori Gestió. #### SEE ALSO * [Webhooks in Gitee manual](https://help.gitee.com/webhook) * [`POST /hooks/gitee/`](https://docs.weblate.org/ca/latest/api.md#post--hooks-gitee-) * [Accés als repositoris des de Hosted Weblate](https://docs.weblate.org/ca/latest/vcs.md#hosted-push) ### Gerrit review requests Gerrit support adds a thin layer atop [Git](https://docs.weblate.org/ca/latest/vcs.md#vcs-git) using the [git-review](https://pypi.org/project/git-review/) tool to allow pushing translation changes as Gerrit review requests, instead of pushing them directly to the repository. The optional [Branca per a la pujada](https://docs.weblate.org/ca/latest/admin/projects.md#component-push-branch) setting selects the target branch for the Gerrit review. Leave it empty to use [Branca del repositori](https://docs.weblate.org/ca/latest/admin/projects.md#component-branch). Use the short branch name, such as `main`; Weblate and `git-review` push the review to `refs/for/` automatically. Gerrit push options can be appended after `%` in either setting, for example `main%topic=l10n`. Gerrit interprets these options as the configured Weblate Gerrit account and applies its own permissions. The Gerrit documentation has the details on the configuration necessary to set up such repositories. There is no separate code-hosting credential setting for this backend. ### Credencials de Docker For Docker installations, code-hosting API credentials can also be provided through environment variables, see [Code-hosting sites credentials](https://docs.weblate.org/ca/latest/admin/install/docker.md#docker-vcs-config).