Valfria Weblate-moduler¶

Flera valfria moduler finns tillgängliga för din installation.

Git-exportör¶

Ger dig läsbehörighet till det underliggande Git-arkivet via HTTP(S).

Installation¶

Lägg till weblate.gitexport till installerade appar i settings.py:
```
INSTALLED_APPS += ("weblate.gitexport",)
```
Exportera befintliga arkiv genom att migrera din databas efter installationen:
```
weblate migrate
```

Råd

Git-exportören är aktiverad i vår officiella Docker-bild. För att inaktivera den, använd:

WEBLATE_REMOVE_APPS=weblate.gitexport

Användning¶

Modulen kopplas automatiskt till Weblate och ställer in den exporterade repositoriets URL i Komponentkonfiguration. Repositorierna är tillgängliga under /git/-delen av Weblate-URL:en, till exempel https://example.org/git/weblate/main/.

Repositorier för offentligt tillgängliga projekt kan klonas utan autentisering:

git clone 'https://example.org/git/weblate/main/'

För att kunna bläddra i arkiven med begränsad åtkomst (med Private åtkomstkontroll eller när REQUIRE_LOGIN är aktiverat) krävs en API-token som kan erhållas i din användarprofil:

git clone 'https://user:KEY@example.org/git/weblate/main/'

Råd

Som standard har medlemmar eller Användare-gruppen och anonyma användare åtkomst till arkiven för offentliga projekt via Åtkomst till arkiv och Power user-roller.

Fakturering¶

Detta används på Hosted Weblate för att definiera faktureringsplaner, spåra fakturor och användningsgränser.

Installation¶

1. Add weblate.billing to installed apps in settings.py:

INSTALLED_APPS += ("weblate.billing",)

Kör databasmigreringen för att eventuellt installera ytterligare databasstrukturer för modulen:

weblate migrate

Skapande och tilldelning av faktureringsplaner¶

Du måste först skapa en faktureringsplan för att aktivera fakturering. Gå till avsnittet Administration (representerat av skiftnyckelikonen) och öppna skärmen Verktyg. Därifrån går du vidare till Django-admingränssnittet.

I Djangos administratörsgränssnitt letar du upp avsnittet BILLING och lägger till en faktureringsplan. Du kan till exempel lägga till en Free-plan utan kostnad.

Om du vill tilldela en faktureringsplan till ett befintligt projekt kan detta också göras i Django-admin-gränssnittet med hjälp av alternativet Kundfakturering.

Slutligen erbjuder Django admin interface ett alternativ för Invoice (faktura) där du kan logga dina kunders betalningar.

Användning¶

Efter installationen kan du styra faktureringen i administratörsgränssnittet. Användare med aktiverad fakturering får en ny flik Fakturering i sin Användarprofil.

Faktureringsmodulen gör det dessutom möjligt för projektadministratörer att skapa nya projekt och komponenter utan att vara superanvändare (se Lägga till översättningsprojekt och komponenter). Detta är möjligt när följande villkor är uppfyllda:

Faktureringen ligger inom de konfigurerade gränserna (överskridande resulterar i blockering av projekt-/komponentskapande) och är betald (om priset är större än noll)
Användaren är administratör för ett befintligt projekt med fakturering eller användaren är ägare av faktureringen (det senare är nödvändigt när man skapar ny fakturering för att användare ska kunna importera nya projekt).

När projektet skapas kan användaren välja vilken fakturering som ska debiteras för projektet om han har tillgång till flera av dem.

Juridisk modul¶

Detta används på Hosted Weblate för att tillhandahålla nödvändiga juridiska dokument. Det levereras med tomma dokument, och du förväntas fylla i följande mallar i dokumenten:

legal/documents/tos.html: Användarvillkor
legal/documents/privacy.html: Dokument om integritetspolicy
legal/documents/summary.html: Kort översikt över användarvillkoren och integritetspolicyn

Vid ändring av användarvillkoren, justera LEGAL_TOS_DATE så att användarna tvingas godkänna de uppdaterade villkoren.

Observera

Juridiska dokument för tjänsten Hosted Weblate finns tillgängliga i detta Git-arkiv <https://github.com/WeblateOrg/wllegal/tree/main/wllegal/templates/legal/documents>.

Dessa kommer troligen inte att vara direkt användbara för dig, men kan vara till hjälp som utgångspunkt om de anpassas efter dina behov.

