Doorlopende vertaling¶
Er is een dusdanige infrastructuur dat uw vertaling de ontwikkelingen op de voet volgt. Op deze manier kunnen vertalers normaal doorwerken aan de vertalingen, in plaats van eerst een grote hoeveelheid nieuwe tekst te moeten verwerken, net voorafgaande aan een nieuwe uitgave.
Zie ook
Integreren met Weblate beschrijft de basismanieren om uw ontwikkeling met Weblate te integreren.
Dit is het proces:
Ontwikkelaars maken wijzigingen en pushen die naar de opslagruimte van het VCS.
Optioneel worden de vertaalde bestanden bijgewerkt, bekijk Nieuwe tekenreeksen introduceren.
Weblate haalt wijzigingen op uit de opslagruimte van het VCS, parset vertaalbestanden en werkt zijn database bij, bekijk Bijwerken van opslagruimten.
Vertalers dienen vertalingen in met de webinterface van Weblate, of uploaden wijzigingen die offline gemaakt zijn.
Als de vertalers gereed zijn, voert Weblate de wijzigingen door in de lokale opslagruimte (bekijk Vetraagd indienen).
Wijzigingen worden doorgezet naar de opslagruimte upstream (bekijk Wijzigingen vanuit Weblate pushen).
Hint
Upstream hosten van de code is niet noodzakelijk, u kunt Weblate gebruiken met Lokale bestanden waarbij de enige opslagruimte binnen Weblate ligt.
Bijwerken van opslagruimten¶
U zou enige wijze van bijwerken van opslagruimten van de backends vanuit hun bron moeten instellen.
Gebruik Notificatie-hooks om te integreren met de meest gebruikte services voor het hosten van code:
U moet ook Hooks inschakelen instellen om dit te laten werken.
Activeer het bijwerken handmatig, ofwel in het beheer van de opslagruimte of met Weblate REST API of Weblate Client
Schakel
AUTO_UPDATE
in om automatisch alle onderdelen van uw instantie van Weblate bij te werkenVoer
updategit
uit (met selectie van het project of met--all
om alles bij te werken)
Iedere keer wanneer Weblate de opslagruimte bijwerkt, worden de add-ons voor na het bijwerken geactiveerd, bekijk Add-ons.
Conflicten met samenvoegen vermijden¶
De conflicten met samenvoegen in Weblate treden op als hetzelfde bestand werd gewijzigd, zowel in Weblate als daarbuiten. Afhankelijk van de situatie, zijn er verschillende benaderingen die hier zouden kunnen helpen:
Conflicten met samenvoegen vermijden door vertaalbestanden alleen in Weblate te wijzigen
Conflicten met samenvoegen vermijden door te focussen op bewerkingen met Git
Conflicten met samenvoegen vermijden door vertaalbestanden alleen in Weblate te wijzigen¶
Vermijden van bewerkingen buiten Weblate is gemakkelijk met eentalige bestanden — u kunt nieuwe tekenreeksen in Weblate toevoegen en het hele bewerken van de bestanden daar laten. Voor tweetalige bestanden is gewoonlijk een bepaald proces voor het uitnemen van eenheden nodig om vertaalbare bestanden te kunnen genereren vanuit de broncode. In sommige gevallen kan dit worden opgedeeld in twee delen:
Het uitnemen genereert sjabloon (bijvoorbeeld gettext POT wordt gegenereerd met xgettext).
Verdere processen voegen het samen tot de feitelijke vertalingen (de gettext PO-bestanden worden bijgewerkt met msgmerge).
U kunt de tweede stap uitvoeren binnen Weblate en het zal ervoor zorgen dat alle openstaande wijzigingen worden opgenomen, voor deze bewerking.
Conflicten met samenvoegen vermijden door Weblate te vergrendelen bij het daarbuiten maken van wijzigingen¶
Integreren van Weblate in uw proces voor bijwerken, zodat het wijzigingen verwijderd, voordat de bestanden buiten Weblate worden bijgewerkt, kan worden bereikt door Weblate REST API te gebruiken om Weblate te forceren om alle openstaande wijzigingen te pushen en de vertaling te vergrendelen, terwijl u wijzigingen uitvoert aan uw kant.
Het script voor het uitvoeren van bijwerkingen kan er uitzien zoals dit:
# 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
Als u meerdere onderdelen hebt die dezelfde opslagruimte delen, moet u ze allemaal afzonderlijk vergrendelen:
wlc lock foo/bar
wlc lock foo/baz
wlc lock foo/baj
Notitie
De voorbeelden gebruiken Weblate Client, wat configuratie nodig heeft (API-sleutels) om in staat te zijn om Weblate op afstand te beheren. U kunt dit ook bereiken met elke HTTP-cliënt in plaats van met Weblate Client, bijvoorbeeld curl, bekijk Weblate REST API.
Conflicten met samenvoegen vermijden door te focussen op bewerkingen met Git¶
Zelfs wanneer Weblate de enige bron is van de wijzigingen in de vertaalbestanden, kunnen conflicten optreden bij het gebruiken van de add-on Git-commits samenvoegen, Manier voor samenvoegen is geconfigureerd voor Rebase, of wanneer u commits bij elkaar voegt buiten Weblate (bijvoorbeeld bij het samenvoegen van een pull request).
De reden voor conflicten met samenvoegen is in dit geval anders - er zijn wijzigingen in Weblate die gebeurden nadat u commits van Weblate hebt samengevoegd. Dit gebeurt gewoonlijk als het samenvoegen niet is geautomatiseerd en een paar dagen of weken wacht totdat iemand ze heeft nagekeken. Git is dan soms niet langer in staat om wijzigingen upstream te identificeren als overeenkomend met die van Weblate en weigert een rebase uit te voeren.
U moet, om dit te verhelpen, de hoeveelheid openstaande wijzigingen in Weblate minimaliseren als u een pull request samenvoegt, of de conflicten volledig vermijden door wijzigingen niet bij elkaar te voegen (squashen).
Hier zijn enkele opties om dat te vermijden:
Gebruik Git-commits samenvoegen, noch squashen bij het samenvoegen. Dat is de bron van de oorzaak waarom Git de wijzigingen na het samenvoegen niet meer herkent.
Laat Weblate openstaande wijzigingen indienen voor het samenvoegen. Dat zal het pull request bijwerken met al zijn wijzigingen en beide opslagruimten zullen gesynchroniseerd zijn.
Gebruik de mogelijkheden voor nakijken in Weblate (bekijk Werkwijzen voor vertalen), zodat u automatisch GitHub pull requesten kunt samenvoegen nadat CI slaagt.
Gebruik vergrendelen in Weblate om wijzigingen te vermijden, terwijl het GitHub pull request wordt nagekeken.
Zie ook
Automatisch wijzigingen van GitHub ontvangen¶
Weblate heeft eigen ondersteuning voor GitHub.
Als u Hosted Weblate gebruikt is de aanbevolen benadering om de Weblate app te installeren, op die manier zult u de juiste instellingen verkrijgen zonder te veel te hoeven in te stellen. Het kan ook worden gebruikt voor het terugpushen van wijzigingen.
Voeg, voor het ontvangen van notificaties voor elke push naar een opslagruimte van GitHub, de Weblate Webhook toe in de instellingen voor de opslagruimte (Webhooks) zoals weergegeven in de afbeelding hieronder:

