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 describes basic ways to integrate your development with Weblate. Code hosting integrations lists provider-specific setup steps for common code hosting sites.

Så här går det till:

1. Utvecklare gör ändringar och överför dem till VCS-arkivet.

2. Om så önskas uppdateras översättningsfilerna, se Introduktion av nya strängar.

3. Weblate hämtar ändringar från VCS-arkivet, analyserar översättningsfiler och uppdaterar sin databas, se Uppdatering av filförråden.

4. Översättare skickar in översättningar via Weblate-webbgränssnittet eller laddar upp ändringar offline.

5. När översättarna är klara överför Weblate ändringarna till det lokala arkivet (se Lata åtaganden).

6. Changes are pushed back to the upstream repository (see 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.

• Use Aviseringskopplingar to integrate with the majority of common code hosting services, see Code hosting integrations. You must also Aktivera hooks for this to work.

• 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:

1. Extraheringen genererar en mall (till exempel genereras gettext POT med hjälp av xgettext).

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

Arkivunderhåll

The Repository maintenance view shows repository status for a project, component, or translation and lets privileged users run maintenance operations from the user interface.

The same actions can also be triggered using Weblates REST API or, for the supported subset, Weblate-klient.

Availability of individual actions depends on permissions, the configured version control system, whether pushing is configured, and whether the selected object can be locked.

Handling	What it does	Typical use
Commit	Commits pending changes stored in Weblate to the local repository.	Flush pending Weblate changes before doing repository work elsewhere.
Push	Pushes committed local repository changes to the configured upstream.	Send committed translations upstream when automatic push is disabled or delayed.
Update	Fetches upstream changes and integrates them using the component’s configured Sammanslagningsstil.	Bring Weblate in sync with upstream using the default integration strategy.
Update with merge	Fetches upstream changes and integrates them with an explicit merge.	Override the default merge style for a single update.
Update with rebase	Fetches upstream changes and rebases local Weblate commits on top of upstream.	Keep history linear when that matches your workflow.
Update with merge without fast-forward	Fetches upstream changes and creates an explicit merge commit even when a fast-forward would be possible.	Preserve merge commits for auditing or branch-management reasons.
Lock / Unlock	Prevents or allows translators to make further changes in Weblate.	Freeze translation changes while doing repository maintenance outside Weblate.
Reset and discard	Resets Weblate’s local repository to upstream and discards pending Weblate changes.	Use when upstream should overwrite the local Weblate repository state.
Reset and reapply	Resets Weblate’s local repository to upstream while preserving pending translations. See Reset and reapply recovery behavior.	Recover from diverged history while keeping pending Weblate translations.
Cleanup	Removes untracked files and stale branches from the local repository checkout.	Clean up leftover files or stale repository state in Weblate’s checkout.
Synchronize	Forces Weblate to write all known translations back to the repository files.	Repair cases where repository files became out of sync with the database state.
Rescan	Re-reads translation files from the local repository into Weblate.	Import file changes after manual repository work or file creation.

Reset and reapply recovery behavior

The Reset and reapply operation keeps pending translations from Weblate while resetting the local repository state to match upstream.

The operation can restore pending translations only when the target language files still exist after the reset or when Weblate can create them for the component, for example using a valid Mall för nya översättningar.

If neither of these conditions is met, Weblate keeps the pending changes in its database and reports a recovery error instead of failing later with a generic parse error.

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

Code hosting notifications

Provider-specific app and webhook instructions for GitHub, GitLab, Bitbucket, Pagure, Azure Repos, Gitea, Forgejo, and Gitee are covered in Code hosting integrations.

Provider-specific notifications

These legacy anchors are kept for compatibility. Current provider-specific app and webhook setup is documented in Code hosting integrations.

Se även

• GitHub notifications

• GitLab notifications

• Bitbucket notifications

• Pagure notifications

• Azure Repos notifications

• Gitea notifications

• Forgejo notifications

• Gitee notifications

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

Each translation component can have a push URL set up (see Push-URL för arkiv), and in that case Weblate will be able to push changes to the remote repository. Weblate can also be configured to automatically push changes on every commit, see Skicka vid incheckning.

For the push options table and provider-specific pull, merge, and review request workflows, see Skicka ändringar från Weblate.

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