Installation¶

1. Add weblate.legal to installed apps in settings.py:

INSTALLED_APPS += ("weblate.legal",)

# Optional:

# Social auth pipeline to confirm TOS upon registration/subsequent sign in
SOCIAL_AUTH_PIPELINE += ("weblate.legal.pipeline.tos_confirm",)

# Middleware to enforce TOS confirmation of signed in users
MIDDLEWARE += [
    "weblate.legal.middleware.RequireTOSMiddleware",
]

Kör databasmigreringen för att eventuellt installera ytterligare databasstrukturer för modulen:

weblate migrate

Redigera de juridiska dokumenten i mappen weblate/legal/templates/legal/ så att de passar din tjänst.

Användning¶

Efter installation och redigering visas de juridiska dokumenten i Weblate-gränssnittet.

Avatarer¶

Avatarer laddas ner och cachelagras på serversidan för att minska informationsläckor till de webbplatser som serverar dem som standard. Det inbyggda stödet för att hämta avatarer från e-postadresser som konfigurerats för detta kan stängas av med ENABLE_AVATARS.

Weblate stöder för närvarande:

Se även

Signera Git-commits med GnuPG¶

Alla commit kan signeras med GnuPG-nyckeln för Weblate-instansen.

Aktivera WEBLATE_GPG_IDENTITY. (Weblate genererar en GnuPG-nyckel när det behövs och använder den för att signera alla översättningskommandon.)

Denna funktion kräver att GnuPG 2.1 eller senare är installerat.

Du hittar nyckeln i DATA_DIR och den offentliga nyckeln visas på sidan ”Om”:
Alternativt kan du också importera befintliga nycklar till Weblate, ställ bara in HOME=$DATA_DIR/home när du anropar gpg.

Råd

Nyckelmaterialet cachelagras av Weblate under en lång period. Om du låter Weblate generera en nyckel med WEBLATE_GPG_IDENTITY och sedan importerar nyckeln med samma identitet för att använda en befintlig nyckel, rekommenderas det att rensa redis-cachen för att se effekten av en sådan ändring.

Observera

När du delar DATA_DIR mellan flera värdar, följ instruktionerna på https://wiki.gnupg.org/NFS för att GnuPG-signering ska fungera tillförlitligt.

Se även

WEBLATE_GPG_IDENTITY

Hastighetsbegränsande¶

Förändrat i version 4.6: Hastighetsbegränsningen gäller inte längre för inloggade superanvändare.

Flera operationer i Weblate är hastighetsbegränsade. Högst RATELIMIT_ATTEMPTS försök är tillåtna inom RATELIMIT_WINDOW sekunder. Användaren blockeras sedan i RATELIMIT_LOCKOUT. Det finns också inställningar som är specifika för olika områden, till exempel RATELIMIT_CONTACT_ATTEMPTS eller RATELIMIT_TRANSLATE_ATTEMPTS. Tabellen nedan är en fullständig lista över tillgängliga områden.

Följande operationer är föremål för hastighetsbegränsning:

Namn	Omfattning	Tillåtna försök	Ratelimit-fönster	Låsningsperiod
Registrering	`REGISTRATION`	5	300	600
Skicka meddelande till administratörer	`MESSAGE`	2	300	600
Lösenordsautentisering vid inloggning	`LOGIN`	5	300	600
Tvåfaktorsautentisering	`SECOND_FACTOR`	5	300	600
Sök på hela webbplatsen	`SEARCH`	6	60	60
Översättning	`TRANSLATE`	30	60	600
Lägg till i ordlista	`GLOSSARY`	30	60	600
Börja översättningen till ett nytt språk	`LANGUAGE`	2	300	600
Skapa nytt projekt	`PROJECT`	5	600	600

Hastighetsbegränsningen baseras på sessioner när användaren är inloggad och på IP-adressen om så inte är fallet.

Om en användare misslyckas med att logga in AUTH_LOCK_ATTEMPTS gånger, kommer lösenordsautentiseringen att stängas av på kontot tills lösenordet har återställts.

Inställningarna kan också tillämpas i Docker-containern genom att lägga till prefixet WEBLATE_ till inställningsnamnet, till exempel RATELIMIT_ATTEMPTS blir WEBLATE_RATELIMIT_ATTEMPTS.

API:et har separata inställningar för hastighetsbegränsning, se API-hastighetsbegränsning.

Se även