Kontinuerlig lokalisering¶

Det finns infrastruktur på plats så att din översättning följer utvecklingen noggrant. På så sätt kan översättarna arbeta med översättningarna hela tiden, istället för att behöva ta sig an en enorm mängd ny text strax före lanseringen.

Se även

Integrering med Weblate beskriver grundläggande sätt att integrera din utveckling med Weblate.

Så här går det till:

Utvecklare gör ändringar och överför dem till VCS-arkivet.
Om så önskas uppdateras översättningsfilerna, se Introduktion av nya strängar.
Weblate hämtar ändringar från VCS-arkivet, analyserar översättningsfiler och uppdaterar sin databas, se Uppdatering av filförråden.
Översättare skickar in översättningar via Weblate-webbgränssnittet eller laddar upp ändringar offline.
När översättarna är klara överför Weblate ändringarna till det lokala arkivet (se Lata åtaganden).
Ändringarna skickas tillbaka till uppströmsrepositoriet (se Skicka ändringar från Weblate).

Råd

Upstream-kodhosting är inte nödvändigt, du kan använda Weblate med Lokala filer där det endast finns ett arkiv inuti Weblate.

Uppdatering av filförråden¶

Du bör skapa något sätt att uppdatera backend-arkiv från deras källa.

Använd Aviseringskopplingar för att integrera med de flesta vanliga kodhostingtjänster:
Du måste också Aktivera hooks för att detta ska fungera.
Starta uppdateringen manuellt antingen i repositorieförvaltningen eller med hjälp av Weblates REST API eller Weblate-klient
Aktivera AUTO_UPDATE för att automatiskt uppdatera alla komponenter på din Weblate-instans
Kör updategit (med val av projekt eller --all för att uppdatera alla)

När Weblate uppdaterar arkivet kommer tilläggen efter uppdateringen att aktiveras, se Tillägg.

Undvika sammanfogningskonflikter¶

Konflikter vid sammanslagning från Weblate uppstår när samma fil har ändrats både i Weblate och utanför det. Beroende på situationen finns det flera tillvägagångssätt som kan hjälpa här:

Undvik konflikter vid sammanslagning genom att endast ändra översättningsfiler i Weblate
Undvik konflikter vid sammanslagning genom att låsa Weblate när du gör ändringar utanför
Undvik konflikter vid sammanslagningar genom att fokusera på Git-operationer

Undvik konflikter vid sammanslagning genom att endast ändra översättningsfiler i Weblate¶

Det är enkelt att undvika redigeringar utanför Weblate med enspråkiga filer – du kan lägga till nya strängar i Weblate och lämna all redigering av filerna där. För tvåspråkiga filer finns det vanligtvis någon form av meddelandeutvinningsprocess för att generera översättningsbara filer från källkoden. I vissa fall kan detta delas upp i två delar:

Extraheringen genererar en mall (till exempel genereras gettext POT med hjälp av xgettext).
Vidare bearbetning sammanfogar det till faktiska översättningar (gettext PO-filerna uppdateras med hjälp av msgmerge).

Du kan utföra det andra steget i Weblate, vilket säkerställer att alla väntande ändringar inkluderas före denna åtgärd.

Undvik konflikter vid sammanslagning genom att låsa Weblate när du gör ändringar utanför¶

Du kan integrera Weblate i din uppdateringsprocess så att ändringarna spolas innan filerna utanför Weblate uppdateras genom att använda Weblates REST API för att tvinga Weblate att skicka alla väntande ändringar och låsa översättningen medan du gör ändringar på din sida.

Skriptet för att göra uppdateringar kan se ut så här:

# 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

Om du har flera komponenter som delar samma arkiv måste du låsa dem alla separat:

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

Observera

I exemplet används Weblate-klient, som behöver konfigureras (API-nycklar) för att kunna styra Weblate på distans. Du kan också uppnå detta med hjälp av valfri HTTP-klient istället för Weblate-klient, till exempel curl, se Weblates REST API.

Undvik konflikter vid sammanslagningar genom att fokusera på Git-operationer¶