De Payload URL bestaat uit uw URL voor Weblate, gevolgd door /hooks/github/
, voor de service Hosted Weblate is dit bijvoorbeeld https://hosted.weblate.org/hooks/github/
.
U kunt de andere waarden laten staan op de standaard instellingen (Weblate kan beide typen inhoud afhandelen en gebruikt alleen de gebeurtenis push).
Automatisch wijzigingen van Bitbucket ontvangen¶
Weblate heeft ondersteuning voor webhooks van Bitbucket, voeg een webhook toe die wordt geactiveerd bij pushen vanuit de opslagruimte, met als doel de URL /hooks/bitbucket/
op uw installatie van Weblate (bijvoorbeeld https://hosted.weblate.org/hooks/bitbucket/
).

Automatisch wijzigingen van GitLab ontvangen¶
Weblate heeft ondersteuning voor hooks van GitLab, voeg een webhook voor het project toe met als doel de URL /hooks/gitlab/
op uw installatie van Weblate (bijvoorbeeld https://hosted.weblate.org/hooks/gitlab/
).
Automatisch wijzigingen van Pagure ontvangen¶
Weblate heeft ondersteuning voor hooks van Pagure, voeg een webhook toe met als doel de URL /hooks/pagure/
op uw installatie van Weblate (bijvoorbeeld https://hosted.weblate.org/hooks/pagure/
). Dit kan worden gedaan in Activate Web-hooks onder Project options:

