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 review requests, Subversiune, Bitbucket Cloud pull requests, Bitbucket Data Center pull requests, and Azure DevOps pull requests) 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.
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.
On GitHub, you need to add or invite the Hosted Weblate weblate user with write access even when you use the Hosted Weblate GitHub app. The app handles incoming notifications from GitHub, but pushing changes back still uses the Hosted Weblate weblate user.
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 an 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
On GitHub, each key can only be used once, see GitHub repository access and 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¶
Detailed GitHub repository access is covered in GitHub repository access.
GitLab repositories¶
Detailed GitLab repository access is covered in GitLab repository access.
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¶
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¶
Detailed GitHub pull request setup is covered in GitHub solicitări de tracțiune.
Cereri de fuziune GitLab¶
Detailed GitLab merge request setup is covered in Cereri de fuziune GitLab.
Gitea cereri de pull¶
Detailed Gitea pull request setup is covered in Gitea cereri de pull.
Bitbucket Data Center pull requests¶
Detailed Bitbucket Data Center pull request setup is covered in Bitbucket Data Center pull requests.
Bitbucket Cloud pull requests¶
Detailed Bitbucket Cloud pull request setup is covered in Bitbucket Cloud pull requests.
Cereri de fuziune Pagure¶
Detailed Pagure merge request setup is covered in Cereri de fuziune Pagure.
Gerrit¶
Detailed Gerrit review request setup is covered in Gerrit review requests.
Azure DevOps pull requests¶
Detailed Azure DevOps pull request setup is covered in Azure DevOps pull requests.
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.