Även när Weblate är den enda källan till ändringarna i översättningsfilerna kan konflikter uppstå när du använder tillägget Squasha Git arkiveringar, Sammanslagningsstil är konfigurerat till Rebase eller du squasherar commit utanför Weblate (till exempel när du sammanfogar en pull-begäran).

Orsaken till sammanfogningskonflikter är annorlunda i detta fall – det har skett ändringar i Weblate efter att du sammanfogade Weblate-commits. Detta inträffar vanligtvis om sammanfogningen inte är automatiserad och man väntar i dagar eller veckor på att en människa ska granska dem. Git kan då ibland inte längre identifiera uppströmsändringar som matchande Weblate-ändringar och vägrar att utföra en rebase.

För att lösa detta måste du antingen minimera antalet väntande ändringar i Weblate när du sammanfogar en pull-begäran, eller helt undvika konflikter genom att inte sammanfoga ändringar.

Här är några alternativ för att undvika det:

Använd varken Squasha Git arkiveringar eller squashing vid sammanfogning. Detta är den grundläggande orsaken till att git inte känner igen ändringar efter sammanfogning.
Låt Weblate bekräfta väntande ändringar innan sammanslagning. Detta uppdaterar pull-begäran med alla ändringar, och båda arkiven kommer att synkroniseras.
Använd granskningsfunktionerna i Weblate (se Översättningsarbetsflöden) så att du automatiskt kan slå samman GitHub-pullförfrågningar efter att CI har godkänts.
Använd låsning i Weblate för att undvika ändringar medan GitHub-pull-begäran granskas.

Se även

Weblate-klient

Automatiskt ta emot ändringar från GitHub¶

Weblate har inbyggt stöd för GitHub.

Om du använder Hosted Weblate rekommenderas att du installerar Weblate-appen, så får du rätt inställningar utan att behöva göra så mycket själv. Den kan också användas för att skicka tillbaka ändringar.

För att få aviseringar om varje push till ett GitHub-arkiv, lägg till Weblate Webhook i arkivinställningarna (Webhooks) enligt bilden nedan:

Payload URL består av din Weblate-URL med tillägget /hooks/github/. För Hosted Weblate-tjänsten är detta till exempel https://hosted.weblate.org/hooks/github/.

Du kan lämna andra värden på standardinställningarna (Weblate kan hantera båda innehållstyperna och använder bara push-händelsen).

Se även

Automatiskt ta emot ändringar från Bitbucket¶

