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

  1. Lägg till weblate.gitexport till installerade appar i settings.py:

    INSTALLED_APPS += ("weblate.gitexport",)
    
  2. 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/'

Observera

Weblate serves the Git repository itself, but it does not serve Git LFS objects. For repositories using Git LFS, clone from the upstream repository and add Weblate as another remote. If you only need Git-tracked files, you can clone from Weblate with GIT_LFS_SKIP_SMUDGE=1 to skip downloading Git LFS objects.

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",)
  1. 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.

The billing module additionally allows users to create new projects and components without being superusers (see Lägga till översättningsprojekt och komponenter). This is possible when following conditions are met:

  • Faktureringen ligger inom de konfigurerade gränserna (överskridande resulterar i blockering av projekt-/komponentskapande) och är betald (om priset är större än noll)

  • The user has Add projects to workspace permission for the workspace covered by the billing plan.

Upon project creation user is able to choose which workspace should contain the project. Projects created in a workspace with billing count against the billing plan assigned to that workspace. Users with the Edit workspace settings permission can view and pay the billing plan; billing notification e-mails are sent to these users. See Fakturering for details.

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:

Lokalisering CDN

The JavaScript-lokalisering CDN and Translation files CDN add-ons write files to LOCALIZE_CDN_PATH; Weblate does not serve them. Configure the web server or CDN serving LOCALIZE_CDN_URL as a public, read-only static file host.

Treat every published CDN file as public. The add-on specific UUID in the URL is not an access-control mechanism. Do not enable CDN add-ons for components that contain private strings, unreleased product text, customer data, internal URLs, API examples, repository paths, translator comments, or file-format metadata that should not be exposed.

The Translation files CDN add-on publishes raw translation files in formats supported by Weblate. Some formats can be interpreted by browsers or other clients as HTML, SVG, XML, JavaScript, YAML, or application-specific configuration. Serve the CDN from a dedicated domain that is separate from Weblate and from the application consuming the translations. Do not share authentication cookies with the CDN domain.

Recommended server configuration:

  • Serve only the directory configured by LOCALIZE_CDN_PATH; do not expose Weblate repositories, backups, media, configuration, or the whole data directory.

  • Disable directory listing.

  • Use HTTPS and make the CDN host read-only from the web server.

  • Send X-Content-Type-Options with nosniff.

  • Configure conservative MIME types. Serve unknown translation formats as text/plain or application/octet-stream; only serve weblate.js as JavaScript.

  • For raw translation formats that are not intended to be rendered in a browser, consider adding Content-Disposition with attachment.

  • Configure Access-Control-Allow-Origin only for sites that need browser access to the files.

  • Set cache lifetimes that match your update expectations, and purge CDN caches when stale translations must disappear quickly.

The following nginx snippet serves only the configured CDN directory and applies conservative defaults for raw translation files:

weblate/examples/weblate.nginx.cdn.conf
#
# nginx configuration for the Weblate localization CDN
#
# You will want to change:
#
# - server_name to match the host configured in LOCALIZE_CDN_URL
# - root to match LOCALIZE_CDN_PATH
# - Access-Control-Allow-Origin to the sites that need browser access
# - TLS configuration if HTTPS is not terminated before nginx
#
server {
    listen 80;
    server_name cdn.example.com;

    # LOCALIZE_CDN_PATH
    root /home/weblate/data/l10n-cdn;

    autoindex off;
    disable_symlinks on;

    location = / {
        return 404;
    }

    # The JavaScript localization add-on publishes this loader.
    location ~ "^/[0-9a-f]{32}/weblate\.js$" {
        try_files $uri =404;

        types {
            application/javascript js;
        }
        default_type application/javascript;

        add_header X-Content-Type-Options nosniff always;
        # add_header Access-Control-Allow-Origin "https://www.example.com" always;

        expires 1h;
    }

    # Other CDN files are translation files. Serve them conservatively so raw
    # formats are not interpreted as active browser content.
    location / {
        try_files $uri =404;

        types {
        }
        default_type text/plain;

        add_header X-Content-Type-Options nosniff always;
        add_header Content-Disposition "attachment" always;
        # add_header Access-Control-Allow-Origin "https://www.example.com" always;

        expires 1h;
    }
}

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

    ../_images/about-gpg.webp
  • 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.

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.