Integrare control versiune¶
Weblate currently supports Git (with extended support for GitHub solicitări de tracțiune, Cereri de fuziune GitLab, Gitea cereri de pull, Gerrit, Subversiune, Bitbucket Cloud pull requests, Bitbucket Data Center pull requests, and Azure DevOps pull requests) and Mercurial as version control back-ends.
Accesarea depozitelor¶
Depozitul VCS pe care doriți să îl utilizați trebuie să fie accesibil pentru Weblate. În cazul unui depozit public, trebuie doar să introduceți URL-ul corect (de exemplu https://github.com/WeblateOrg/weblate.git), dar pentru depozitele private sau pentru URL-urile push, configurarea este mai complexă și necesită autentificare.
Accesarea depozitelor din Weblate găzduit¶
Notă
This section applies only to Hosted Weblate (hosted.weblate.org). If you are running your own self-hosted Weblate instance, please see the next section instead.
For Hosted Weblate, there is a dedicated push user registered on GitHub,
Bitbucket, Codeberg, and GitLab (with the username weblate, e-mail
hosted@weblate.org, and a name or profile description Weblate push user).
Sugestie
There can be more Weblate users on the platforms, designated for other Weblate instances.
Searching by e-mail hosted@weblate.org is recommended to find the correct
user for Hosted Weblate.
You need to add this user as a collaborator and give it appropriate permissions to your repository (read-only is okay for cloning, write is required for pushing). Depending on the service and your organization’s settings, this happens immediately, or requires confirmation on the Weblate side.
Utilizatorul weblate de pe GitHub acceptă invitații în mod automat în cinci minute. Este posibil să fie necesară o procesare manuală pe celelalte servicii, așa că vă rugăm să aveți răbdare.
Once the weblate user is added to your repository, you can configure
Depozitar cod sursă and URL de încărcare depozitar using the SSH protocol (for example
git@github.com:WeblateOrg/weblate.git).
Accessing repositories on code hosting sites (GitHub, GitLab, Bitbucket, Azure DevOps, …)¶
Notă
This section applies to self-hosted Weblate instances. If you are using Hosted Weblate (hosted.weblate.org), see Accesarea depozitelor din Weblate găzduit instead.
For self-hosted Weblate, accessing repositories on code hosting sites is typically done by creating a dedicated user who is associated with a Weblate SSH key (see Cheie SSH Weblate). This way you associate Weblate SSH key with a single user (platforms frequently enforce single use of a SSH key) and grant this user access to the repository. You can then use SSH URL to access the repository (see Depozite SSH).
Depozite SSH¶
Cea mai frecvent utilizată metodă de accesare a depozitelor private se bazează pe SSH. Autorizați cheia SSH publică Weblate (a se vedea Cheie SSH Weblate) pentru a accesa în acest mod depozitul upstream.
Atenționare
Pe GitHub, fiecare cheie poate fi folosită doar o singură dată, vezi Depozite GitHub și Accesarea depozitelor din Weblate găzduit.
Weblate stochează, de asemenea, amprenta digitală a cheii gazdă la prima conectare și nu reușește să se conecteze la gazdă în cazul în care aceasta este modificată ulterior (a se vedea Verificarea cheilor gazdă SSH).
În cazul în care este necesară o ajustare, faceți acest lucru din interfața de administrare Weblate:
Cheie SSH Weblate¶
Schimbat în versiunea 4.17: Weblate now generates both RSA and Ed25519 SSH keys. Using Ed25519 is recommended for new setups.
Cheia publică Weblate este vizibilă pentru toți utilizatorii care navighează pe pagina About.
Administratorii pot genera sau afișa cheia publică utilizată în prezent de Weblate în conexiune (din SSH keys) pe pagina de destinație a interfeței de administrare.
Notă
The corresponding private SSH key can not currently have a password, so ensure it is well protected.
Sugestie
Efectuați o copie de rezervă a cheii SSH Weblate private generate.
Verificarea cheilor gazdă SSH¶
Weblate stochează automat cheile gazdă SSH la prima accesare și le reține pentru utilizare ulterioară.
În cazul în care doriți să verificați amprenta cheii înainte de a vă conecta la depozit, adăugați cheile gazdă SSH ale serverelor pe care le veți accesa în Adaugă cheie gazdă, din aceeași secțiune a interfeței de administrare. Introduceți numele gazdei pe care urmează să o accesați (de exemplu, gitlab.com) și apăsați Submit. Verificați dacă amprenta sa se potrivește cu cea a serverului pe care l-ați adăugat.
Cheile adăugate cu amprentele digitale sunt afișate în mesajul de confirmare:
Connecting to legacy SSH servers¶
Recent OpenSSH releases (for example the one used in Weblate Docker container) disable RSA signatures using the SHA-1 hash algorithm by default. This change has been made as the SHA-1 hash algorithm is cryptographically broken, and it is possible to create chosen-prefix hash collisions for <USD$50K.
For most users, this change should be invisible and there is no need to replace ssh-rsa keys. OpenSSH has supported RFC8332 RSA/SHA-256/512 signatures since release 7.2 and existing ssh-rsa keys will automatically use the stronger algorithm where possible.
Incompatibility is more likely when connecting to older SSH implementations that have not been upgraded or have not closely tracked improvements in the SSH protocol. The SSH connection to such server will fail with:
no matching host key type found. Their offer: ssh-rsa
For these cases, it may be necessary to selectively re-enable RSA/SHA1 to allow
connection and/or user authentication via the HostkeyAlgorithms and
PubkeyAcceptedAlgorithms options. For example, the following stanza in
DATA_DIR/ssh/config will enable RSA/SHA1 for host and user
authentication for a single destination host:
Host legacy-host
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
We recommend enabling RSA/SHA1 only as a stopgap measure until legacy implementations can be upgraded or reconfigured with another key type (such as ECDSA or Ed25519).
Depozite GitHub¶
There are two main approaches to accessing GitHub repositories with Weblate:
Option 1: HTTPS with Personal Access Token (simpler for getting started)
Use HTTPS authentication with a personal access token and your GitHub account. This works for both read-only access (cloning) and read-write access (pushing changes or creating pull requests).
To use this approach:
Create a personal access token as described in Creating an access token for command-line use.
Include the token in your repository URL:
https://username:token@github.com/owner/repo.git
This is suitable when you’re starting with Weblate or working with a single repository.
Option 2: SSH with Dedicated User (recommended for multiple repositories)
For setups with multiple repositories, it is recommended to create a dedicated user for Weblate. This avoids GitHub’s limitation that each SSH key can only be used once per platform.
To use this approach:
Create a dedicated GitHub user account (e.g.,
weblate-bot)Add Weblate’s public SSH key to this user (see Cheie SSH Weblate)
Grant this user access to all repositories you want to translate
Use SSH URLs for your repositories:
git@github.com:owner/repo.git
This approach is also used for Hosted Weblate, which has a dedicated weblate user for that purpose.
Notă
When using GitHub solicitări de tracțiune for pull requests, the Încarcă ramură configuration affects the behavior: if not set, the project is forked and changes are pushed through a fork. If set, changes are pushed to the upstream repository and the chosen branch.
GitLab repositories¶
Access via SSH is possible (see Depozite SSH), but in case you need to access more than one repository, you will hit a GitLab limitation on allowed SSH key usage (since each key can be used only once).
În cazul în care Încarcă ramură nu este setat, proiectul este bifurcat și modificările sunt împinse prin intermediul unei bifurcații. În cazul în care este setat, modificările sunt împinse în depozitul din upstream și în branșa aleasă.
Using personal or project access tokens is possible as well. The token needs write_repository scope to be able to push changes to the repository. The project access token requires Developer role for pushing.
The URL needs to contain an username, for personal access token it is the
actual username (
https://user:personal_access_token@gitlab.com/example/example.git) for
project access tokens it can be non-blank value
(https://example:project_access_token@gitlab.com/example/example.git).
Notă
The rules for using project access tokens has changed between GitLab releases, the non-blank value is the current requirement, but older versions had different expectations (project name, bot user name). Check GitLab documentation matching your version if unsure.
URL-uri interne Weblate¶
Share one repository setup between different components by referring to its
placement as weblate://project/component in other (linked) components. This
way linked components use the VCS repository configuration of the
main (referenced) component.
Atenționare
Îndepărtarea componentei principale înlătură și componentele legate.
Weblate ajustează automat URL-ul de depozit la crearea unei componente dacă găsește o componentă cu o configurație de depozit corespunzătoare. Puteți suprascrie acest lucru în ultimul pas al configurării componentei.
Motive pentru a utiliza acest lucru:
Economisește spațiu pe disc pe server, depozitul este stocat doar o singură dată.
Face ca actualizările să fie mai rapide, se actualizează doar un singur depozit.
Există doar un singur depozit exportat cu traducerile Weblate (vezi Exportator Git).
Unele add-onuri pot funcționa pe mai multe componente care împart un depozit, de exemplu Comasează comiteri Git.
Depozite HTTPS¶
Vezi și
Pentru a accesa depozite HTTPS protejate, includeți numele de utilizator și parola în URL. Nu vă faceți griji, Weblate va elimina aceste informații atunci când URL-ul este afișat utilizatorilor (dacă li se permite să vadă URL-ul depozitului).
De exemplu, URL-ul GitHub cu autentificarea adăugată ar putea arăta astfel: https://user:your_access_token@github.com/WeblateOrg/weblate.git.
In case you don’t provide credentials in the URL and the repository requires it, Git will fail with an error:
fatal: could not read Username for 'https://github.com': terminal prompts disabled
Schimbat în versiunea 5.10.2: Weblate uses proactive authentication with Git 2.46.0 and newer when HTTP credentials are supplied.
This makes it possible to access Azure DevOps repositories and makes access to authenticated repositories faster.
Notă
Dacă numele de utilizator sau parola conțin caractere speciale, acestea trebuie să fie codificate URL, de exemplu https://user%40example.com:%24password%23@bitbucket.org/....
Utilizarea proxy¶
Dacă trebuie să accesați depozitele VCS HTTP/HTTPS utilizând un server proxy, configurați VCS pentru a-l utiliza.
Acest lucru se poate face folosind variabilele de mediu http_proxy, https_proxy și all_proxy (așa cum este descris în documentația cURL) sau prin impunerea acesteia în configurația VCS, de exemplu:
git config --global http.proxy http://user:password@proxy.example.com:80
Notă
Configurarea proxy-ului trebuie să fie făcută sub utilizatorul care rulează Weblate (a se vedea și Permisiunile sistemului de fișiere) și cu HOME=$DATA_DIR/home (a se vedea DATA_DIR), altfel Git executat de Weblate nu îl va folosi.
Git¶
Sugestie
Weblate needs Git 2.28 or newer.
Vezi și
Consultați Accesarea depozitelor pentru informații despre cum să accesați diferite tipuri de depozite.
Git cu încărcare forțată¶
Acesta se comportă exact ca Git, singura diferență fiind că forțează întotdeauna împingerea. Acest lucru este destinat doar în cazul în care se utilizează un depozit separat pentru traduceri.
Atenționare
Folosiți-o cu prudență, deoarece acest lucru duce cu ușurință la pierderi de comenzi în depozitul din upstream.
Personalizarea configurației Git¶
Weblate invocă toate comenzile VCS cu HOME=$DATA_DIR/home (a se vedea DATA_DIR), prin urmare, editarea configurației utilizatorului trebuie să se facă în DATA_DIR/home/.git.
GitHub solicitări de tracțiune¶
Aceasta adaugă un strat subțire deasupra Git folosind GitHub API pentru a permite împingerea modificărilor de traducere ca cereri de tragere, în loc să împingă direct în depozit.
Git introduce modificările direct într-un depozit, în timp ce GitHub solicitări de tracțiune creează cereri de extragere. Acesta din urmă nu este necesar pentru simpla accesare a depozitelor Git.
Trebuie să configurați acreditările API (GITHUB_CREDENTIALS) în setările Weblate pentru ca acest lucru să funcționeze. Odată configurat, veți vedea o opțiune GitHub atunci când selectați Sistem de control al versiunilor.
Cereri de fuziune GitLab¶
Acest lucru adaugă doar un strat subțire peste Git folosind GitLab API pentru a permite împingerea modificărilor de traducere ca cereri de fuziune în loc de împingerea directă în depozit.
Nu este necesar să folosiți acest lucru pentru a accesa depozitele Git, Git obișnuit funcționează la fel, singura diferență este modul în care este gestionat împingerea către un depozit. Cu Git, modificările sunt împinse direct în depozit, în timp ce Cereri de fuziune GitLab creează cereri de fuziune.
Trebuie să configurați acreditările API (GITLAB_CREDENTIALS) în setările Weblate pentru ca acest lucru să funcționeze. Odată configurat, veți vedea o opțiune GitLab atunci când selectați Sistem de control al versiunilor.
Gitea cereri de pull¶
Added in version 4.12.
Acest lucru adaugă doar un strat subțire deasupra Git folosind Gitea API pentru a permite împingerea modificărilor de traducere ca cereri de tragere în loc de împingerea directă în depozit.
Nu este nevoie să folosiți acest lucru pentru a accesa depozitele Git, Git obișnuit funcționează la fel, singura diferență este modul în care este gestionat împingerea către un depozit. Cu Git, modificările sunt împinse direct în depozit, în timp ce Gitea cereri de pull creează cereri de pull.
Trebuie să configurați acreditările API (GITEA_CREDENTIALS) în setările Weblate pentru ca acest lucru să funcționeze. Odată configurat, veți vedea o opțiune Gitea atunci când selectați Sistem de control al versiunilor.
Bitbucket Data Center pull requests¶
Added in version 4.16.
This just adds a thin layer atop Git using the Bitbucket Data Center API to allow pushing translation changes as pull requests instead of pushing directly to the repository.
Atenționare
This does not support Bitbucket Cloud API.
There is no need to use this to access Git repositories, ordinary Git works the same, the only difference is how pushing to a repository is handled. With Git changes are pushed directly to the repository, while Bitbucket Data Center pull requests creates pull request.
You need to configure API credentials (BITBUCKETSERVER_CREDENTIALS) in the
Weblate settings to make this work. Once configured, you will see a
Bitbucket Data Center option when selecting Sistem de control al versiunilor.
Bitbucket Cloud pull requests¶
Added in version 5.8.
This just adds a thin layer atop Git using the Bitbucket Cloud API to allow pushing translation changes as pull requests instead of pushing directly to the repository.
Atenționare
This is different from Bitbucket Data Center API.
There is no need to use this to access Git repositories, ordinary Git works the same, the only difference is how pushing to a repository is handled. With Git changes are pushed directly to the repository, while Bitbucket Cloud pull requests creates pull request.
You need to configure API credentials (BITBUCKETCLOUD_CREDENTIALS) in the
Weblate settings to make this work. Once configured, you will see a
Bitbucket Cloud option when selecting Sistem de control al versiunilor.
Cereri de fuziune Pagure¶
Added in version 4.3.2.
Acest lucru adaugă doar un strat subțire peste Git folosind Pagure API pentru a permite împingerea modificărilor de traducere ca cereri de fuziune în loc să le împingă direct în depozit.
Nu este necesar să folosiți acest lucru pentru a accesa depozitele Git, Git obișnuit funcționează la fel, singura diferență este modul în care este gestionat împingerea către un depozit. Cu Git modificările sunt împinse direct în depozit, în timp ce Cereri de fuziune Pagure creează cereri de fuziune.
Trebuie să configurați acreditările API (PAGURE_CREDENTIALS) în setările Weblate pentru ca acest lucru să funcționeze. Odată configurat, veți vedea o opțiune Pagure atunci când selectați Sistem de control al versiunilor.
Gerrit¶
Adaugă un strat subțire deasupra Git folosind instrumentul git-review pentru a permite împingerea modificărilor de traducere ca cereri de revizuire Gerrit, în loc să le împingă direct în depozit.
Documentația Gerrit conține detalii cu privire la configurația necesară pentru a configura astfel de depozite.
Azure DevOps pull requests¶
This adds a thin layer atop Git using the Azure DevOps API to allow pushing translation changes as pull requests, instead of pushing directly to the repository.
Git pushes changes directly to a repository, while Azure DevOps pull requests creates pull requests. The latter is not needed for merely accessing Git repositories.
You need to configure API credentials (AZURE_DEVOPS_CREDENTIALS) in the
Weblate settings to make this work. Once configured, you will see a
Azure DevOps option when selecting Sistem de control al versiunilor.
Mercurial¶
Mercurial este un alt VCS pe care îl puteți utiliza direct în Weblate.
Notă
Ar trebui să funcționeze cu orice versiune Mercurial, dar uneori există modificări incompatibile la interfața de linie de comandă care întrerupe integrarea Weblate.
Vezi și
Consultați Accesarea depozitelor pentru informații despre cum să accesați diferite tipuri de depozite.
Subversiune¶
Weblate folosește git-svn pentru a interacționa cu depozitele subversion. Este un script Perl care permite utilizarea subversiunii de către un client Git, permițând utilizatorilor să mențină o clonă completă a depozitului intern și să facă confirmări la nivel local.
Notă
Weblate încearcă să detecteze automat aspectul depozitului Subversion - acceptă atât URL-uri directe pentru branșă, cât și depozite cu aspect standard (branches/, tags/ și trunk/). Mai multe informații despre acest lucru pot fi găsite în documentația git-svn. Dacă depozitul vostru nu are o dispunere standard și întâmpinați erori, încercați să includeți numele branșei în URL-ul depozitului și să lăsați ramificația goală.
Acreditive pentru Subversion¶
Weblate se așteaptă să acceptați certificatul în avans (și acreditările dumneavoastră, dacă este necesar). Acesta va căuta să le insereze în directorul DATA_DIR. Acceptați certificatul folosind svn o dată cu variabila de mediu $HOME setată la 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
Vezi și
Fișiere locale¶
Sugestie
În partea de jos, acesta folosește Git. Necesită Git instalat și vă permite să treceți la utilizarea nativă a Git cu un istoric complet al traducerilor.
Weblate poate funcționa și fără un VCS la distanță. Traducerile inițiale sunt importate prin încărcarea lor. Ulterior, puteți înlocui fișiere individuale prin încărcarea fișierelor sau puteți adăuga șiruri de traduceri direct din Weblate (în prezent, disponibil numai pentru traduceri monolingve).
În fundal, Weblate creează un depozit Git pentru tine, iar toate modificările sunt urmărite în acesta. În cazul în care decideți ulterior să utilizați un VCS pentru a stoca traducerile, aveți deja un depozit în Weblate pe care vă puteți baza integrarea.