Traducere continuă

Există o infrastructură care permite ca traducerea dumneavoastră să urmeze îndeaproape dezvoltarea. În acest fel, traducătorii pot lucra la traduceri pe tot parcursul timpului, în loc să lucreze la o cantitate uriașă de text nou chiar înainte de lansare.

Vezi și

Integrarea cu Weblate descrie modalitățile de bază pentru a vă integra dezvoltarea cu Weblate.

Acesta este procesul:

  1. Dezvoltatorii fac modificări și le transferă în depozitul VCS.

  2. Opțional, fișierele de traducere sunt actualizate (acest lucru depinde de formatul fișierului, a se vedea De ce Weblate încă arată șiruri de traducere vechi atunci când am actualizat șablonul?).

  3. Weblate extrage modificările din depozitul VCS, vezi Actualizarea depozitelor.

  4. Odată ce Weblate detectează modificări în traduceri, traducătorii sunt notificați în funcție de setările de abonament.

  5. Traducătorii trimit traducerile folosind interfața web Weblate sau încarcă modificările offline.

  6. Odată ce traducătorii au terminat, Weblate comite modificările în depozitul local (a se vedea Angajări leneșe) și le împinge înapoi dacă are permisiuni pentru a face acest lucru (a se vedea Împingerea modificărilor din Weblate).

digraph translations { graph [fontname = "sans-serif", fontsize=10]; node [fontname = "sans-serif", fontsize=10, margin=0.1, height=0]; edge [fontname = "sans-serif", fontsize=10]; "Developers" [shape=box, fillcolor="#144d3f", fontcolor=white, style=filled]; "Translators" [shape=box, fillcolor="#144d3f", fontcolor=white, style=filled]; "Developers" -> "VCS repository" [label=" 1. Push "]; "VCS repository" -> "VCS repository" [label=" 2. Updating translations ", style=dotted]; "VCS repository" -> "Weblate" [label=" 3. Pull "]; "Weblate" -> "Translators" [label=" 4. Notification "]; "Translators" -> "Weblate" [label=" 5. Translate "]; "Weblate" -> "VCS repository" [label=" 6. Push "]; }

Actualizarea depozitelor

Ar trebui să configurați o modalitate de actualizare a depozitelor backend de la sursa acestora.

Ori de câte ori Weblate actualizează depozitul, vor fi declanșate addon-urile post-update, vezi Extensii.

Evitarea conflictelor de fuziune

Conflictele de fuziune din Weblate apar atunci când același fișier a fost modificat atât în Weblate, cât și în afara acestuia. Există două abordări pentru a rezolva această problemă - evitați modificările în afara Weblate sau integrați Weblate în procesul de actualizare, astfel încât să se elimine modificările înainte de actualizarea fișierelor din afara Weblate.

Prima abordare este ușoară în cazul fișierelor monolingve - puteți adăuga noi șiruri de caractere în Weblate și puteți lăsa acolo întreaga editare a fișierelor. În cazul fișierelor bilingve, există de obicei un fel de proces de extragere a mesajelor pentru a genera fișiere traductibile din codul sursă. În unele cazuri, acesta poate fi împărțit în două părți - una pentru extracție generează șablonul (de exemplu, gettext POT este generat folosind xgettext) și apoi un proces ulterior îl îmbină în traduceri reale (fișierele gettext PO sunt actualizate folosind msgmerge). Puteți efectua al doilea pas în cadrul Weblate și acesta se va asigura că toate modificările în așteptare sunt incluse înainte de această operațiune.

A doua abordare poate fi realizată prin utilizarea Weblate’s REST API pentru a forța Weblate să împingă toate modificările în așteptare și să blocheze traducerea în timp ce efectuați modificări pe partea dumneavoastră.

Scriptul pentru efectuarea actualizărilor poate arăta astfel:

# Lock Weblate translation
wlc lock
# Push changes from Weblate to upstream repository
wlc push
# Pull changes from upstream repository to your local copy
git pull
# Update translation files, this example is for Django
./manage.py makemessages --keep-pot -a
git commit -m 'Locale updates' -- locale
# Push changes to upstream repository
git push
# Tell Weblate to pull changes (not needed if Weblate follows your repo
# automatically)
wlc pull
# Unlock translations
wlc unlock

Dacă aveți mai multe componente care împart același depozit, trebuie să le blocați pe toate separat:

wlc lock foo/bar
wlc lock foo/baz
wlc lock foo/baj

Notă

Exemplul utilizează Client Weblate, care are nevoie de configurare (chei API) pentru a putea controla Weblate de la distanță. De asemenea, puteți realiza acest lucru folosind orice client HTTP în loc de wlc, de exemplu curl, vezi Weblate’s REST API.

Vezi și

Client Weblate

Primirea automată a modificărilor de pe GitHub

Weblate vine cu suport nativ pentru GitHub.

