Versiebeheerintegratie¶
Weblate ondersteunt momenteel Git (met uitgebreide ondersteuning voor GitHub pull requests, GitLab verzoeken voor samenvoegen, Gitea pull requests, Gerrit, Subversion, Bitbucket Cloud pull requests, Pull requesten op Bitbucket Data Center en Azure DevOps pull requests) en Mercurial als versiebeheer backends.
Toegang tot opslagruimten¶
De opslagruimte van het VCS dat u wilt gebruiken moet toegankelijk zijn vanuit Weblate. Met een publiek beschikbare opslagruimte hoeft u slechts de juiste URL in te voeren (bijvoorbeeld https://github.com/WeblateOrg/weblate.git), maar voor privé opslagruimten of voor URL’s voor pushen is het instellen meer complex en vereist authenticatie.
Toegang tot opslagruimten vanuit Hosted Weblate¶
Voor Hosted Weblate is er een toegewezen gebruiker voor pushen op GitHub, Bitbucket, Codeberg en GitLab (met de gebruikersnaam weblate, e-mail hosted@weblate.org en een naam of beschrijving van een profiel Weblate push user).
Hint
Er mogen meer gebruikers van Weblate op de platforms zijn, toegewezen voor andere instanties van Weblate. Zoeken op e-mail hosted@weblate.org wordt aanbevolen om de juiste gebruiker voor Hosted Weblate te zoeken.
U moet deze gebruiker toevoegen als een deelnemer en de toepasselijke rechten geven voor uw opslagruimte (read-only is oké voor klonen, write is vereist voor pushen). Afhankelijk van de service, en de instellingen van uw organisatie, gebeurt dit onmiddellijk of vereist het bevestiging van de kant van Weblate.
De gebruiker weblate op GitHub accepteert invitaties automatisch binnen vijf minuten. Handmatige verwerking zou voor andere services nodig kunnen zijn, wees dus geduldig.
Als de gebruiker weblate eenmaal is toegevoegd aan uw opslagruimte, kunt u Broncode-opslagruimte en URL voor pushen naar de opslagruimte configureren met het protocol SSH (bijvoorbeeld git@github.com:WeblateOrg/weblate.git).
Toegang tot opslagruimten van sites voor het hosten van code (GitHub, GitLab, Bitbucket, Azure DevOps, …)¶
Toegang tot opslagruimten van sites voor het hosten van code wordt gewoonlijk gedaan door een aangewezen gebruiker te maken die wordt geassocieerd met een Weblate SSH-sleutel (bekijk Weblate SSH-sleutel). Op deze manier associeert u de Weblate SSH-sleutel aan een enkele gebruiker (platforms dwingen vaak het eenmalig gebruik van een SSH-sleutel af) en geeft deze gebruiker toegang tot de opslagruimte. U kunt dan de URL van SSH gebruiken voor toegang tot de opslagruimte (bekijk SSH-opslagruimten).
Hint
Op een Hosted Weblate is dit vooraf al geconfigureerd voor de meeste publieke sites, bekijk Toegang tot opslagruimten vanuit Hosted Weblate.
SSH-opslagruimten¶
De meest frequent gebruikte methode voor toegang tot privé opslagruimten is gebaseerd op SSH. Autoriseer de publieke Weblate SSH-sleutel (bekijk Weblate SSH-sleutel) om op deze manier toegang te krijgen tot de opslagruimte upstream.
Waarschuwing
Op GitHub kan elke sleutel maar een keer gebruikt worden, bekijk Opslagruimten van GitHub en Toegang tot opslagruimten vanuit Hosted Weblate.
Weblate slaat ook de vingerafdruk voor d esleutel van de host op bij de eerste verbinding en laat de verbinding met de host mislukken als die later wordt gewijzigd (bekijk Verifiëren van sleutels voor SSH-host).
In het geval er aanpassingen moeten worden gedaan, doe dat dan vanuit de beheerinterface van Weblate:
Weblate SSH-sleutel¶
Veranderd in versie 4.17: Weblate genereert nu zowel SSH-sleutels van RSA als van Ed25519. Gebruiken van Ed25519 wordt aanbevolen voor nieuwe opstellingen.
De publieke sleutel van Weblate is zichtbaar voor alle gebruikers die bladeren door de pagina Over Weblate.
Beheerders kunnen de momenteel door Weblate gebruikte publieke sleutel genereren of weergeven in de verbinding (vanuit SSH keys) op de startpagina van de beheerinterface.
Notitie
De corresponderende private SSH-sleutel kan momenteel geen wachtwoord hebben, zorg er dus voor dat die goed beveiligd is.
Hint
Maak een back-up van de gegenereerde private SSH-sleutel van Weblate.
Verifiëren van sleutels voor SSH-host¶
Weblate slaat automatisch de sleutels voor SSH-host op bij de eerste toegang en onthoud die voor later gebruik.
In het geval dat u de vingerafdruk van de sleutel wilt verifiëren voordat u verbindt met de opslagruimte, voeg de sleutels voor de SSH-host van de servers, waartoe u toegang wilt, toe in Host sleutel toevoegen, in hetzelfde gedeelte van de beheerinterface. Voer de hostnaam in waarvoor u toegang wilt (bijv. gitlab.com) en druk op Indienen. Verifieer of de vingerafdruk overeenkomt met de server die u hebt toegevoegd.
De toegevoegde sleutels met vingerafdrukken worden weergegeven het bericht met de bevestiging:
Verbinden met oude servers van SSH¶
Recente uitgaven van OpenSSH (bijvoorbeeld die welke wordt gebruikt in Weblate Docker container) schakelen standaard RSA-handtekeningen, die het hash-algoritme SHA-1 gebruiken, uit. Deze wijziging is gemaakt omdat het hash-algoritme SHA-1 cryptografisch gezien defect is en het mogelijk is om botsingen van hashes met gekozen voorvoegsel te maken voor <USD$50K.
Voor de meeste gebruikers zal deze wijziging onzichtbaar zijn en er is geen noodzaak om de sleutels SSH-RSA te vervangen. OpenSSH heeft ondersteunde handtekeningen voor RFC8332 RSA/SHA-256/512 vanaf uitgave 7.2 en bestaande sleutels SSH-RSA zullen automatisch het sterkere algoritme gebruiken, indien mogelijk.
Incompatibiliteit ligt meer voor de hand bij het verbinden met oudere implementaties van SSH die niet zijn geüpgraded of niet nauwgezet de verbeteringen in het SSH-protocol hebben bijgehouden. De verbinding met SSH naar een dergelijke server zal mislukken met:
no matching host key type found. Their offer: ssh-rsa
Voor deze gevallen zou het noodzakelijk kunnen zijn om selectief RSA/SHA1 opnieuw in te schakelen om verbinding en/of authenticatie van de gebruiker via de opties HostkeyAlgorithms en PubkeyAcceptedAlgorithms mogelijk te maken. De volgende stanza in DATA_DIR/ssh/config zal,bijvoorbeeld, RSA/SHA1 inschakelen voor host en gebruikerauthenticatie voor een enkele bestemmingshost:
Host legacy-host
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
We bevelen het inschakelen van RSA/SHA1 alleen aan als een tijdelijke maatregel, totdat oude implementaties kunnen worden geüpgraded of opnieuw kunnen worden geconfigureerd met een ander type sleutel (zoals ECDSA of Ed25519).
Opslagruimten van GitHub¶
Toegang via SSH is mogelijk (bekijk SSH-opslagruimten), maar in het geval dat u toegang nodig hebt tot meer dan een opslagruimte, zult u tegen ene beperking van GitHub aanlopen met betrekking tot het toegestane gebruik van SSH-sleutels (omdat elke sleutel maar een keer mag worden gebruikt).
In het geval dat de Push-tak niet is ingesteld, wordt het project geforkt en de wijzigingen gepusht via een fork. In het geval het wel is ingesteld worden wijzigingen gepusht naar de opslagruimte upstream en de gekozen tak.
Voor kleinere uitvoeringen, gebruik authenticatie met HTTPS met een persoonlijk toegangstoken en uw account van GitHub, bekijk Creating an access token for command-line use.
Voor grotere opstellingen is het gewoonlijk beter om een aangewezen gebruiker te maken voor Weblate, daaraan de publieke SSH-sleutel dis is gegenereerd in Weblate toe te wijzen (bekijk Weblate SSH-sleutel) en die toegang te geven tot alle opslagruimten die u wilt vertalen. Deze benadering wordt ook gebruikt voor Hosted Weblate, daarvoor is de aangewezen gebruiker weblate.
Weblate interne URL’s¶
Deel een opstelling met een opslagruimte tussen verschillende onderdelen door naar zijn plaatsing te verwijzen als naar weblate://project/onderdeel in andere (gekoppelde) onderdelen. Op deze manier gekoppelde onderdelen gebruiken de configuratie van de opslagruimte van het VCS van het hoofd (verwezen) onderdeel.
Waarschuwing
Verwijderen van het hoofdonderdeel verwijdert ook gekoppelde onderdelen.
Weblate past automatisch de URL van de opslagruimte aan bij het maken van een onderdeel, als het een onderdeel vindt met een overeenkomende opstelling voor de opslagruimte. U kunt dit overschrijven in de laatste stap van de configuratie voor een onderdeel.
Redenen om dit te gebruiken:
Bespaart schijfruimte op de server, de opslagruimte wordt maar een keer opgeslagen.
Maakt bijwerken sneller, slechts een opslagruimte wordt bijgewerkt.
Er is slechts een enkele geëxporteerde opslagruimte met vertalingen van Weblate (bekijk Git exporter).
Sommige add-ons kunnen werken op meerdere onderdelen die een opslagruimte delen, bijvoorbeeld Git-commits samenvoegen.
HTTPS opslagruimten¶
Voor toegang tot beveiligde opslagruimten van HTTPS, neem de gebruikersnaam en het wachtwoord op in de URL. Geen zorgen, Weblate zal deze informatie verwijderen wanneer de URL aan gebruikers wordt weergegeven (zelfs als het toegestaan is de URL van de opslagruimte als geheel te bekijken).
Bijvoorbeeld de GitHub URL met authenticatie toegevoegd zou eruit kunnen zien als: https://user:uw_toegangs_token@github.com/WeblateOrg/weblate.git.
Veranderd in versie 5.10.2: Weblate uses proactive authentication with Git 2.46.0 and newer when HTTP credentials are supplied.
This makes it possible to access Azure DevOps repositories and makes access to authenticated repositories faster.
Notitie
Als uw gebruikersnaam of wachtwoord speciale tekens bevat, moeten die als URL worden gecodeerd, bijvoorbeeld https://gebruiker%40example.com:%24wachtwoord%23@bitbucket.org/….
Proxy gebruiken¶
Als u toegang nodig hebt tot opslagruimten van het VCS met HTTP/HTTPS die een proxyserver gebruiken, configureer dan het VCS om het te gebruiken.
Dat kan worden gedaan met de omgevingsvariabelen http_proxy, https_proxy en all_proxy, (zoals beschreven in de cURL documentation) of door het af te dwingen in de configuratie van het VCS, bijvoorbeeld:
git config --global http.proxy http://user:password@proxy.example.com:80
Notitie
De configuratie van de proxy moet worden gedaan door de gebruiker waaronder Weblate wordt uitgevoerd (bekijk ook Rechten voor bestandssysteem) en met HOME=$DATA_DIR/home (bekijk DATA_DIR), anders zal Git, dat wordt uitgevoerd met Weblate, het niet gebruiken.
Zie ook
Git¶
Hint
Weblate heeft Git 2.28 of nieuwer nodig.
Zie ook
Bekijk Toegang tot opslagruimten voor informatie over hoe toegang te krijgen tot de verschillende soorten opslagruimten.
Git met afgedwongen push¶
Dit gedraagt zich exact hetzelfde als Git zelf, het enige verschil is dat het altijd pushen forceert. Dit is alleen bedoeld voor het geval dat een afzonderlijke opslagruimte voor de vertalingen wordt gebruikt.
Waarschuwing
Gebruik het voorzichtig, omdat het gemakkelijk leidt tot verloren gegane indieningen in uw opslagruimte upstream.
Aanpassen van de configuratie van Git¶
Weblate roept alle opdrachten voor het VCS aan met HOME=$DATA_DIR/home (bekijk DATA_DIR), daarom moet het bewerken van de gebruikerconfiguratie worden gedaan in DATA_DIR/home/.git.
Git helpers op afstand¶
U kunt ook Git remote helpers gebruiken voor aanvullende ondersteuning van andere versiebeheersystemen, maar wees voorbereid om problemen te debuggen waar dit toe kan leiden.
Op dit moment zijn helpers voor Bazaar en Mercurial beschikbaar binnen afzonderlijke opslagruimten op GitHub: git-remote-hg en git-remote-bzr. Download ze handmatig en plaats ze ergens in uw zoekpad (bijvoorbeeld ~/bin). Zorg ervoor dat u het corresponderende versiebeheersystemen hebt geïnstalleerd.
Als u deze eenmaal hebt geïnstalleerd, kunnen dergelijk helpers op afstand worden gebruikt om een opslagruimte in Weblate te specificeren.
Het project gnuhello klonen vanaf Launchpad met Bazaar:
bzr::lp:gnuhello
Voor de opslagruimte hello uit selenic.com met Mercurial:
hg::https://selenic.com/repo/hello
Waarschuwing
Het ongemakkelijke van het gebruiken van helpers op afstand met Git is bijvoorbeeld met Mercurial, de helper op afstand maakt soms een nieuwe tip bij het terugpushen van wijzigingen.
GitHub pull requests¶
Dit voegt een dunne laag toe bovenop Git met de GitHub API om het pushen van wijzigingen in de vertalingen als pull requests mogelijk te maken, in plaats van ze direct naar de opslagruimte te pushen.
Git pusht wijzigingen direct naar een opslagruimte, terwijl GitHub pull requests pull requests maakt. Het laatste is niet nodig om puur toegang te krijgen tot opslagruimten van Git.
U moet inloggegevens voor de API configureren (GITHUB_CREDENTIALS) in de instellingen van Weblate om dit te laten werken. Eenmaal geconfigureerd, zult u een optie GitHub zien bij het selecteren van Versiebeheersysteem.
GitLab verzoeken voor samenvoegen¶
Dit voegt een dunne laag toe bovenop Git met de GitLab API om het pushen van wijzigingen in vertalingen als merge requests mogelijk te maken, in plaats van ze direct naar de opslagruimte te pushen.
Er is geen noodzaak om dit te gebruiken voor toegang tot opslagruimten van Git, gewoonlijk werkt Git hetzelfde, het enige verschil is hoe het pushen naar een opslagruimte wordt afgehandeld. Met Git worden wijzigingen direct naar de opslagruimte gepusht, terwijl GitLab verzoeken voor samenvoegen een merge request maakt.
U moet inloggegevens voor de API configureren (GITLAB_CREDENTIALS) in de instellingen van Weblate om dit te laten werken. Eenmaal geconfigureerd, zult u een optie GitLab zien bij het selecteren van Versiebeheersysteem.
Gitea pull requests¶
Added in version 4.12.
Dit voegt eenvoudigweg een dunne laag toe bovenop Git met behulp van de Gitea API om wijzigingen in vertalingen als pull requests te kunnen pushen, in plaats van ze direct naar de opslagruimte te pushen.
Het is niet nodig om dit te gebruiken voor toegang tot opslagruimten van Git, gewoonlijk werkt Git hetzelfde, het enige verschil is hoe het pushen naar een opslagruimte wordt afgehandeld. Met Git worden wijzigingen direct naar de opslagruimte gepusht, terwijl Gitea pull requests pull requests maakt.
U moet inloggegevens voor de API configureren (GITEA_CREDENTIALS) in de instellingen van Weblate om dit te laten werken. Zodra dit is geconfigureerd, ziet u een optie Gitea bij het selecteren van Versiebeheersysteem.
Pull requesten op Bitbucket Data Center¶
Added in version 4.16.
Dit voegt eenvoudigweg een dunne laag toe bovenop Git die de Bitbucket Data Center API gebruikt om wijzigingen in vertalingen als pull requesten te pushen, in plaats van ze direct naar de opslagruimte te pushen.
Waarschuwing
Dit ondersteunt niet Bitbucket Cloud API.
Er is geen noodzaak om dit te gebruiken om toegang te krijgen tot opslagruimten van Git, gewoonlijk werkt Git hetzelfde, het enige verschil is hoe het pushen naar een opslagruimte wordt afgehandeld. Met Git worden wijzigingen rechtstreeks naar de opslagruimte gepusht, terwijl Pull requesten op Bitbucket Data Center een pull request maakt.
U moet inloggegevens voor de API configureren (BITBUCKETSERVER_CREDENTIALS) in de instellingen van Weblate om dit te laten werken. Zodra dit is geconfigureerd, ziet u een optie Bitbucket Data Center bij het selecteren van Versiebeheersysteem.
Bitbucket Cloud pull requests¶
Added in version 5.8.
Dit voegt eenvoudigweg een dunne laag toe bovenop Git met behulp van de Bitbucket Cloud API om wijzigingen in vertalingen als pull requests te kunnen pushen, in plaats van ze direct naar de opslagruimte te pushen.
Waarschuwing
Dit is anders dan in de Bitbucket data Center API.
Het is niet nodig om dit te gebruiken voor toegang tot opslagruimten van Git, gewoonlijk werkt Git hetzelfde, het enige verschil is hoe het pushen naar een opslagruimte wordt afgehandeld. Met Git worden wijzigingen direct naar de opslagruimte gepusht, terwijl Bitbucket Cloud pull requests pull requests maakt.
U moet inloggegevens voor de API configureren (BITBUCKETCLOUD_CREDENTIALS) in de instellingen van Weblate om dit te laten werken. Zodra dit is geconfigureerd, ziet u een optie Bitbucket Cloud bij het selecteren van Versiebeheersysteem.
Pagure verzoeken voor samenvoegen¶
Added in version 4.3.2.
Dit voegt eenvoudigweg een dunne laag toe bovenop Git die de Pagure API gebruikt om wijzigingen in vertalingen als merge requests te pushen, in plaats van ze direct naar de opslagruimte te pushen.
Er is geen noodzaak om dit te gebruiken om toegang te krijgen tot opslagruimten van Git, gewoonlijk werkt Git hetzelfde, het enige verschil is hoe het pushen naar een opslagruimte wordt afgehandeld. Met Git worden wijzigingen rechtstreeks naar de opslagruimte gepusht, terwijl Pagure verzoeken voor samenvoegen een merge request maakt.
U moet inloggegevens voor de API configureren (PAGURE_CREDENTIALS) in de instellingen van Weblate om dit te laten werken. Zodra dit is geconfigureerd, ziet u een optie Pagure bij het selecteren van Versiebeheersysteem.
Gerrit¶
Dit voegt eenvoudigweg een dunne laag toe bovenop Git die het programma git-review gebruikt om wijzigingen in vertalingen als Gerrit review requests te pushen, in plaats van ze direct naar de opslagruimte te pushen.
De documentatie van Gerrit heeft de details voor de noodzakelijke configuratie om dergelijke opslagruimten op te stellen.
Azure DevOps pull requests¶
Dit voegt eenvoudigweg een dunne laag toe bovenop Git die de Azure DevOps API gebruikt om wijzigingen in vertalingen als pull requests te pushen, in plaats van ze direct naar de opslagruimte te pushen.
Git pusht wijzigingen direct naar een opslagruimte, terwijl Azure DevOps pull requests pull requests maakt. Het laatste is niet nodig om alleen toegang te krijgen tot opslagruimten van Git.
U moet inloggegevens voor de API configureren (AZURE_DEVOPS_CREDENTIALS) in de instellingen van Weblate om dit te laten werken. Zodra dit is geconfigureerd, ziet u een optie Azure DevOps bij het selecteren van Versiebeheersysteem.
Mercurial¶
Mercurial is een ander VCS dat u direct in Weblate kunt gebruiken.
Notitie
Het zou moeten werken met elke versie van Mercurial, maar er zijn soms incompatibele wijzigingen in de interface voor de opdrachtregel die integratie met Weblate verbreekt.
Zie ook
Bekijk Toegang tot opslagruimten voor informatie over hoe toegang te krijgen tot de verschillende soorten opslagruimten.
Subversion¶
Weblate gebruikt git-svn voor interactie met opslagruimten van subversion. Het is een Perl-script dat Subversion in staat stelt te worden gebruikt door een cliënt van Git, wat gebruikers in staat stelt een volledige kloon van de interne opslagruimte te onderhouden en lokaal in te dienen.
Notitie
Weblate probeert automatisch de lay-out van de opslagruimte van Subversion te detecteren - het ondersteunt zowel directe URL’s voor tak of opslagruimten met standaard lay-out (takken/, tags/ en trunk/). Meer informatie hierover is te vinden in de git-svn documentatie. Als uw opslagruimte geen standaard lay-out heeft en u fouten tegenkomt, probeer dan de naam van de tak op te nemen in de URL van de opslagruimte en laat de tak leeg.
Inloggegevens Subversion¶
Weblate verwacht dat u van tevoren het certificaat hebt geaccepteerd (en uw inloggegevens indien nodig). Het zal zoeken om ze in te voegen in de map DATA_DIR. Accepteer het certificaat door svn eenmaal te gebruiken met de omgevingsvariabele $HOME ingesteld op de DATA_DIR:
# Use DATA_DIR as configured in Weblate settings.py, it is /app/data in the Docker
HOME=${DATA_DIR}/home svn co https://svn.example.com/example
Zie ook
Lokale bestanden¶
Hint
Daaronder gebruikt dit Git. Het vereist dat Git is geïnstalleerd en stelt u in staat om over te schakelen naar Git zelf met de volledige geschiedenis van uw vertalingen.
Weblate kan ook werken zonder een VCS op afstand. De initiële vertalingen worden geïmporteerd door ze te uploaden. Later kunt u individuele bestanden vervangen door een bestand te uploaden, of tekenreeksen van vertalingen direct toe te voegen vanuit Weblate (momenteel alleen beschikbaar voor eentalige vertalingen).
Op de achtergrond maakt Weblate een opslagruimte voor Git voor u en alle wijzigingen worden daarin bijgehouden. In het geval dat u later bepaalt om een VCS te gebruiken om de vertalingen op te slaan, heeft u al een opslagruimte in Weblate waarop u uw integratie kunt baseren.