Integrering med Weblate¶

Grunderna i Weblate¶

Projekt- och komponentstruktur¶

I Weblate är översättningar organiserade i projekt och komponenter. Varje projekt kan innehålla ett antal komponenter och dessa innehåller översättningar till enskilda språk. Komponenten motsvarar en översättningsbar fil (till exempel GNU gettext PO (Portable Object) eller Android-strängresurser). Projekten finns till för att hjälpa dig att organisera komponenter i logiska uppsättningar (till exempel för att gruppera alla översättningar som används inom en applikation).

Dessutom kan komponenter inom projekt struktureras med hjälp av kategorier. Komponenter kan tillhöra en kategori, och kategorier kan vara hierarkiska.

Internt har varje projekt översättningar till vanliga strängar som sprids till andra komponenter inom projektet som standard. Detta minskar bördan av repetitiva översättningar och översättningar i flera versioner. Översättningsspridningen kan inaktiveras per Komponentkonfiguration med hjälp av Tillåt spridning av översättning om översättningarna skulle skilja sig åt.

Integrering av arkiv¶

Weblate är byggt för att integreras med uppströms versionskontrollförvar, Kontinuerlig lokalisering beskriver byggstenar och hur förändringarna flödar mellan dem.

Se även

Arkitekturöversikt beskriver hur Weblate fungerar internt.

Användarattribution¶

Weblate sparar översättningarna som översättarna har skapat i versionskontrollförvaret med hjälp av namn och e-postadress. Att ha en riktig e-postadress kopplad till commit följer principerna för distribuerad versionskontroll och gör det möjligt för tjänster som GitHub att koppla dina bidrag i Weblate till din GitHub-profil.

Denna funktion medför också en risk för missbruk av e-postmeddelanden som publiceras i versionskontrollens commit. Dessutom finns det i praktiken inget sätt att redigera en sådan commit när den väl har publicerats på en offentlig hosting (som GitHub). Weblate gör det möjligt att välja ett privat commit-e-postmeddelande i Konto för att undvika detta.

Därför bör administratörer ta hänsyn till detta när de konfigurerar Weblate:

En sådan användning av e-post bör tydligt beskrivas i tjänstevillkoren om ett sådant dokument behövs. Juridisk modul kan hjälpa till med det.
PRIVATE_COMMIT_EMAIL_OPT_IN kan göra e-postmeddelanden privata som standard.

Importera ett lokaliseringsprojekt till Weblate¶

Weblate har utvecklats med VCS-integration som en central funktion, så det enklaste sättet är att ge Weblate åtkomst till ditt arkiv. Importprocessen guidar dig genom konfigureringen av dina översättningar till Weblate-komponenter.

Alternativt kan du låta Weblate skapa ett lokalt arkiv som innehåller alla översättningar utan integration.

Se även

Hämta uppdaterade översättningar från Weblate¶

Weblate lagrar uppdaterade strängar i en databas och överför dem till ett lokalt versionskontrollarkiv. Du kan lägga till ett Weblate-arkiv (när Git-exportör är aktiverat) som ett extra fjärrarkiv och hämta översättningsuppdateringar från det.

Innan detta kan du behöva bekräfta eventuella lokala ändringar som gjorts i Weblate (se Lata åtaganden). Detta kan göras från användargränssnittet (i Repository maintenance), eller från kommandoraden med hjälp av Weblate-klient.

Att skicka ändringar kan automatiseras om du ger Weblate push-åtkomst till ditt arkiv och konfigurerar Push-URL för arkiv i Komponentkonfiguration, se Skicka ändringar från Weblate.

Alternativt kan du använda Weblates REST API för att uppdatera översättningarna så att de matchar den senaste versionen från uppströms i ditt fjärr-VCS-arkiv.

Se även

Hämta fjärrändringar till Weblate¶

För att hämta alla strängar som nyligen uppdaterats i ditt fjärr-VCS-arkiv till Weblate, låt Weblate hämta från uppströmsarkivet. Detta kan göras i användargränssnittet (i Repository maintenance), eller från kommandoraden med hjälp av Weblate-klient.

Detta kan automatiseras genom att ställa in en webhook i ditt arkiv för att aktivera Weblate varje gång det finns en ny commit. Se Uppdatering av filförråden för mer information.