Weblate har stöd för Bitbucket-webhooks. Lägg till en webhook som aktiveras vid push till repositoriet, med destinationen till URL:en /hooks/bitbucket/ på din Weblate-installation (till exempel https://hosted.weblate.org/hooks/bitbucket/).

Se även

Automatiskt ta emot ändringar från GitLab¶

Weblate har stöd för GitLab-hooks. Lägg till en projektwebhook med destinationen /hooks/gitlab/ URL på din Weblate-installation (till exempel https://hosted.weblate.org/hooks/gitlab/).

Felsökning

Kontrollera GitLab webhook request history om webhooks levereras.
Svarets nyttolast innehåller information om matchade komponenter.

Se även

Automatiskt ta emot ändringar från Pagure¶

Weblate har stöd för Pagure-hooks. Lägg till en webhook med destinationen /hooks/pagure/ URL på din Weblate-installation (till exempel https://hosted.weblate.org/hooks/pagure/). Detta kan göras i Aktivera webhooks under Projektalternativ:

Se även

Automatiskt ta emot ändringar från Azure Repos¶

Weblate har stöd för Azure Repos-webhooks. Lägg till en webhook för händelsen Code pushed med destinationen /hooks/azure/ URL på din Weblate-installation (till exempel https://hosted.weblate.org/hooks/azure/). Detta kan göras i Service hooks under Project settings.

Se även

Automatiskt ta emot ändringar från Gitea Repos¶

Weblate har stöd för Gitea-webhooks. Lägg till en Gitea Webhook för Push events-händelsen med destinationen /hooks/gitea/ URL på din Weblate-installation (till exempel https://hosted.weblate.org/hooks/gitea/). Detta kan göras i Webhooks under Settings för repositoriet.

Se även

Automatiskt ta emot ändringar från Gitee Repos¶

Weblate har stöd för Gitee-webhooks. Lägg till en WebHook för Push-händelse med destinationen /hooks/gitee/ URL på din Weblate-installation (till exempel https://hosted.weblate.org/hooks/gitee/). Detta kan göras i WebHooks under Management i arkivet.

Se även

Automatisk uppdatering av arkiv varje natt¶

Weblate hämtar automatiskt fjärrlagringsplatser varje natt för att förbättra prestandan när ändringar senare slås samman. Du kan också välja att göra detta till nattliga sammanslagningar genom att aktivera AUTO_UPDATE.

Skicka ändringar från Weblate¶

Varje översättningskomponent kan ha en push-URL inställd (se Push-URL för arkiv), och i så fall kan Weblate skicka ändringar till det fjärranslutna arkivet. Weblate kan också konfigureras för att automatiskt överföra ändringar vid varje commit (detta är standard, se Skicka vid incheckning). Om du inte vill att ändringar ska överföras automatiskt kan du göra det manuellt under Repository maintenance eller med hjälp av API:et via wlc push.

Push-alternativen skiljer sig åt beroende på vilken Integration av versionskontroll som används. Mer information finns i det kapitlet.

Om du inte vill ha direkta pushar från Weblate finns stöd för GitHub-pullförfrågningar, GitLab-sammanslagningsförfrågningar, Gitea-pullförfrågningar, Pagure-sammanslagningsförfrågningar, Azure DevOps pull-förfrågningar pull-förfrågningar eller Gerrit granskningar. Du kan aktivera dessa genom att välja GitHub, GitLab, Gitea, Gerrit, Azure DevOps eller Pagure som Versionshanteringssystem i Komponentkonfiguration.

Sammantaget finns följande alternativ tillgängliga med Git, Mercurial, GitHub, GitLab, Gitea, Pagure, Azure DevOps, Bitbucket Data Center och Bitbucket Cloud:

Önskad inställning	Versionshanteringssystem	Push-URL för arkiv	Pusha gren
Ingen push	Git	tom	tom
Tryck direkt	Git	URL för SSH	tom
Tryck för att separera gren	Git	URL för SSH	Grenens namn
Ingen push	Mercurial	tom	tom
Tryck direkt	Mercurial	URL för SSH	tom
Tryck för att separera gren	Mercurial	URL för SSH	Grenens namn
GitHub-pullförfrågan från fork	GitHub-pullförfrågningar	tom	tom
GitHub-pullförfrågan från gren	GitHub-pullförfrågningar	SSH URL [1]	Grenens namn
GitLab-sammanslagningsförfrågan från fork	GitLab-sammanslagningsförfrågningar	tom	tom
GitLab-sammanslagningsbegäran från gren	GitLab-sammanslagningsförfrågningar	SSH URL [1]	Grenens namn
Gitea-sammanslagningsförfrågan från fork	Gitea-pullförfrågningar	tom	tom
Gitea-sammanslagningsbegäran från gren	Gitea-pullförfrågningar	SSH URL [1]	Grenens namn
Pagure-sammanslagningsförfrågan från fork	Pagure-sammanslagningsförfrågningar	tom	tom
Pagure-sammanslagningsbegäran från gren	Pagure-sammanslagningsförfrågningar	SSH URL [1]	Grenens namn
Azure DevOps pull-förfrågan från fork	Azure DevOps pull-förfrågningar	tom	tom
Azure DevOps pull-förfrågan från gren	Azure DevOps pull-förfrågningar	SSH URL [1]	Grenens namn
Bitbucket Data Center pull-begäran från fork	Bitbucket Data Center-pullförfrågningar	tom	tom
Bitbucket Data Center pull-förfrågan från gren	Bitbucket Data Center-pullförfrågningar	SSH URL [1]	Grenens namn
Bitbucket Cloud-pullförfrågan från fork	Bitbucket Cloud-pullförfrågningar	tom	tom
Bitbucket Cloud-pullförfrågan från gren	Bitbucket Cloud-pullförfrågningar	SSH URL [1]	Grenens namn

Observera

Du kan också aktivera automatisk överföring av ändringar efter Weblate-commits. Detta kan göras i Skicka vid incheckning.

Se även

Se Åtkomst till arkiv för att konfigurera SSH-nycklar och Lata åtaganden för information om när Weblate beslutar att bekräfta ändringar.

Skyddade grenar¶

Om du använder Weblate på en skyddad gren kan du konfigurera den så att den använder pull-förfrågningar och utför en faktisk granskning av översättningarna (vilket kan vara problematiskt för språk du inte kan). Ett alternativ är att upphäva denna begränsning för Weblate-pushanvändaren.

På GitHub kan detta till exempel göras i repositoriekontrollen:

Interagera med andra¶

Weblate gör det enkelt att interagera med andra med hjälp av dess API.

Se även

Weblates REST API

Lata åtaganden¶

Weblate grupperar om möjligt alla commit från samma författare till en enda commit. Detta minskar antalet commit avsevärt, men du kan behöva ange uttryckligen att commit ska göras om du vill synkronisera VCS-arkivet, t.ex. för sammanslagning (detta är som standard tillåtet för gruppen Managers, se Förteckning över privilegier).

Ändringarna i detta läge bekräftas när något av följande villkor är uppfyllt:

Någon annan ändrar en redan ändrad sträng.
En sammanslagning från uppströms sker.
En uttrycklig bekräftelse krävs.
En filnedladdning begärs.
Ändringen är äldre än den period som definieras som Ålder på ändringar att arkivera på Komponentkonfiguration.

Råd

Commits skapas för varje komponent. Om du har många komponenter kommer du alltså fortfarande att se många commits. I så fall kan du använda tillägget Squasha Git arkiveringar.

Om du vill göra ändringar oftare och utan att kontrollera åldern kan du schemalägga en regelbunden uppgift för att utföra en commit. Detta kan göras med hjälp av Periodiska uppgifter i Djangos administratörsgränssnitt. Skapa först önskat Intervall (till exempel 120 sekunder). Lägg sedan till en ny periodisk uppgift och välj weblate.trans.tasks.commit_pending som Uppgift med {"hours": 0} som Nyckelordsargument och önskat intervall.

Bearbetning av arkiv med skript¶

Du kan anpassa hur Weblate interagerar med arkivet med hjälp av Tillägg. Se Körning av skript från tillägg för information om hur du kör externa skript via tillägg.

Hålla översättningarna lika mellan komponenterna¶

När du har flera översättningskomponenter kan det vara bra att se till att samma strängar har samma översättning. Detta kan uppnås på flera nivåer.

Översättningsspridning¶

Med Tillåt spridning av översättning aktiverat (vilket är standard, se Komponentkonfiguration) görs alla nya översättningar automatiskt i alla komponenter med matchande strängar. Sådana översättningar krediteras korrekt till den användare som för närvarande översätter i alla komponenter.

Förutsättningar för spridning:

Alla komponenter måste finnas i ett enda projekt (det räcker inte med att länka komponenter).
Aktivera Tillåt spridning av översättning för att automatiskt återanvända översättningar för matchande strängar.
Översättningsspridningen kräver att nyckeln matchar enspråkiga översättningsformat, så tänk på det när du skapar översättningsnycklar.
Strängarna sprids under översättningen, men strängar som laddas från arkivet sprids inte.

Tips

Denna funktion har för närvarande begränsningar, och vi vill göra den mer universell. Vänligen dela med dig av dina synpunkter på https://github.com/WeblateOrg/weblate/issues/3166.

Konsistenskontroll¶

Kontrollen Inkonsekvent utlöses när strängarna skiljer sig åt. Du kan använda detta för att manuellt granska sådana skillnader och välja rätt översättning.

Automatisk översättning¶

Automatisk översättning baserad på olika komponenter kan vara ett sätt att synkronisera översättningarna mellan komponenterna. Du kan antingen starta den manuellt (se Automatisk översättning) eller låta den köras automatiskt vid uppdatering av arkivet med hjälp av ett tillägg (se Automatisk översättning).