İsteğe bağlı Weblate modülleri

Kurulumunuz için isteğe bağlı çeşitli modüller vardır.

Git dışa aktarıcı

HTTP(S) kullanarak temel alınan Git deposuna salt okunur erişim sağlar.

Kurulum

  1. settings.py dosyasındaki kurulu uygulamalara weblate.gitexport ekleyin:

    INSTALLED_APPS += ("weblate.gitexport",)

  2. Kurulumdan sonra veri tabanınızı aktararak var olan depoları dışa aktarın:

    weblate migrate

İpucu

Git dışa aktarıcısı resmi Docker kalıbımızda açıktır. Kapatmak için şu komutu kullanın:

WEBLATE_REMOVE_APPS=weblate.gitexport

Kullanım

Modül kendiliğinden Weblate bağlantısı kurar ve Bileşen yapılandırması içinde dışa aktarılan depo adresini ayarlar. Depolara Weblate adresinin /git/ bölümünden erişilebilir. Örneğin https://site.org/git/weblate/main/.

Herkese açık projelerin depoları kimlik doğrulaması olmadan kopyalanabilir:

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

Sınırlanmış erişimi olan depolara göz atmak için erişim (Gizli erişim denetimi ile ya da REQUIRE_LOGIN seçeneği kullanıma alınarak), kullanıcı profilinizden alabileceğiniz bir API kodu ile sağlanır:

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

Not

Weblate, Git deposunun kendisine hizmet eder, ancak Git LFS nesnelerine hizmet etmez. Git LFS kullanan depolar için, yukarı akış deposundan çoğaltın ve başka bir uzak hizmet olarak Weblate ekleyin. Yalnızca Git ile izlenen dosyalara gerek duyuyorsanız, Git LFS nesnelerini indirmeyi atlamak için Weblate üzerinde GIT_LFS_SKIP_SMUDGE=1 ile çoğaltabilirsiniz.

İpucu

Varsayılan olarak, üyeler veya Kullanıcılar grubu ve anonim kullanıcı, herkese açık projeler için depolara Depo erişimi ve Uzman kullanıcı rolleri ile erişebilir.

Faturalama

Bu seçenek, faturalama tarifelerini tanımlamak, faturaları ve kullanım sınırlarını izlemek için Hosted Weblate üzerinde kullanılır.

Kurulum

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

INSTALLED_APPS += ("weblate.billing",)

  1. İsteğe bağlı olarak modül için ek veri tabanı yapıları kurmak üzere veri tabanı aktarımını çalıştırın:

weblate migrate

Fatura tarifesi oluşturmak ve atamak

Faturalamayı kullanmak için öncelikle bir faturalama tarifesi oluşturmanız gerekir. Yönetim bölümüne gidin (somun anahtarı simgesiyle gösterilir) ve Araçlar sayfasını açın. Oradan Django yönetim arayüzü bölümüne geçin.

Django yönetim arayüzünde, FATURALAMA bölümünü bulun ve bir faturalama tarifesi ekleyin. Örneğin, herhangi bir maliyeti olmayan bir Ücretsiz tarife ekleyebilirsiniz.

Var olan bir projeye faturalama tarifesi atamak isterseniz, bunu Django yönetim arayüzü içinden Müşteri faturaları seçeneğini kullanarak da yapabilirsiniz.

Son olarak, Django yönetim arayüzü müşteri ödemelerinizi kaydetmek için bir Fatura seçeneği sunar.

Kullanım

Kurulumdan sonra faturalamayı yönetici arayüzünden yönetebilirsiniz. Faturalamanın kullanıma alındığı kullanıcılara Kullanıcı profili içinde Faturalama sekmesi görüntülenir.

Faturalama modülü ayrıca proje yöneticilerinin süper kullanıcı olmadan yeni projeler ve bileşenler oluşturmasını sağlar (ayrıntılı bilgi almak için: Çeviri projelerini ve bileşenleri eklemek). Bunun için şu koşullar yerine getirilmelidir:

  • Faturalama yapılandırılmış sınırlar içindedir (aşırı kullanım, proje/bileşen oluşturulmasını engeller) ve ödenmiştir (fiyatı sıfır değilse)

  • Kullanıcı, faturalama ile var olan projenin yöneticisidir ya da kullanıcı faturalamanın sahibidir (ikincisi, kullanıcıların yeni projeleri içe aktarabilmesi için yeni faturalama oluştururken gereklidir).