Dacă utilizați Weblate găzduit, abordarea recomandată este să instalați Weblate app, astfel veți obține configurația corectă fără a fi nevoie să configurați prea multe. De asemenea, poate fi folosită pentru a împinge modificările înapoi.

Pentru a primi notificări la fiecare push către un depozit GitHub, adăugați Webhook-ul Weblate în setările depozitului (Webhooks), așa cum se arată în imaginea de mai jos:

../_images/github-settings.png

Pentru URL-ul de sarcină utilă, adăugați /hooks/github/ la URL-ul Weblate, de exemplu, pentru serviciul Weblate găzduit, acesta este https://hosted.weblate.org/hooks/github/.

Puteți lăsa celelalte valori la setările implicite (Weblate poate gestiona ambele tipuri de conținut și consumă doar evenimentul push).

Primirea automată a modificărilor de la Bitbucket

Weblate are suport pentru Bitbucket webhooks, adăugați un webhook care se declanșează la împingerea depozitului, cu destinația către /hooks/bitbucket/ URL-ul de pe instalarea Weblate (de exemplu https://hosted.weblate.org/hooks/bitbucket/).

../_images/bitbucket-settings.png

Primirea automată a modificărilor de la GitLab

Weblate are suport pentru cârligele GitLab, adăugați un webhook de proiect cu destinația /hooks/gitlab/` URL pe instalarea Weblate (de exemplu https://hosted.weblate.org/hooks/gitlab/).

Primirea automată a modificărilor de la Pagure

Nou în versiunea 3.3.

Weblate are suport pentru cârligele Pagure, adăugați un webhook cu destinația /hooks/pagure/` URL pe instalarea Weblate (de exemplu https://hosted.weblate.org/hooks/pagure/). Acest lucru poate fi făcut în Activate Web-hooks sub Project options:

../_images/pagure-webhook.png

Primirea automată a modificărilor din Azure Repos

Nou în versiunea 3.8.

Weblate are suport pentru cârligele web Azure Repos, adăugați un webhook pentru evenimentul Code pushed cu destinația la /hooks/azure/` URL pe instalarea Weblate (de exemplu https://hosted.weblate.org/hooks/azure/). Acest lucru se poate face în Service hooks din Project settings.

Primirea automată a modificărilor din Gitea Repos

Nou în versiunea 3.9.

Weblate are suport pentru Gitea webhooks, adăugați un eveniment Gitea Webhook pentru evenimentul Push events cu destinația la /hooks/gitea/` URL-ul din instalarea Weblate (de exemplu https://hosted.weblate.org/hooks/gitea/). Acest lucru se poate face în Webhooks din depozitul Settings.

Primirea automată a modificărilor din Gitee Repos

Nou în versiunea 3.9.

Weblate are suport pentru Gitee webhooks, adăugați un WebHook pentru evenimentul Push cu destinația la /hooks/gitee/` URL-ul de pe instalarea Weblate (de exemplu https://hosted.weblate.org/hooks/gitee/). Acest lucru se poate face în WebHooks din cadrul depozitului Management.

Actualizarea automată a depozitelor în fiecare noapte

Weblate preia în mod automat depozitele la distanță în fiecare noapte pentru a îmbunătăți performanța la fuzionarea ulterioară a modificărilor. Opțional, puteți transforma acest lucru și în fuziuni nocturne, activând AUTO_UPDATE.

Împingerea modificărilor din Weblate

Fiecare componentă de traducere poate avea o adresă URL de împingere configurată (vezi URL de împingere a depozitului) și, în acest caz, Weblate va fi capabil să împingă modificările în depozitul de la distanță. Weblate poate fi, de asemenea, configurat să împingă automat modificările la fiecare confirmare (acest lucru este implicit, a se vedea Împingeți pe comitere). Dacă nu doriți ca modificările să fie împinse automat, puteți face acest lucru manual sub Repository maintenance sau folosind API prin wlc push.

Opțiunile push diferă în funcție de Integrarea controlului versiunilor utilizat, mai multe detalii se găsesc în acest capitol.

În cazul în care nu doriți împingeri directe de către Weblate, există suport pentru GitHub, GitLab, Pagure pull requests sau :ref: vcs-gerrit reviews, le puteți activa alegând GitHub, GitLab, Gerrit sau Pagure ca Sistem de control al versiunilor în Configurația componentei.

În general, următoarele opțiuni sunt disponibile cu Git, GitHub și GitLab:

Configurația dorită

Sistem de control al versiunilor

URL de împingere a depozitului

Împingeți ramura

Nu împinge

Git

vid

vid

Împingeți direct

Git

SSH URL

vid

Împingeți în ramura separată

Git

SSH URL

Denumirea branșei

GitHub trage cerere de la bifurcație

GitHub

vid

vid

GitHub trage cerere de la branșă

GitHub

URL SSH 1

Denumirea branșei

Cerere de fuziune GitLab din bifurcație

GitLab

vid

vid

Cerere de fuziune GitLab din branșă

GitLab

URL SSH 1

Denumirea branșei

Cerere de fuziune Pagure din bifurcație

Pagure

vid

vid

Pagure cerere de îmbinare din ramura

Pagure

URL SSH 1

Denumirea branșei

1(1,2,3)

Poate fi gol în cazul în care Depozitul de cod sursă suportă împingerea.

Notă

Puteți, de asemenea, să activați împingerea automată a modificărilor după ce Weblate le validează, acest lucru poate fi făcut în Împingeți pe comitere.

Vezi și

Consultați Accesarea depozitelor pentru configurarea cheilor SSH și Angajări leneșe pentru informații despre momentul în care Weblate decide să valideze modificările.

Branșe protejate

Dacă folosiți Weblate pe ramura protejată, îl puteți configura pentru a utiliza cereri de tragere și pentru a efectua o revizuire reală a traducerilor (ceea ce ar putea fi problematic pentru limbile pe care nu le cunoașteți). O abordare alternativă este de a renunța la această limitare pentru utilizatorul Weblate push.

De exemplu, pe GitHub, acest lucru se poate face în configurația depozitului:

../_images/github-protected.png

Fuziune sau re-bază

În mod implicit, Weblate fuzionează depozitul din amonte în propriul depozit. Acesta este cel mai sigur mod în cazul în care accesați și depozitul de bază prin alte mijloace. În cazul în care nu aveți nevoie de acest lucru, puteți activa rebasarea modificărilor în upstream, ceea ce va produce un istoric cu mai puține comenzi de fuziune.

Notă

Operațiunea Rebasing vă poate cauza probleme în cazul fuziunilor complicate, așa că analizați cu atenție dacă doriți sau nu să o activați.

Interacțiunea cu ceilalți

Weblate facilitează interacțiunea cu ceilalți folosind API-ul său.

Angajări leneșe

Comportamentul Weblate este de a grupa, dacă este posibil, comenzi de la același autor într-o singură comandă. Acest lucru reduce foarte mult numărul de comenzi, însă este posibil să fie necesar să-i spuneți în mod explicit să facă comenzi în cazul în care doriți să sincronizați depozitul VCS, de exemplu pentru fuziune (acest lucru este permis în mod implicit pentru grupul Managers, a se vedea Listă de privilegii).

Modificările din acest mod sunt confirmate atunci când este îndeplinită oricare dintre următoarele condiții:

Sugestie

Se creează angajamente pentru fiecare componentă. Astfel, în cazul în care aveți multe componente, veți vedea în continuare o mulțime de comisioane. În acest caz, ați putea utiliza addon-ul Comenzi Git Squash.

Dacă doriți să confirmați modificările mai frecvent și fără a verifica vechimea, puteți programa o sarcină regulată pentru a efectua o confirmare:

CELERY_BEAT_SCHEDULE = {
    # Unconditionally commit all changes every 2 minutes
    "commit": {
        "task": "weblate.trans.tasks.commit_pending",
        # Ommiting hours will honor per component settings,
        # otherwise components with no changes older than this
        # won't be committed
        "kwargs": {"hours": 0},
        # How frequently to execute the job in seconds
        "schedule": 120,
    }
}

Procesarea depozitului cu scripturi

Modalitatea de a personaliza modul în care Weblate interacționează cu depozitul este Extensii. Consultați Executarea scripturilor din add-on pentru informații despre cum să executați scripturi externe prin intermediul addon-urilor.

Păstrarea traducerilor la fel în toate componentele

Odată ce aveți mai multe componente de traducere, ați putea dori să vă asigurați că aceleași șiruri de caractere au aceeași traducere. Acest lucru poate fi realizat la mai multe niveluri.

Propagarea traducerii

Cu Permiteți propagarea traducerii activat (ceea ce este implicit, vezi Configurația componentei), toate traducerile noi sunt efectuate automat în toate componentele cu șiruri de caractere corespunzătoare. Astfel de traduceri sunt creditate în mod corespunzător utilizatorului care traduce în mod curent în toate componentele.

Notă

Propagarea traducerii necesită ca cheia să se potrivească pentru formatele de traducere monolingve, așa că țineți cont de acest lucru atunci când creați chei de traducere.

Verificarea consistenței

Verificarea Inconsecvent se declanșează ori de câte ori șirurile sunt diferite. Puteți utiliza acest lucru pentru a examina manual astfel de diferențe și pentru a alege traducerea corectă.

Traducere automată

Traducerea automată bazată pe diferite componente poate fi o modalitate de a sincroniza traducerile între componente. Puteți fie să o declanșați manual (a se vedea Traducere automată), fie să o faceți să se execute automat la actualizarea depozitului folosind addon (a se vedea Traducere automată).