Vanliga frågor¶
Konfiguration¶
Hur skapar man ett automatiserat arbetsflöde?¶
Weblate kan hantera alla översättningsuppgifter halvautomatiskt åt dig. Om du ger det push-åtkomst till ditt arkiv kan översättningarna ske utan interaktion, såvida inte någon sammanfogningskonflikt uppstår.
Konfigurera ditt Git-arkiv så att det meddelar Weblate när det sker någon förändring. Se Aviseringskopplingar för information om hur du gör det.
Ange en push-URL i din Komponentkonfiguration i Weblate, så att Weblate kan överföra ändringar till ditt arkiv.
Aktivera Skicka vid incheckning på din Komponentkonfiguration i Weblate. Detta gör att Weblate skickar ändringar till ditt arkiv så fort de görs i Weblate.
Hur får man åtkomst till arkiv via SSH?¶
Se Åtkomst till arkiv för information om hur du konfigurerar SSH-nycklar.
Hur åtgärdar man sammanfogningskonflikter i översättningar?¶
Konflikter uppstår ibland när översättningsfilen ändras samtidigt i både Weblate och uppströmsrepositoriet. Du kan vanligtvis undvika detta genom att slå samman Weblate-översättningar innan du gör ändringar i översättningsfilerna (t.ex. innan du kör msgmerge). Be bara Weblate att bekräfta alla väntande översättningar (du kan göra det i Repository maintenance i menyn Operations) och slå samman arkivet (om automatisk push inte är aktiverad).
Om du redan har stött på en sammanfogningskonflikt är det enklaste sättet att lösa alla konflikter lokalt på din dator att lägga till Weblate som ett fjärrarkiv, sammanfoga det i uppströms och åtgärda eventuella konflikter. När du har skickat tillbaka ändringarna kommer Weblate att kunna använda den sammanfogade versionen utan några andra särskilda åtgärder.
Observera
Beroende på din konfiguration kan åtkomst till Weblate-arkivet kräva autentisering. När du använder den inbyggda Git-exportör i Weblate autentiserar du dig med ditt användarnamn och API-nyckeln.
# Open an existing checkout of the upstream repository or perform a fresh one:
git clone UPSTREAM_REPOSITORY_URL
cd REPO
# Commit all pending changes in Weblate, you can do this in the UI as well:
wlc commit
# Lock the translation in Weblate, again this can be done in the UI as well:
wlc lock
# Add Weblate as remote:
git remote add weblate https://hosted.weblate.org/git/project/component/
# You might need to include credentials in some cases:
git remote add weblate https://username:APIKEY@hosted.weblate.org/git/project/component/
# Update weblate remote:
git remote update weblate
# Merge Weblate changes:
git merge weblate/main
# Resolve conflicts:
edit …
git add …
…
git commit
# Rebase changes (if Weblate is configured to do rebases)
git rebase origin/main
# Push changes to upstream repository, Weblate will fetch merge from there:
git push
# Open Weblate for translation:
wlc unlock
Om du använder flera grenar i Weblate kan du göra samma sak med alla:
# Add and update Weblate remotes
git remote add weblate-one https://hosted.weblate.org/git/project/one/
git remote add weblate-second https://hosted.weblate.org/git/project/second/
git remote update weblate-one weblate-second
# Merge QA_4_7 branch:
git checkout QA_4_7
git merge weblate-one/QA_4_7
... # Resolve conflicts
git commit
# Merge main branch:
git checkout main
git merge weblates-second/main
... # Resolve conflicts
git commit
# Push changes to the upstream repository, Weblate will fetch the merge from there:
git push
När det gäller gettext PO-filer finns det ett sätt att slå samman konflikter på ett halvautomatiskt sätt:
Hämta och spara en lokal klon av Weblate Git-arkivet. Hämta också en andra ny lokal klon av uppströms Git-arkivet (dvs. du behöver två kopior av uppströms Git-arkivet: en intakt och en fungerande kopia):
# Add remote:
git remote add weblate /path/to/weblate/snapshot/
# Update Weblate remote:
git remote update weblate
# Merge Weblate changes:
git merge weblate/main
# Resolve conflicts in the PO files:
for PO in `find . -name '*.po'` ; do
msgcat --use-first /path/to/weblate/snapshot/$PO\
/path/to/upstream/snapshot/$PO -o $PO.merge
msgmerge --previous --lang=${PO%.po} $PO.merge domain.pot -o $PO
rm $PO.merge
git add $PO
done
git commit
# Push changes to the upstream repository, Weblate will fetch merge from there:
git push
Hur översätter jag flera grenar samtidigt?¶
Weblate stöder överföring av översättningsändringar inom ett Projektkonfiguration. För varje Komponentkonfiguration där funktionen är aktiverad (standardinställning) överförs ändringen automatiskt till andra komponenter. På så sätt hålls översättningarna synkroniserade även om grenarna i sig redan har divergerat ganska mycket och det inte är möjligt att helt enkelt slå samman översättningsändringarna mellan dem.
När du har sammanfört ändringarna från Weblate kan du behöva sammanföra dessa grenar (beroende på ditt utvecklingsflöde) och kasta bort skillnaderna:
git merge -s ours origin/maintenance
Hur översätter man projekt för flera plattformar?¶
Weblate stöder ett brett utbud av filformat (se Lokalisering filformat) och det enklaste sättet är att använda det inbyggda formatet för varje plattform.
När du har lagt till alla plattformsöversättningsfiler som komponenter i ett projekt (se Lägga till översättningsprojekt och komponenter) kan du använda funktionen för översättningsspridning (aktiverad som standard, kan inaktiveras i Komponentkonfiguration) för att översätta strängar för alla plattformar samtidigt.
Hur exporterar man Git-arkivet som Weblate använder?¶
Det finns inget speciellt med arkivet, det finns under katalogen DATA_DIR och heter vcs/<project>/<component>/. Om du har SSH-åtkomst till den här maskinen kan du använda arkivet direkt.
För anonym åtkomst kan du köra en Git-server och låta den tillhandahålla arkivet till omvärlden.
Alternativt kan du använda Git-exportör i Weblate för att automatisera detta.
Vilka alternativ finns för att skicka tillbaka ändringar uppströms?¶
Detta beror i hög grad på din konfiguration, Weblate är ganska flexibelt på detta område. Här är några exempel på arbetsflöden som används med Weblate:
Weblate överför och sammanfogar ändringar automatiskt (se Hur skapar man ett automatiserat arbetsflöde?).
Du ber Weblate manuellt att pusha (det krävs push-åtkomst till uppströmsrepositoriet).
Någon sammanfogar manuellt ändringar från Weblate git-arkivet till uppströmsarkivet.
Någon skriver om historiken som skapats av Weblate (t.ex. genom att ta bort sammanfogningskommandon), sammanfogar ändringarna och ber Weblate att återställa innehållet i uppströmsrepositoriet.
Naturligtvis kan du blanda alla dessa efter eget tycke och smak.
Hur kan jag begränsa åtkomsten till Weblate till endast översättningar, utan att exponera källkoden för den?¶
Du kan använda git submodule för att separera översättningar från källkoden samtidigt som de fortfarande är under versionskontroll.
Skapa ett arkiv med dina översättningsfiler.
Lägg till detta som en submodul till din kod:
git submodule add git@example.com:project-translations.git path/to/translations
Länka Weblate till detta arkiv, det behöver inte längre ha åtkomst till arkivet som innehåller din källkod.
Du kan uppdatera huvudarkivet med översättningar från Weblate genom att:
git submodule update --remote path/to/translations
Se dokumentationen för git submodule för mer information.
Hur kan jag kontrollera om min Weblate är korrekt konfigurerad?¶
Weblate innehåller en uppsättning konfigurationskontroller som du kan se i administratörsgränssnittet. Följ bara länken Prestandarapport i administratörsgränssnittet eller öppna URL:en /manage/performance/ direkt.
Varför är alla commit gjorda av Weblate <noreply@weblate.org>?¶
Weblate använder Weblate <noreply@weblate.org> som standard committer för alla commits, vilket konfigureras av DEFAULT_COMMITER_EMAIL och DEFAULT_COMMITER_NAME. Detta är en teknisk identifierare som visar att commit har bearbetats via Weblate.
Dock registreras författaren till varje commit korrekt som den enskilda användare som gjorde översättningen (vid användning av Git). Detta innebär att du kan se vem som faktiskt översatte varje sträng genom att undersöka fältet för commit-författare. Detsamma gäller Mercurial; endast Subversion har inte denna funktion.
Observera
I Git skiljer man mellan committer (den som skapade commit-objektet) och författaren (den som gjorde ändringarna). Weblate fungerar som committer samtidigt som man bevarar enskilda översättares upphovsrätt som författare.
För commit där upphovsmannen inte kan fastställas (t.ex. automatiska ändringar från anonyma förslag eller maskinöversättningsresultat) anges upphovsmannen som anonym användare. Du kan konfigurera den anonyma användarens namn och e-postadress i ANONYMOUS_USER_NAME.
Se även
Hur flyttar man filer i arkivet utan att förlora historiken i Weblate?¶
För att behålla historiken, kommentarerna eller skärmdumparna kopplade till strängarna efter att du har ändrat filernas plats måste du se till att dessa strängar aldrig raderas i Weblate. Dessa borttagningar kan inträffa om Weblate-arkivet uppdateras, men komponentkonfigurationen fortfarande pekar på de gamla filerna. Detta gör att Weblate antar att alla översättningar ska raderas.
Lösningen på detta är att utföra operationen synkroniserat med Weblate:
Lås den berörda komponenten i Weblate.
Bekräfta alla väntande ändringar och slå ihop dem i uppströmsrepositoriet.
Inaktivera mottagning av webhooks för Projektkonfiguration; detta förhindrar Weblate från att omedelbart se ändringar i arkivet.
Gör eventuella nödvändiga ändringar i repo (till exempel med hjälp av git mv), och skicka dem till uppströmsrepositoriet.
Ändra Komponentkonfiguration så att den matchar den nya konfigurationen. När konfigurationen ändras hämtar Weblate det uppdaterade arkivet och noterar de ändrade platserna samtidigt som befintliga strängar behålls.
Lås upp komponenten och återaktivera krokarna i projektkonfigurationen.
Råd
Säkerhetskopior på projektnivå kan vara användbart att utföra innan sådana störande förändringar.
Användning¶
Hur granskar jag andras översättningar?¶
Det finns flera granskningsbaserade arbetsflöden tillgängliga i Weblate, se Översättningsarbetsflöden.
Du kan prenumerera på alla ändringar som görs i Aviseringar och sedan kontrollera andras bidrag när de kommer in via e-post.
I botten av översättningsvyn finns ett granskningsverktyg där du kan välja att bläddra bland översättningar som gjorts av andra sedan ett visst datum.
Se även
Hur ger jag feedback på en källsträng?¶
På kontextflikarna under översättningen kan du använda fliken Kommentarer för att ge feedback på en källsträng eller diskutera den med andra översättare.
Hur kan jag använda befintliga översättningar när jag översätter?¶
Alla översättningar inom Weblate kan användas tack vare delat översättningsminne.
Du kan importera befintliga översättningsminnesfiler till Weblate.
Använd importfunktionen för att ladda kompendiet som översättningar, förslag eller översättningar som behöver granskas. Detta är den bästa metoden för en engångsöversättning med hjälp av ett kompendium eller en liknande översättningsdatabas.
Du kan konfigurera tmserver med alla databaser du har och låta Weblate använda den. Detta är bra när du vill använda den flera gånger under översättningen.
Ett annat alternativ är att översätta alla relaterade projekt i en enda Weblate-instans, vilket gör att den automatiskt hämtar översättningar från andra projekt också.
Uppdaterar Weblate översättningsfiler förutom översättningar?¶
Weblate försöker begränsa ändringar i översättningsfiler till ett minimum. För vissa filformat kan detta tyvärr leda till att filen omformateras. Om du vill behålla filens format, använd en pre-commit-hook för detta.
Se även
Hur sammanfogar jag uppdaterade POT-filer med PO-översättningar?¶
Se Uppdatera filer på målspråket för information om hur du uppdaterar PO-filer när POT-mallen ändras.
Varifrån kommer språkteckningarna och hur kan jag lägga till egna?¶
Den grundläggande uppsättningen språkteckningar ingår i Weblate och Translate-toolkit. Den täcker mer än 150 språk och innehåller information om pluralformer och textriktning.
Du kan fritt definiera dina egna språk i administrationsgränssnittet, du behöver bara ange information om det.
Se även
Kan Weblate markera ändringar i en fuzzy-sträng?¶
Weblate stöder detta, men det behöver data för att visa skillnaden.
För Gettext PO-filer måste du ange parametern --previous till msgmerge när du uppdaterar PO-filer, till exempel:
msgmerge --previous -U po/cs.po po/phpmyadmin.pot
För enspråkiga översättningar kan Weblate hitta den tidigare strängen med hjälp av ID, så att skillnaderna visas automatiskt.
Varför visar Weblate fortfarande gamla översättningssträngar när jag har uppdaterat mallen?¶
Weblate försöker inte manipulera översättningsfilerna på något annat sätt än att låta översättarna översätta. Det uppdaterar alltså inte de översättningsbara filerna när mallen eller källkoden har ändrats. Du måste helt enkelt göra detta manuellt och skicka ändringarna till arkivet, så hämtar Weblate ändringarna automatiskt.
Observera
Det är vanligtvis en bra idé att slå samman ändringar som gjorts i Weblate innan du uppdaterar översättningsfilerna, eftersom du annars oftast kommer att få konflikter att lösa.
Hur hanterar man omdöpning av översättningsfiler?¶
När du byter namn på filer i arkivet kan det hända att Weblate tolkar detta som att filerna tas bort och läggs till. Detta kan leda till att stränghistorik, kommentarer och förslag går förlorade.
För att undvika detta, utför namnändringen enligt följande steg:
Lås översättningskomponenten i Hantera det lokala VCS-arkivet.
Bekräfta väntande ändringar i Hantera det lokala VCS-arkivet.
Sammanfoga Weblate-ändringar till uppströmsrepositoriet.
Inaktivera mottagning av uppdateringar via hooks med hjälp av Aktivera hooks.
Utför omdöpningen av filerna i arkivet.
Uppdatera komponentkonfigurationen så att den stämmer överens med de nya filnamnen.
Aktivera uppdateringshookar och lås upp komponenten.
Råd
Säkerhetskopior på projektnivå kan vara användbart att utföra innan sådana störande förändringar.
Felsökning¶
Begäran misslyckas ibland med felmeddelandet ”för många öppna filer”¶
Detta händer ibland när ditt Git-arkiv växer sig för stort och du har många av dem. Komprimering av Git-arkiven förbättrar denna situation.
Det enklaste sättet att göra detta är att köra:
# Go to DATA_DIR directory
cd data/vcs
# Compress all Git repositories
for d in */* ; do
pushd $d
git gc
popd
done
Se även
När jag försöker komma åt webbplatsen får jag felmeddelandet ”Bad Request (400)”¶
Detta beror troligen på en felaktigt konfigurerad ALLOWED_HOSTS. Den måste innehålla alla värdnamn som du vill ha åtkomst till på din Weblate. Till exempel:
ALLOWED_HOSTS = ["weblate.example.com", "weblate", "localhost"]
Se även
Vad betyder ”Det finns fler filer för det enskilda språket (en)”?¶
Detta händer vanligtvis när du har en översättningsfil för källspråket. Weblate håller reda på källsträngar och reserverar källspråket för detta. Den extra filen för samma språk behandlas inte.
Om du vill ha översättningen till källspråket, ändra Källspråk i komponentinställningarna. Du kan använda English (Developer) som källspråk eller använda Kvalitetsfilter för källsträngarna.
Om översättningsfilen för källspråket inte behövs, ta bort den från arkivet.
Om översättningsfilen för källspråket behövs, men ska ignoreras av Weblate, justera Språkfilter för att utesluta den.
Råd
Du kan få liknande felmeddelanden även för andra språk. I så fall är den mest troliga orsaken att flera filer är kopplade till ett enda språk i Weblate.
Detta kan orsakas av att man använder föråldrade språkkoder tillsammans med nya (ja och jp för japanska) eller inkluderar både landsspecifika och generiska koder (fr och fr_FR). Se Analysera språkkoder för mer information.
Funktioner¶
Stöder Weblate andra VCS-system än Git och Mercurial?¶
Weblate har för närvarande inte inbyggt stöd för något annat än Git (med utökat stöd för GitHub-pullförfrågningar, Gerrit och Subversion) och Mercurial, men det är möjligt att skriva backends för andra VCS:er.
Weblate stöder även drift utan VCS, se Lokala filer.
Observera
För inbyggt stöd för andra VCS-system kräver Weblate användning av distribuerade VCS-system, och kan förmodligen anpassas för att fungera med andra system än Git och Mercurial, men någon måste implementera detta stöd.
Se även
Hur krediterar Weblate översättare?¶
Varje ändring som görs i Weblate registreras i VCS under översättarens namn. På så sätt har varje enskild ändring rätt upphovsman, och du kan spåra den med hjälp av de vanliga VCS-verktyg som du använder för kod.
Dessutom, när översättningsfilformatet stöder det, uppdateras filrubrikerna så att de inkluderar översättarens namn.
Varför tvingar Weblate fram visning av alla PO-filer i ett enda träd?¶
Weblate har utformats så att varje PO-fil representeras som en enskild komponent. Detta är fördelaktigt för översättare, eftersom de då vet vad de faktiskt översätter.
Förändrat i version 4.2: Översättare kan översätta alla delar av ett projekt till ett specifikt språk som en helhet.
Varför använder Weblate språkkoder som sr_Latn eller zh_Hant?¶
Dessa är språkkoder som definieras av RFC 5646 för att bättre ange att det verkligen är olika språk istället för tidigare felaktigt använda modifierare (för @latin-varianter) eller landskoder (för kinesiska).
Weblate förstår fortfarande äldre språkkoder och kommer att mappa dem till aktuella koder – till exempel kommer sr@latin att hanteras som sr_Latn och zh@CN som zh_Hans.
Observera
Weblate använder som standard språkkoder i POSIX-stil med understreck, se Språkliga definitioner för mer information.