Integrarea controlului versiunilor

Weblate suportă în prezent Git (cu suport extins pentru GitHub pull requests, Gerrit și Subversiune) și Mercurial ca back-end-uri de control al versiunilor.

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

Pentru Hosted Weblate există un utilizator push dedicat înregistrat pe GitHub, Bitbucket, Codeberg și GitLab (cu numele de utilizator weblate, e-mail hosted@weblate.org și, numit Weblate push user). Trebuie să adăugați acest utilizator ca și colaborator și să-i acordați permisiunea corespunzătoare pentru depozitul dumneavoastră (read-only este în regulă pentru clonare, write este necesar pentru push). În funcție de setările serviciului și ale organizației dumneavoastră, acest lucru se întâmplă imediat sau necesită confirmare din partea Weblate.

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.

Odată ce utilizatorul weblate este adăugat, puteți configura Depozitul de cod sursă și URL de împingere a depozitului folosind protocolul SSH (de exemplu git@github.com:WeblateOrg/weblate.git).

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:

_images/ssh-keys.png

Cheie SSH Weblate

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ă

Cheia SSH privată corespunzătoare nu poate avea în prezent o parolă, așa că asigurați-vă că aceasta este bine protejată.

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:

_images/ssh-keys-added.png

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 Împingeți ramura 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 Comenzi Git Squash.

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 forța push

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 pull requests

Nou în versiunea 2.3.

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 pull requests 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.

GitLab merge requests

Nou în versiunea 3.9.

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 GitLab merge requests 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.

Pagure merge requests

Nou în versiunea 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 Pagure merge requests 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

Nou în versiunea 2.2.

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.

Mercurial

Nou în versiunea 2.1.

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

Nou în versiunea 2.8.

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ă.

Schimbat în versiunea 2.19: Înainte de aceasta, erau acceptate doar depozitele care foloseau aspectul standard.

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

DATA_DIR

Fișiere locale

Git

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.

Nou în versiunea 3.8.

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.