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 Server 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¶
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, …)¶
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 (this of frequently enforced by the platform) and grant this user access to the repository. You can then use SSH URL to access the repository (see Depozite SSH).
Sugestie
On a Hosted Weblate, this is pre-cofigured for most of the public sites, please see Accesarea depozitelor din Weblate găzduit.
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¶
Accesul prin SSH este posibil (a se vedea Depozite SSH), dar în cazul în care aveți nevoie să accesați mai mult de un depozit, vă veți lovi de o limitare GitHub privind utilizarea permisă a cheilor SSH (deoarece fiecare cheie poate fi utilizată o singură dată).
Î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ă.
Pentru implementări mai mici, utilizați autentificarea HTTPS cu un token de acces personal și contul dumneavoastră GitHub, consultați Crearea unui token de acces pentru utilizarea în linia de comandă.
Pentru configurații mai mari, este de obicei mai bine să creați un utilizator dedicat pentru Weblate, să-i atribuiți cheia SSH publică generată în Weblate (vezi Cheie SSH Weblate) și să-i acordați acces la toate depozitele pe care doriți să le traduceți. Această abordare este utilizată și pentru Weblate găzduit, pentru care există un utilizator dedicat weblate.
URL-uri interne Weblate¶
Împărtășiți o configurație de depozit între diferite componente, făcând referire la plasarea sa ca weblate://proiect/component în alte componente (legate). În acest fel, componentele legate utilizează configurația de depozit VCS a componentei principale (la care se face referire).
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.
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 are nevoie de Git 2.12 sau mai nou.
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.
Ajutoare la distanță Git¶
De asemenea, puteți folosi Git remote helpers pentru a sprijini suplimentar alte sisteme de control al versiunilor, dar fiți pregătiți să depanați problemele pe care le-ar putea cauza.
În acest moment, ajutoarele pentru Bazaar și Mercurial sunt disponibile în depozite separate pe GitHub: git-remote-hg și git-remote-bzr. Descărcați-le manual și puneți-le undeva în calea dvs. de căutare (de exemplu ~/bin). Asigurați-vă că aveți instalate sistemele de control al versiunilor corespunzătoare.
Odată instalate acestea, aceste telecomenzi pot fi utilizate pentru a specifica un depozit în Weblate.
Pentru a clona proiectul gnuhello din Launchpad folosind Bazaar:
bzr::lp:gnuhello
Pentru depozitul hello de pe selenic.com folosind Mercurial:
hg::http://selenic.com/repo/hello
Atenționare
Inconvenientul utilizării ajutoarelor de la distanță Git este că, de exemplu, cu Mercurial, asistentul de la distanță creează uneori un nou tip atunci când împinge modificările înapoi.
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 Server pull requests¶
Added in version 4.16.
This just adds a thin layer atop Git using the Bitbucket Server 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 Server 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 Server 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.