Automatisch wijzigingen van Azure Repos ontvangen¶
Weblate heeft ondersteuning voor webhooks van Azure Repos, voeg een webhook toe voor de gebeurtenis Code pushed met als doel de URL /hooks/azure/
op uw installatie van Weblate (bijvoorbeeld https://hosted.weblate.org/hooks/azure/
). Dit kan worden gedaan in Service hooks onder Project settings.
Automatisch wijzigingen van Gitea Repos ontvangen¶
Weblate heeft ondersteuning voor webhooks van Gitea, voeg een Gitea Webhook toe voor de gebeurtenis Push events met als doel de URL /hooks/gitea/
op uw installatie van Weblate (bijvoorbeeld https://hosted.weblate.org/hooks/gitea/
). Dit kan worden gedaan in Webhooks onder Settings voor de opslagruimte.
Automatisch wijzigingen van Gitee Repos ontvangen¶
Weblate heeft ondersteuning voor webhooks van Gitee, voeg een WebHook toe voor de gebeurtenis Push met als doel de URL /hooks/gitee/
op uw installatie van Weblate (bijvoorbeeld https://hosted.weblate.org/hooks/gitee/
). Dit kan worden gedaan in WebHooks onder Management van de opslagruimte.
Automatisch opslagruimten ‘s nachts bijwerken¶
Weblate haalt automatisch ‘s nachts opslagruimten op afstand op om de prestaties te verbeteren bij het later samenvoegen van wijzigingen. U kunt dit ook inschakelen om ‘s nachts samenvoegingen te doen, door AUTO_UPDATE
in te schakelen.
Wijzigingen vanuit Weblate pushen¶
Elk vertaalonderdeel kan een URL voor pushen ingesteld hebben (bekijk URL voor pushen naar de opslagruimte), en in dat geval zal Weblate in staat zijn de wijziging naar de opslagruimte op afstand te pushen. Weblate kan ook worden geconfigureerd om automatisch wijzigingen te pushen bij elke indiening (commit) (dit is standaard, bekijk Pushen na commit). Als u niet wilt dat de wijzigingen automatisch worden gepusht, kunt u dat handmatig doen onder Onderhoud opslagruimte of de API gebruiken via wlc push
.
De opties voor pushen verschillen, gebaseerd op het gebruikte Versiebeheerintegratie, meer details zijn te vinden in dat hoofdstuk.
Voor het geval dat u geen direct pushen door Weblate wilt, is er ondersteuning voor pull requests van GitHub pull requests, GitLab verzoeken voor samenvoegen, Gitea pull requests, Pagure verzoeken voor samenvoegen, Azure DevOps pull requests of reviews van Gerrit, u kunt deze activeren door te kiezen voor GitHub, GitLab, Gitea, Gerrit, Azure DevOps, of Pagure als Versiebeheersysteem in Configuratie onderdeel.
In het algemeen zijn de volgende opties beschikbaar met Git, Mercurial, GitHub, GitLab, Gitea, Pagure, Azure DevOps, Bitbucket Data Center en Bitbucket Cloud:
Gewenste instelling |
|||
---|---|---|---|
Niet pushen |
leeg |
leeg |
|
Direct pushen |
SSH URL |
leeg |
|
Pushen naar afzonderlijke tak |
SSH URL |
Naam tak |
|
Niet pushen |
leeg |
leeg |
|
Direct pushen |
SSH URL |
leeg |
|
Pushen naar afzonderlijke tak |
SSH URL |
Naam tak |
|
GitHub pull request vanuit fork |
leeg |
leeg |
|
GitHub pull request vanuit tak |
SSH URL [1] |
Naam tak |
|
GitLab merge request vanuit fork |
leeg |
leeg |
|
GitLab merge request vanuit tak |
SSH URL [1] |
Naam tak |
|
Gitea merge request vanuit fork |
leeg |
leeg |
|
Gitea merge request vanuit tak |
SSH URL [1] |
Naam tak |
|
Pagure merge request vanuit fork |
leeg |
leeg |
|
Pagure merge request vanuit tak |
SSH URL [1] |
Naam tak |
|
Azure DevOps pull request vanuit fork |
leeg |
leeg |
|
Azure DevOps pull request vanuit tak |
SSH URL [1] |
Naam tak |
|
Pull request op Bitbucket Data Center uit fork |
leeg |
leeg |
|
Bitbucket Data Center pull request vanuit tak |
SSH URL [1] |
Naam tak |
|
Bitbucket Cloud pull request vanuit fork |
leeg |
leeg |
|
Bitbucket Cloud pull request vanuit tak |
SSH URL [1] |
Naam tak |
Notitie
U kunt ook het automatisch pushen van wijzigingen na commits van Weblate inschakelen, dit kan worden gedaan in Pushen na commit.
Zie ook
Bekijk Toegang tot opslagruimten voor het instellen van sleutels voor SSH, en Vetraagd indienen voor informatie over wanneer Weblate besluit wijzigingen in te dienen.
Beveiligde takken¶
Als u Weblate gebruikt op een beveiligde tak, kunt u het configureren om pull requests te gebruiken en feitelijk beoordelen van de vertalingen uit te voeren (wat problematisch zou kunnen zijn voor talen die u niet beheerst). Een alternatieve benadering is om deze beperking op te heffen voor de Weblate push-gebruiker.
In GitHub kan dit bijvoorbeeld worden gedaan in de configuratie van de opslagruimte:

Interacteren met anderen¶
Weblate maakt het gemakkelijk om met anderen te interacteren met zijn API.
Zie ook
Vetraagd indienen¶
Het gedrag van Weblate is om indieningen van dezelfde auteur te groeperen in een indiening, indien mogelijk. Dit verkleint het aantal indieningen enorm, u zou misschien echter expliciet aan moeten geven om in te dienen in het geval u de opslagruimte van het VCS wilt synchroniseren, bijv. voor samenvoegen (dit is standaard toegestaan voor de groep Beheerders, bekijk Lijst met rechten).
De wijzigingen in deze modus worden ingediend als aan een van de volgende voorwaarden is voldaan:
Iemand anders wijzigt een al gewijzigde tekenreeks.
Er wordt samengevoegd vanuit upstream.
Een expliciete indiening wordt gevraagd.
Downloaden van een bestand wordt gevraagd.
Wijziging is ouder dan de periode die is gedefinieerd als Ouderdom van door te voeren wijzigingen in Configuratie onderdeel.
Hint
Indieningen worden gemaakt voor elk onderdeel. Dus in het geval u heel veel onderdelen hebt, zult u nog steeds heel veel indieningen hebben. U zou in dat geval misschien de add-on Git-commits samenvoegen willen gebruiken.
Wanneer u wijzigingen vaker in wilt dienen en zonder controle op hun ouderdom, kunt u een normale taak plannen om een indiening uit te voeren. Dit kan worden gedaan met Periodic tasks in De Django beheerinterface. Maak eerst de gewenste Interval (bijvoorbeeld 120 seconden). Voeg dan een nieuwe periodieke taak toe en kies weblate.trans.tasks.commit_pending
als Task met {"hours": 0}
als Keyword Arguments en de gewenste interval.
Opslagruimte verwerken met scripts¶
De manier om aan te passen hoe Weblate interacteert met de opslagruimte is Add-ons. Raadpleeg Scripts uitvoeren vanuit add-on voor informatie over hoe externe scripts uit te voeren via add-ons.
Vertalingen hetzelfde houden tussen onderdelen¶
Als eenmaal meerdere vertaalonderdelen hebt, zou u er misschien voor willen zorgen dat dezelfde tekenreeksen ook dezelfde vertaling hebben. Dat kan op verscheidene niveaus worden bereikt.
Verspreiden van vertaling¶
Met Sta propageren van vertalingen toe ingeschakeld (wat de standaard is, bekijk Configuratie onderdeel), worden alle nieuwe vertalingen automatisch doorgevoerd in alle onderdelen met overeenkomende tekenreeksen. Dergelijke vertalingen worden op de juiste wijze geattribueerd met de huidige vertalende gebruiker in alle onderdelen.
Notitie
Het verspreiden van de vertaling vereist de overeenkomende sleutel voor eentalige vertaalindelingen, houd daar dus rekening mee bij het maken van sleutels voor vertalingen.
Controle op consistentie¶
De controle Inconsistent wordt uitgevoerd als de tekenreeksen verschillen. U kunt dit gebruiken om dergelijke verschillen handmatig na te kijken en de juiste vertaling te kiezen.
Automatische vertaling¶
Automatisch vertalen, gebaseerd op verschillende onderdelen, kan een manier zijn om de vertaling tussen onderdelen te synchroniseren. U kunt het ofwel handmatig activeren (bekijk Automatische vertaling) of het automatisch laten uitvoeren bij het bijwerken van de opslagruimte met een add-on (bekijk Automatische vertaling).