Proje oluşturulduktan sonra kullanıcı, daha fazla özelliğe erişebilmesi durumunda proje için hangi fatura ücretlendirmesinin uygulanacağını seçebilir.

Avatarlar

Avatarlar, varsayılan olarak hizmet verdikleri sitelerden bilgi sızıntılarını azaltmak için sunucu tarafına indirilir ve ön belleğe alınır. Bunun için yapılandırılmış e-posta adreslerinden avatarları almayı sağlama özelliği ENABLE_AVATARS seçeneği ile kullanımdan kaldırılabilir.

Weblate şu anda şunları destekliyor:

Ayrıca bakınız

Yerelleştirme CDN

The JavaScript yerelleştirme 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;
    }
}

Ayrıca bakınız

Git işlemelerini GnuPG ile imzalamak

Tüm işlemeler Weblate kopyasının GnuPG anahtarı tarafından imzalanabilir.

  • WEBLATE_GPG_IDENTITY ayarını açın. (Weblate, gerektiğinde bir GnuPG anahtarı oluşturur ve bunu tüm çeviri işlemelerini imzalamak için kullanır.)

    Bu özellik için GnuPG 2.1 ya da üzerindeki bir sürüm kurulu olmalıdır.

    Anahtarı DATA_DIR içinde bulabilirsiniz. Herkese açık anahtar “Hakkında” sayfasında görüntülenir:

    ../_images/about-gpg.webp

  • Alternatif olarak, var olan anahtarları Weblate içine de aktarabilirsiniz. gpg çağırırken HOME = $DATA_DIR/home ayarını yapmanız yeterlidir.

İpucu

Weblate anahtar materyalini uzun süreyle ön belleğe alır. WEBLATE_GPG_IDENTITY seçeneği ile Weblate tarafından bir anahtar oluşturmasına izin veriyorsanız ve var olan bir anahtarı kullanmak için aynı kimlikli anahtarı Weblate içine aktarırsanız, bu tür bir değişikliğin etkisini görmek için redis ön belleğini temizlemeniz önerilir.

Not

Birkaç sunucu arasında DATA_DIR paylaşırken, GnuPG imzalamasının düzgün çalışabilmesi için lütfen https://wiki.gnupg.org/NFS adresindeki yönergeyi izleyin.

Ayrıca bakınız

WEBLATE_GPG_IDENTITY

Hızı sınırlaması

4.6 sürümünde değişti: Artık oturum açmış süper kullanıcılara hız sınırlaması uygulanmıyor.

Weblate üzerinde bazı işlemlere hız sınırlaması uygulanır. RATELIMIT_WINDOW saniye içinde en fazla RATELIMIT_ATTEMPTS girişim yapılmasına izin verilir. Kullanıcı daha sonra RATELIMIT_LOCKOUT süreyle engellenir. Kapsamlara özgü ayarlar da vardır. Örneğin RATELIMIT_CONTACT_ATTEMPTS ya da RATELIMIT_TRANSLATE_ATTEMPTS. Aşağıdaki tabloda, kullanılabilecek kapsamların tam listesini görebilirsiniz.

Hız sınırlaması uygulanan işlemler şunlardır:

Ad

Kapsam

İzin verilen girişimler

Hız sınırlaması aralığı

Kilitleme süresi

Hesap açılışı

REGISTRATION

5

300

600

Yöneticilere ileti göndermek

MESSAGE

2

300

600

Oturum açarken parola kimlik doğrulaması

LOGIN

5

300

600

İki adımlı doğrulama

SECOND_FACTOR

5

300

600

Site genelinde arama

SEARCH

6

60

60

Çevriliyor

TRANSLATE

30

60

600

Sözlüğe ekleme

GLOSSARY

30

60

600

Yeni bir dil çevirisi başlatma

LANGUAGE

2

300

600

Yeni proje oluşturma

PROJECT

5

600

600

Hız sınırlaması, kullanıcı oturum açmışsa oturuma, açmamışsa IP adresine göre yapılır.

Bir kullanıcı AUTH_LOCK_ATTEMPTS kez oturum açamazsa, parola sıfırlama işlemini yapana kadar hesabın parola kimlik doğrulaması kapatılır.

Ayarlar, seçenek adına WEBLATE_ ön eki eklenerek Docker kapsayıcısına da uygulanabilir. Örneğin RATELIMIT_ATTEMPTS seçeneği WEBLATE_RATELIMIT_ATTEMPTS olur.

API için ayrı hız sınırlama ayarları vardır. Ayrıntılı bilgi almak için: API hız sınırlaması.

Ayrıca bakınız