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:
Dezvoltatorii fac modificări și le transferă în depozitul VCS.
Optionally the translation files are updated, see Introducing new strings.
Weblate pulls changes from the VCS repository, parses translation files and updates its database, see Actualizarea depozitelor.
Traducătorii trimit traducerile folosind interfața web Weblate sau încarcă modificările offline.
Once the translators are finished, Weblate commits the changes to the local repository (see Angajări leneșe).
Changes are pushed back to the upstream repository (see Împingerea modificărilor din Weblate).
Sugestie
Upstream code hosting is not necessary, you can use Weblate with Fișiere locale where there is only the repository inside Weblate.
Actualizarea depozitelor¶
Ar trebui să configurați o modalitate de actualizare a depozitelor backend de la sursa acestora.
Utilizați Cârlige notificare pentru a vă integra cu majoritatea serviciilor comune de găzduire a codurilor:
Declanșarea manuală a actualizării fie în gestionarea depozitului, fie folosind Weblate’s REST API sau Client Weblate
Activați
AUTO_UPDATE
pentru a actualiza automat toate componentele de pe instanța WeblateExecute
updategit
(with selection of project or--all
to update all)
Ori de câte ori Weblate actualizează depozitul, vor fi declanșate addon-urile post-update, vezi Suplimente.
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.
The first approach is easy with monolingual files — you can add new strings within Weblate and leave whole editing of the files there. For bilingual files, there is usually some kind of message extraction process to generate translatable files from the source code. In some cases this can be split into two parts - one for the extraction generates template (for example gettext POT is generated using xgettext) and then further process merges it into actual translations (the gettext PO files are updated using msgmerge). You can perform the second step within Weblate and it will ensure that all pending changes are included prior to this operation.
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.
Avoiding merge conflicts on Weblate originated changes¶
Even when Weblate is the single source of the changes in the translation files, conflicts can appear when using Comasează comiteri Git add-on, Stil îmbinare is configured to Rebase, or you are squashing commits outside of Weblate (for example when merging a pull request).
The reason for merge conflicts is different in this case - there are changes in Weblate which happened after you merged Weblate commits. This typically happens if merging is not automated and waits for days or weeks for a human to review them. Git is then sometimes no longer able to identify upstream changes as matching the Weblate ones and refuses to perform a rebase.
To approach this, you either need to minimize amount of pending changes in Weblate when you merge a pull request, or avoid the conflicts completely by not squashing changes.
Here are few options how to avoid that:
Do not use neither Comasează comiteri Git nor squashing at merge time. This is the root cause why git doesn’t recognize changes after merging.
Let Weblate commit pending changes before merging. This will update the pull request with all its changes and both repositories will be in sync.
Use the review features in Weblate (see Fluxuri de lucru de traducere), so that you can automatically merge GitHub pull requests after CI passes.
Use locking in Weblate to avoid changes while GitHub pull request is in review.
Vezi și
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:
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/
).
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¶
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:
Primirea automată a modificărilor din Azure Repos¶
Weblate has support for Azure Repos webhooks, add a webhook for
Code pushed event with destination to /hooks/azure/
URL on your
Weblate installation (for example https://hosted.weblate.org/hooks/azure/
).
This can be done in Service hooks under Project
settings.
Primirea automată a modificărilor din Gitea Repos¶
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¶
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 încărcare depozitar) ș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 Încarcă la 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 Integrare control versiune utilizat, mai multe detalii se găsesc în acest capitol.
In case you do not want direct pushes by Weblate, there is support for GitHub solicitări de tracțiune, Cereri de fuziune GitLab, Gitea cereri de pull, Cereri de fuziune Pagure, Azure DevOps pull requests pull requests or Gerrit reviews, you can activate these by choosing GitHub, GitLab, Gitea, Gerrit, Azure DevOps, or Pagure as Sistem de control al versiunilor in Configurația componentei.
Overall, following options are available with Git, Mercurial, GitHub, GitLab, Gitea, Pagure, and Azure DevOps:
Configurația dorită |
|||
---|---|---|---|
Nu împinge |
vid |
vid |
|
Împingeți direct |
SSH URL |
vid |
|
Împingeți în ramura separată |
SSH URL |
Denumirea branșei |
|
Nu împinge |
vid |
vid |
|
Împingeți direct |
SSH URL |
vid |
|
Împingeți în ramura separată |
SSH URL |
Denumirea branșei |
|
GitHub trage cerere de la bifurcație |
vid |
vid |
|
GitHub trage cerere de la branșă |
URL SSH [1] |
Denumirea branșei |
|
Cerere de fuziune GitLab din bifurcație |
vid |
vid |
|
Cerere de fuziune GitLab din branșă |
URL SSH [1] |
Denumirea branșei |
|
Gitea cerere de fuziune din fork |
vid |
vid |
|
Cerere de fuziune Gitea din branșă |
URL SSH [1] |
Denumirea branșei |
|
Cerere de fuziune Pagure din bifurcație |
vid |
vid |
|
Pagure cerere de îmbinare din ramura |
URL SSH [1] |
Denumirea branșei |
|
Azure DevOps pull request from fork |
vid |
vid |
|
Azure DevOps pull request from branch |
URL SSH [1] |
Denumirea branșei |
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 Încarcă la 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:
Interacțiunea cu ceilalți¶
Weblate facilitează interacțiunea cu ceilalți folosind API-ul său.
Vezi și
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 of privileges).
Modificările din acest mod sunt confirmate atunci când este îndeplinită oricare dintre următoarele condiții:
Altcineva modifică un șir deja modificat.
Are loc o fuziune din amonte.
Se solicită o confirmare explicită.
Se solicită descărcarea unui fișier.
Modificarea este mai veche decât perioada definită ca Vârsta modificărilor care urmează să fie comise pe Configurația componentei.
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 add-on-ul Comasează comiteri Git.
If you want to commit changes more frequently and without checking of age, you
can schedule a regular task to perform a commit. This can be done using
Periodic Tasks in Interfața de administrare Django. First create desired
Interval (for example 120 seconds). Then add new periodic task and
choose weblate.trans.tasks.commit_pending
as Task with
{"hours": 0}
as Keyword Arguments and desired interval.
Procesarea depozitului cu scripturi¶
Modalitatea de a personaliza modul în care Weblate interacționează cu depozitul este Suplimente. Consultați Executarea scripturilor din add-on pentru informații despre cum să executați scripturi externe prin intermediul add-ons.
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 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 un add-on (a se vedea Traducere automată).