Om du inte använder VCS-integration kan du använda gränssnittet eller Weblates REST API för att uppdatera översättningarna så att de stämmer överens med din kodbas.

Se även

Lägga till nya strängar¶

Om dina översättningsfiler lagras i ett fjärr-VCS tillsammans med koden har du troligen redan ett arbetsflöde för utvecklare att införa nya strängar. Alla sätt att lägga till strängar kommer att registreras, men överväg att använda Kvalitetsfilter för källsträngarna för att undvika att fel införs.

När översättningsfiler separeras från koden kan följande metoder användas för att införa nya strängar i Weblate.

Manuellt, genom att använda Lägg till ny översättningssträng från Åtgärder-menyn i källspråket. Du kan välja mellan alternativknapparna Singular och Plural i formuläret. Välj lämplig form för den nya översättningssträngen som ska läggas till.
Programmatiskt, med hjälp av API POST /api/translations/(string:project)/(string:component)/(string:language)/units/.
Genom att ladda upp källfilen som Ersätt befintlig översättningsfil (detta skriver över befintliga strängar, så se till att filen innehåller både gamla och nya strängar) eller Lägg till nya strängar, se Importmetoder.

Observera

För att kunna lägga till strängar i Weblate krävs Hantera strängar.

Uppdatera filer på målspråket¶

För enspråkiga filer (se Lokalisering filformat) kan Weblate lägga till nya översättningssträngar som finns i Enspråkig basspråkfil, men inte i de faktiska översättningarna. Det gör dock ingen automatisk rensning av gamla strängar, eftersom det kan ge oväntade resultat. Om du ändå vill göra detta, installera tillägget Städa upp i översättningsfiler, som hanterar rensningen enligt dina krav.

Weblate försöker inte heller uppdatera tvåspråkiga filer när källan ändras, så om du behöver uppdatera po-filer från pot har du två alternativ:

Automatiskt med ett tillägg (rekommenderas för kontinuerliga uppdateringar): Installera tillägget Uppdatera PO-filerna till att matcha POT (msgmerge), som automatiskt kör msgmerge för att uppdatera alla PO-filer när POT-filen ändras.
Manuellt via uppladdning: Använd Uppdatera källsträngar Importmetoder för att ladda upp din POT-fil, som kommer att slås samman med befintliga översättningar.

Råd

Verktyg för extrahering av källsträngar, såsom xgettext eller lupdate, måste köras utanför Weblate.

Se även

Introduktion av nya strängar¶

Du kan lägga till nya strängar i Weblate med Hantera strängar aktiverat, men det är oftast bättre att införa nya strängar tillsammans med de kodändringar som introducerade dem.

Enspråkiga format måste konfigureras så att nya strängar läggs till i Enspråkig basspråkfil. Detta görs vanligtvis av utvecklare när de skriver koden. Du kanske vill använda en granskningsprocess för dessa strängar med hjälp av Kvalitetsfilter för källsträngarna.

Tvåspråkiga format extraherar vanligtvis strängar från källkoden med hjälp av vissa verktyg (som xgettext eller intltool-update). Följ dokumentationen för ditt lokaliseringsramverk för instruktioner om hur du gör detta. När strängarna har extraherats kan det behövas ett ytterligare steg för att uppdatera befintliga översättningar, se Uppdatera filer på målspråket.

Råd

Automatisering av strängutvinning ligger för närvarande utanför Weblates räckvidd. Det innebär vanligtvis att man kör opålitlig kod, vilket gör det mer lämpligt för en generisk kontinuerlig integration än en lokaliseringsspecifik plattform.

Du kanske vill integrera detta i dina kontinuerliga integrationspipelines så att nya strängar automatiskt visas för översättning. En sådan pipeline bör också omfatta Undvika sammanfogningskonflikter.

Se även

Hantera det lokala VCS-arkivet¶

Weblate lagrar alla översättningar i sitt underliggande versionskontrollarkiv. Det rekommenderas att ansluta till ett fjärrarkiv, men det går också att använda ett internt arkiv. Med Repository maintenance kan du hantera detta arkiv.

Råd

Med Kontinuerlig lokalisering skickas alla ändringar automatiskt från arkivet, så det finns vanligtvis inget behov av att hantera det manuellt.

Se även