Yapılandırma yönergeleri

Weblate kurulumu

Kurulumunuza ve deneyiminize bağlı olarak, size en uygun kurulum yöntemi seçin:

Üretim kurulumları için önerilen Docker ile kurmak.
Üretim kurulumları için önerilen virtualenv kurulumu:
Kaynaklardan kurulum, geliştirme çalışmaları için önerilir.
OpenShift üzerine kurulum
Kubernetes üzerine kurulum

Yazılım gereksinimleri

İşletim sistemi

Weblate platformunun, Linux, FreeBSD ve macOS üzerinde çalıştığı biliniyor. Diğer Unix benzeri sistemlerde de büyük olasılıkla çalışacaktır.

Weblate, Windows üzerinde desteklenmez. Ancak yine de çalışabilir ve yazılım yamaları mutlulukla kabul edilir.

Diğer hizmetler

Weblate, çalışabilmek için başka hizmetleri kullanır. En azından şu hizmetlerin çalışması gerekir:

PostgreSQL veri tabanı sunucusu. Bilgi almak için: Weblate için veri tabanı kurulumu.
Ön bellek ve görev kuyruğu için Redis sunucusu. Bilgi almak için: Celery ile arka plan görevlerini kullanmak.
Giden e-postalar için kullanılacak SMTP sunucusu. Bilgi almak için: Giden e-postayı yapılandırmak.

Python bağımlılıkları

Weblate, Python ile yazılmıştır ve Python 3.6 ya da üzerindeki sürümleri destekler. Bağımlılıkları pip kullanarak ya da dağıtım paketlerinizden kurabilirsiniz. Tam listeyi requirements.txt adresinde bulabilirsiniz.

En önemli bağımlılıklar:

Django: https://www.djangoproject.com/
Celery: https://docs.celeryq.dev/
Translate Toolkit: https://toolkit.translatehouse.org/
translation-finder: https://github.com/WeblateOrg/translation-finder
Python Social Auth: https://python-social-auth.readthedocs.io/
Django REST çatısı: https://www.django-rest-framework.org/

İsteğe bağlı bağımlılıklar

Bazı Weblate özellikleri için şu modüller gereklidir. Hepsini requirements-optional.txt içinde bulabilirsiniz.

Mercurial (Mercurial depo desteği için isteğe bağlı): https://www.mercurial-scm.org/
phply (PHP dizgeleri için isteğe bağlı): https://github.com/viraptor/phply
tesserocr (Visual context for strings ile karakter tanıma için isteğe bağlı): https://github.com/sirfz/tesserocr
python-akismet (Spam protection için isteğe bağlı): https://github.com/Nekmo/python-akismet
ruamel.yaml (YAML dosyaları için isteğe bağlı): https://pypi.org/project/ruamel.yaml/
Zeep (Microsoft Terminology için isteğe bağlı): https://docs.python-zeep.org/
aeidon (Alt yazı dosyaları için isteğe bağlı): https://pypi.org/project/aeidon/
fluent.syntax (Fluent biçimi için isteğe bağlı): https://projectfluent.org/

İpucu

Pip kullanarak kurulum yapılırken istediğiniz özellikleri doğrudan belirtebilirsiniz:

pip install "Weblate[PHP,Fluent]"

Ya da tüm isteğe bağlı özelliklerle Weblate kurulumu yapabilirsiniz:

pip install "Weblate[all]"

Ya da hiç bir isteğe bağlı özellik olmadan Weblate kurulumu yapabilirsiniz:

pip install Weblate

Veri tabanı arka plan bağımlılıkları

Weblate PostgreSQL, MySQL ve MariaDB veri tabanlarını destekler. Bilgi almak için Weblate için veri tabanı kurulumu ve yönetim bölümü belgelerine bakabilirsiniz.

Diğer sistem gereksinimleri

Sisteme şu bağımlılıkların kurulması gerekir:

Git: https://git-scm.com/
Pango, Cairo ve ilişkili üst bilgi dosyaları ile GObject iç gözlem verileri: https://cairographics.org/, https://pango.gnome.org/, bilgi almak için: Pango ve Cairo
git-review (Gerrit desteği için isteğe bağlı): https://pypi.org/project/git-review/
git-svn (Subversion desteği için isteğe bağlı): https://git-scm.com/docs/git-svn
tesseract ve verileri (ekran görüntülerinde karakter tanıma için isteğe bağlı): https://github.com/tesseract-ocr/tesseract
licensee (bileşen oluştururken lisansın algılanması için isteğe bağlı): https://github.com/licensee/licensee

Yapım zamanı bağımlılıkları

Bazı Python bağımlılıkları bağımlılıklarını kurmanız gerekebilir. Bu durum, bunları nasıl kurduğunuza bağlıdır. O yüzden her paketin kendi belgesine başvurun. Pip kullanarak yapılan kurulum sorasında ya da dağıtım paketlerini kullanırken önceden oluşturulmuş Wheels kullanıyorsanız, bunlara gerek duymazsınız.

Pango ve Cairo

3.7 sürümünde değişti.

Weblate, bitmap bileşenlerini (bilgi almak için: Promoting the translation) ve görüntüleme denetimlerini (bilgi almak için: Yazı tiplerini yönetmek) oluşturmak için Pango ve Cairo kullanır. Python bağlantılarını düzgün olarak kurmak için önce sistem kitaplıklarını kurmanız gerekir. Hem Cairo hem de Pango gereklidir, bunun için de GLib gereklidir. Tüm bunlar geliştirme dosyaları ve GObject iç gözlem verileriyle birlikte kurulmalıdır.

Sürüm imzalarını doğrulamak

Weblate sürümü, yayın geliştiricisi tarafından şifrelenmiş olarak imzalanır. Şu anda bu işi Michal Čihař yapıyor ve onun PGP anahtarının parmak izi:

63CB 1DF1 EF12 CF2A C0EE 5A32 9C27 B313 42B7 511D

ve <https://keybase.io/nijel> adresinden diğer kimlik bilgilerini alabilirsiniz.

İmzanın indirdiğiniz arşivle eşleştiğini doğrulamanız gerekir. Bu şekilde, yayınlanan kodu değiştirilmemiş olduğundan emin olabilirsiniz. Güncel sürümü indirdiğinizden emin olmak için imzanın tarihini de doğrulamalısınız.

Her arşiv dosyası için, PGP imzasının bulunduğu .asc dosyaları bulunur. Bu iki dosyayı aynı klasöre kaydettikten sonra imzayı doğrulayabilirsiniz:

$ gpg --verify Weblate-3.5.tar.xz.asc
gpg: assuming signed data in 'Weblate-3.5.tar.xz'
gpg: Signature made Ne 3. března 2019, 16:43:15 CET
gpg:                using RSA key 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: Can't check signature: public key not found

Görebileceğiniz gibi GPG, herkese açık anahtarı bilmediğini bildiriyor. Bu aşamada şu adımlardan birini uygulamanız gerekir:

Anahtarı indirmek için wkd kullanın:

$ gpg --auto-key-locate wkd --locate-keys michal@cihar.com
pub   rsa4096 2009-06-17 [SC]
      63CB1DF1EF12CF2AC0EE5A329C27B31342B7511D
uid           [ultimate] Michal Čihař <michal@cihar.com>
uid           [ultimate] Michal Čihař <nijel@debian.org>
uid           [ultimate] [jpeg image of size 8848]
uid           [ultimate] Michal Čihař (Braiins) <michal.cihar@braiins.cz>
sub   rsa4096 2009-06-17 [E]
sub   rsa4096 2015-09-09 [S]

Michal sunucusundan anahtarlığı indirip şununla içe aktarın:

$ gpg --import wmxth3chu9jfxdxywj1skpmhsj311mzm

Anahtarı bir anahtar sunucusundan indirip içe aktarın:

$ gpg --keyserver hkp://pgp.mit.edu --recv-keys 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: key 9C27B31342B7511D: "Michal Čihař <michal@cihar.com>" imported
gpg: Total number processed: 1
gpg:              unchanged: 1

Bu uygulama, durumu biraz iyileştirir. Bu noktada, belirtilen anahtardaki imzanın doğruluğundan emin olabilirsiniz. Ancak yine de anahtarda kullanılan ada güvenemezsiniz:

$ gpg --verify Weblate-3.5.tar.xz.asc
gpg: assuming signed data in 'Weblate-3.5.tar.xz'
gpg: Signature made Ne 3. března 2019, 16:43:15 CET
gpg:                using RSA key 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: Good signature from "Michal Čihař <michal@cihar.com>" [ultimate]
gpg:                 aka "Michal Čihař <nijel@debian.org>" [ultimate]
gpg:                 aka "[jpeg image of size 8848]" [ultimate]
gpg:                 aka "Michal Čihař (Braiins) <michal.cihar@braiins.cz>" [ultimate]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 63CB 1DF1 EF12 CF2A C0EE  5A32 9C27 B313 42B7 511D

Buradaki sorun, herhangi birinin aynı adlı bir anahtar yayınlayabilmesidir. Anahtarın gerçekten ilgili kişinin olduğundan emin olmanız gerekir. Bu konu, GNU gizlilik rehberinin Herkese açık anahtarlığınızdaki diğer anahtarları doğrulama bölümünde ele alınmıştır. En güvenilir yöntem, geliştiriciyle birebir tanışmak ve anahtar parmak izlerini takas etmektir. Ancak güven ağına da güvenebilirsiniz. Bu şekilde, geliştiriciyle birebir tanışmış başka kişilerin imzalarıyla anahtara geçici olarak güvenebilirsiniz.

Anahtara güvenildikten sonra uyarı görünmez olur:

$ gpg --verify Weblate-3.5.tar.xz.asc
gpg: assuming signed data in 'Weblate-3.5.tar.xz'
gpg: Signature made Sun Mar  3 16:43:15 2019 CET
gpg:                using RSA key 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: Good signature from "Michal Čihař <michal@cihar.com>" [ultimate]
gpg:                 aka "Michal Čihař <nijel@debian.org>" [ultimate]
gpg:                 aka "[jpeg image of size 8848]" [ultimate]
gpg:                 aka "Michal Čihař (Braiins) <michal.cihar@braiins.cz>" [ultimate]

İmza geçersiz olursa (arşiv değiştirilmişse), anahtara güvenilip güvenilmediğine bakılmaksızın açık bir hata iletisi görürsünüz:

$ gpg --verify Weblate-3.5.tar.xz.asc
gpg: Signature made Sun Mar  3 16:43:15 2019 CET
gpg:                using RSA key 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: BAD signature from "Michal Čihař <michal@cihar.com>" [ultimate]

Dosya sistemi izinleri

Weblate işleminin, verileri tuttuğu DATA_DIR klasöründe okuma ve yazma yapabilmesi gerekir. Bu klasördeki tüm dosyaların sahibi, tüm Weblate işlemlerini çalıştıran kullanıcı olmalı ve bu klasöre yazabilmelidir (genellikle WSGI ve Celery, bilgi almak için sunucu ve Celery ile arka plan görevlerini kullanmak).

Varsayılan yapılandırmada bunlar Weblate kaynaklarıyla aynı ağaca yerleştirilir. Ancak bunları /var/lib/weblate gibi daha iyi bir konuma taşımayı yeğleyebilirsiniz.

Weblate bu klasörleri kendiliğinden oluşturmaya çalışır. Ancak bunu yapmak için yeterli izinleri yoksa bunu yapamaz.

Yönetim komutları komutunu çalıştırırken de dikkatli olmalısınız. Komut aynı Weblate kullanıcısı ile çalıştırılmalıdır yoksa bazı dosyaların izinler yanlış olabilir.

Docker kapsayıcısında, /app/data birimindeki tüm dosyaların sahibi kapsayıcı içindeki weblate kullanıcısı olmalıdır (UID 1000).

Ayrıca bakınız

Durağan dosyalar sunmak

Weblate için veri tabanı kurulumu

Weblate için PostgreSQL veri tabanı sunucusunun kullanılması önerilir.

Ayrıca bakınız

Güç bir veri tabanı sunucusu kullanın, Databases, Diğer veri tabanlarından PostgreSQL üzerine aktarım

PostgreSQL

Django temelli siteler için genellikle en iyi seçim PostgreSQL kullanmaktır. Django tarafından referans olarak kullanılan veri tabanıdır.

Not

Weblate, bazı durumlarda ayrı olarak kurulması gereken trigram eklentisini kullanır. Postgresql-contrib ya da benzer şekilde adlandırılmış bir paket arayın.

Ayrıca bakınız

PostgreSQL notes

PostgreSQL üzerinde bir veri tabanı oluşturmak

Weblate için ayrı bir kullanıcı hesabı ile ayrı bir veri tabanı kullanmak genellikle iyi bir fikirdir:

# If PostgreSQL was not installed before, set the main password
sudo -u postgres psql postgres -c "\password postgres"

# Create a database user called "weblate"
sudo -u postgres createuser --superuser --pwprompt weblate

# Create the database "weblate" owned by "weblate"
sudo -u postgres createdb -E UTF8 -O weblate weblate

İpucu

Weblate kullanıcısını PostgreSQL üzerinde süper kullanıcı yapmak istemiyorsanız, bu seçeneği atlayabilirsiniz. Bu durumda, PostgreSQL süper kullanıcısı ile Weblate şemasındaki bazı aktarım adımlarını el ile yapmanız gerekir:

CREATE EXTENSION IF NOT EXISTS pg_trgm WITH SCHEMA weblate;
CREATE EXTENSION IF NOT EXISTS btree_gin WITH SCHEMA weblate;

Weblate yapılandırmasını PostgreSQL kullanacak biçimde ayarlamak

PostgreSQL için settings.py kod parçası:

DATABASES = {
    "default": {
        # Database engine
        "ENGINE": "django.db.backends.postgresql",
        # Database name
        "NAME": "weblate",
        # Database user
        "USER": "weblate",
        # Name of role to alter to set parameters in PostgreSQL,
        # use in case role name is different than user used for authentication.
        # "ALTER_ROLE": "weblate",
        # Database password
        "PASSWORD": "password",
        # Set to empty string for localhost
        "HOST": "database.example.com",
        # Set to empty string for default
        "PORT": "",
    }
}

Veri tabanı aktarımı, Weblate tarafından kullanılan ALTER ROLE veri tabanı rolüyle gerçekleştirir. Çoğu durumda rolün adı kullanıcı adıyla aynıdır. Daha karmaşık kurulumlarda rol adı kullanıcı adından farklıdır ve veri tabanı aktarımı sırasında rolün var olmadığı ile ilgili bir hata iletisi görürsünüz (psycopg2.errors.UndefinedObject: role "weblate@hostname" des not exist). Bu sorunun PostgreSQL için Azure veri tabanı ile ortaya çıktığı biliniyor. Ancak yalnızca bu durumla sınırlı değildir. Lütfen veri tabanı aktarımı sırasında Weblate tarafından kullanılacak rolün adını ALTER_ROLE seçeneğinden ayarlayın.

MySQL ve MariaDB

İpucu

Bazı Weblate özellikleri PostgreSQL ile daha iyi çalışır. PostgreSQL veri tabanı, tam metin özelliklerinin kullanılmasını sağlar ve arama ile çeviri belleği işlemlerinde daha üstündür.

Weblate, MySQL ya da MariaDB ile de kullanılabilir. Lütfen bunları Django ile kullanmakla ilgili uyarılar için MySQL notes ve MariaDB notes bölümlerine bakın. Bazı sınırlamalar nedeniyle, yeni kurulumlar için PostgreSQL kullanılması önerilir.

Weblate için en az MySQL 5.7.8 ya da MariaDB 10.2.7 sürümü kullanılmalıdır.

Weblate için önerilen yapılandırma:

Daha yüksek Unicode düzlemlerinin (emojiler gibi) görüntülenmesini sağlamak için utf8mb4 karakter kümesini kullanın.
Metin alanlarında daha uzun dizinlerin kullanılabilmesini sağlamak için sunucuyu innodb_large_prefix seçeneği ile yapılandırın.
Yalıtım düzeyini READ COMMITTED olarak ayarlayın.
SQL kipi STRICT_TRANS_TABLES olarak ayarlanmalıdır.

MySQL 8.x, MariaDB 10.5.x ya da üzeri için varsayılan yapılandırma yeterlidir. Bu nedenle sunucunun ayarlanması gerekmez ve gereken her şey istemci tarafında yapılandırılabilir.

Aşağıda 8 GB RAM belleği olan bir sunucu için /etc/my.cnf.d/server.cnf dosyasının örneğini bulabilirsiniz. Bu ayarlar çoğu kurulum için yeterli olmalıdır. MySQL ve MariaDB için, sisteme aynı anda çok sayıda kullanıcının erişmesinin gerekmediği durumlarda sunucu başarımını artıracak seçenekler vardır. Ayrıntılı bilgiyi üretici belgelerinde bulabilirsiniz.

Weblate kurulumunuza başlamadan önce innodb_file_per_table seçeneğinin doğru ayarlanması ve MySQL ya da MariaDB veri tabanı sunucusunun yeniden başlatılması kurulum yaparken karşılaşılabilecek sorunları azaltmak için çok önemlidir.

[mysqld]
character-set-server = utf8mb4
character-set-client = utf8mb4
collation-server = utf8mb4_unicode_ci

datadir=/var/lib/mysql

log-error=/var/log/mariadb/mariadb.log

innodb_large_prefix=1
innodb_file_format=Barracuda
innodb_file_per_table=1
innodb_buffer_pool_size=2G
sql_mode=STRICT_TRANS_TABLES

İpucu

#1071 - Specified key was too long; max key length is 767 bytes hatasını görürseniz, yapılandırmanızı yukarıdaki innodb ayarlarına uygun olarak güncelleyin ve kurulumu yeniden başlatın.

İpucu

#2006 - MySQL server has gone away hatasını görürseniz, CONN_MAX_AGE seçeneğini yapılandırmak yardımcı olabilir.

Weblate için MySQL/MariaDB yapılandırması

MySQL ve MariaDB için settings.py kod parçası:

DATABASES = {
    "default": {
        # Database engine
        "ENGINE": "django.db.backends.mysql",
        # Database name
        "NAME": "weblate",
        # Database user
        "USER": "weblate",
        # Database password
        "PASSWORD": "password",
        # Set to empty string for localhost
        "HOST": "127.0.0.1",
        # Set to empty string for default
        "PORT": "3306",
        # In case you wish to use additional
        # connection options
        "OPTIONS": {},
    }
}

Kuruluma başlamadan önce MySQL ya da MariaDB veri tabanı sunucusu üzerinde weblate kullanıcı hesabını oluşturmanız gerekir. Bunun için şu komutları kullanın:

GRANT ALL ON weblate.* to 'weblate'@'localhost' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;

Diğer yapılandırmalar

Giden e-postayı yapılandırmak

Weblate, hesap etkinleştirme işlemleri ve kullanıcılar tarafından yapılandırılmış çeşitli bildirimler gibi çeşitli durumlar için e-posta gönderir. Bunun için bir SMTP sunucu erişiminin yapılandırılması gerekir.

E-posta sunucusu şu ayarlar kullanılarak yapılandırılır: EMAIL_HOST, EMAIL_HOST_PASSWORD, EMAIL_USE_TLS, EMAIL_USE_SSL, EMAIL_HOST_USER ve EMAIL_PORT. Seçeneklerin adları oldukça açıklayıcıdır. Ayrıntılı bilgi almak için Django belgelerine bakabilirsiniz.

İpucu

Kimlik doğrulanmasının desteklenmediği ile ilgili bir hata görürseniz (SMTP AUTH extension not supported by server gibi), bu sorun büyük olasılıkla güvenli olmayan bağlantı kullanımından kaynaklanıyordur ve sunucu kimliğin bu şekilde doğrulanmasını reddeder. Böyle bir durumda EMAIL_USE_TLS seçeneğini etkinleştirmeyi deneyin.

Ayrıca bakınız

Not receiving e-mails from Weblate, Docker kapsayıcısında giden e-posta ayarlarını yapılandırmak

Ters vekil sunucu arkasında çalıştırmak

Hız sınırlama, Spam protection ve Denetim günlüğü Weblate özellikleri istemci IP adresinin bilinmesine dayanır.

Varsayılan yapılandırmada Weblate, WSGI işleyicisi tarafından ayarlanan REMOTE_ADDR IP adresini alır.

Ters vekil sunucu kullanıyorsanız, bu alanda büyük olasılıkla ters vekil sunucu adresi bulunacaktır. Weblate yapılandırmasını ek HTTP üst bilgilerine güvenecek ve IP adresini bunlardan alacak şekilde ayarlamanız gerekir. Bu yapılandırma, ters vekil sunucu kullanmayan kurulumlar için IP adresi sahteciliğine olanak sağlayacağından varsayılan olarak etkinleştirilemez. IP_BEHIND_REVERSE_PROXY seçeneğini etkinleştirmek genel kurulumlar için yeterli olabilir. Ancak IP_PROXY_HEADER ve IP_PROXY_OFFSET seçeneklerini de ayarlamanız gerekebilir.

Dikkat edilmesi gereken başka bir şey de Host üst bilgisidir ve SITE_DOMAIN olarak yapılandırılmış değerle eşleşmelidir. Ters vekil sunucunuzda ek yapılandırma gerekebilir (örneğin, Apache için ProxyPreserveHost On ya da nginx ile ``proxy_set_header Host $host;` kullanın).

Ayrıca bakınız

Spam protection, Hız sınırlama, Denetim günlüğü, IP_BEHIND_REVERSE_PROXY, IP_PROXY_HEADER, IP_PROXY_OFFSET, SECURE_PROXY_SSL_HEADER

HTTP vekil sunucu

Weblate, sürüm denetimi sistemi komutlarını yürütür ve bunlar ortamın vekil sunucu yapılandırmasını alır. Önerilen yaklaşım, settings.py dosyasında vekil sunucu ayarlarını belirtmektir:

import os

os.environ["http_proxy"] = "http://proxy.example.com:8080"
os.environ["HTTPS_PROXY"] = "http://proxy.example.com:8080"

Ayrıca bakınız

Vekil sunucu ortam değişkenleri

Yapılandırmayı ayarlama

Ayrıca bakınız

Örnek yapılandırma

weblate/settings_example.py dosyasını weblate/settings.py dosyasına kopyalayın ve kurulumunuza uygun olarak ayarlayın. Büyük olasılıkla şu seçenekleri ayarlamak isteyeceksiniz:

ADMINS

Bir şeyler ters gittiğinde bildirim alacak site yöneticilerinin listesi. Başarısız olan birleştirme bildirimleri ya da Django hataları gibi.

Ayrıca bakınız

ADMINS, Yöneticileri düzgün şekilde yapılandırın

ALLOWED_HOSTS

Bu seçeneği, sitenizin sunması gereken barındırma hizmetlerini listeleyecek biçimde ayarlamalısınız. Örneğin:
ALLOWED_HOSTS = ["demo.weblate.org"]
Alternatif olarak genel arama karakteri ekleyebilirsiniz:
ALLOWED_HOSTS = ["*"]
Ayrıca bakınız

ALLOWED_HOSTS, WEBLATE_ALLOWED_HOSTS, Allowed hosts kurulumu

SESSION_ENGINE

Oturumlarınızın nasıl kaydedileceğini yapılandırın. Varsayılan veri tabanı arka uç altyapısını korumanız durumunda, eski oturum verilerini veri tabanından kaldırmak için weblate clearsessions görevini zamanlamanız gerekir.

Ön bellek olarak Redis kullanıyorsanız (bilgi almak için: Ön bellek özelliğini açın) onu oturumlar için de kullanmanız önerilir:
SESSION_ENGINE = "django.contrib.sessions.backends.cache"
Ayrıca bakınız

Configuring the session engine, SESSION_ENGINE

DATABASES

Veri tabanı sunucusu ile bağlantı. Ayrıntı bilgi almak içinDjango belgelerine bakabilirsiniz.

Ayrıca bakınız

Weblate için veri tabanı kurulumu, DATABASES, Databases

DEBUG

Herhangi bir üretim sunucusunda bu seçeneği devre dışı bırakın. Hata ayıklama kipi etkinleştirildiğinde, Django kullanıcılara hata bildirimlerini görüntüler. Devre dışı bırakıldığında, hatalar e-posta olarak ADMINS seçeneğindeki adreslere gönderilir (yukarıya bakın).

Hata ayıklama kipi de Weblate işleyişini yavaşlatır. Çünkü Django bu durumda içeride çok daha fazla bilgi depolar.

Ayrıca bakınız

DEBUG, Hata ayıklama kipini kapatın

DEFAULT_FROM_EMAIL

Hesap açma e-postaları gibi giden e-postalar için e-posta gönderici adresi.

Ayrıca bakınız

DEFAULT_FROM_EMAIL

SECRET_KEY

Django tarafından çerezlerdeki bazı bilgileri imzalamak için kullanılan anahtar. Bilgi almak için: Django gizli anahtarı.

Ayrıca bakınız

SECRET_KEY

SERVER_EMAIL

Başarısız olan birleştirme bildirimleri gibi, yöneticiye gönderilecek e-postalarda gönderici adresi olarak kullanılacak e-posta adresleri.

Ayrıca bakınız

SERVER_EMAIL

Veri tabanını doldurmak

Yapılandırmanız hazır olduktan sonra, veri tabanı yapısını oluşturmak için weblate migrate komutunu çalıştırabilirsiniz. Bundan sonra yönetici arayüzünü kullanarak çeviri projeleri oluşturabilmelisiniz.

Bir kurulumu etkileşimsiz olarak yapmak isterseniz, weblate migrate --noinput komutunu kullanabilir ve ardından createadmin komutu ile bir yönetici kullanıcı oluşturabilirsiniz.

İşiniz bittiğinde, yönetici arayüzündeki :guilabel:Başarım raporu bölümüne bakmalısınız. Burada size site yapılandırmasını iyileştirmeniz için ipuçları sunulur.

Ayrıca bakınız

Yapılandırma, Yetkiler ve hazır rollerin listesi

Üretim kurulumu

Bir üretim kurulumu için aşağıdaki bölümlerde açıklanan ayarlamaları yapmanız gerekir. Süper kullanıcı olarak oturum açıldığında en önemli ayarlar üst çubukta ünlem simgesi ile bir uyarı olarak görüntülenir:

Django tarafından tetiklenen denetimleri de incelemeniz önerilir (ancak hepsini düzeltmeniz gerekmeyebilir):

weblate check --deploy

Aynı denetim listesini Yönetim arayüzü bölümünden de gözden geçirebilirsiniz.

Ayrıca bakınız

Deployment checklist

Hata ayıklama kipini kapatın

Şununla Django hata ayıklama kipini kaptın (DEBUG):

DEBUG = False

Hata ayıklama kipi açıkken, Django yürütülen tüm sorguları depolar ve kullanıcılara, üretim kipinde gerek duyulmayan hata izlerini görüntüler.

Ayrıca bakınız

Yapılandırmayı ayarlama

Yöneticileri düzgün şekilde yapılandırın

Sunucuda bir sorun olması durumunda e-postaları kimlerin alacağını belirlemek için doğru yönetici adreslerini ADMINS seçeneği ile ayarlayın. Örneğin:

ADMINS = (("Your Name", "your_email@example.com"),)

Ayrıca bakınız

Yapılandırmayı ayarlama

Doğru site etki alanını ayarlayın

Yönetici arabiriminde site adını ve etki alanını ayarlayın. Yoksa RSS ya da kayıt e-postalarındaki bağlantılar çalışmaz. Bu ayar, site etki alanı adının yazılması gereken SITE_DOMAIN seçeneği ile yapılandırılır.

4.2 sürümünde değişti: 4.2 sürümünden önce bunun yerine Django site çatısı kullanılıyordu. Bilgi almak için The “sites” framework.

Ayrıca bakınız

Allowed hosts kurulumu, HTTPS ayarını düzgün biçimde yapın SITE_DOMAIN, WEBLATE_SITE_DOMAIN, ENABLE_HTTPS

HTTPS ayarını düzgün biçimde yapın

Weblate için şifrelenmiş HTTPS iletişim kuralını kullanmanız önemle önerilir. Sertifikanızı hazırladıktan sonra ENABLE_HTTPS seçeneğini ayarlamanız gerekir:

ENABLE_HTTPS = True

İpucu

Ayrıca HSTS özelliğini de etkinleştirmek isteyebilirsiniz. Bilgi almak için: SSL/HTTPS.

Ayrıca bakınız

ENABLE_HTTPS, Allowed hosts kurulumu, Doğru site etki alanını ayarlayın

SECURE_HSTS_SECONDS seçeneğini düzgün biçimde ayarlayın

Siteniz SSL üzerinden sunuluyorsa, HTTP sıkı aktarım güvenliği (HTTP Strict Transport Security) özelliğini etkinleştirmek için settings.py dosyasında SECURE_HSTS_SECONDS değerini ayarlamayı değerlendirmeniz gerekir. Bu seçenek varsayılan olarak, aşağıda gösterildiği gibi 0 olarak ayarlanmıştır.

SECURE_HSTS_SECONDS = 0

Sıfır olmayan bir tamsayı değerine ayarlanırsa, django.middleware.security.SecurityMiddleware üst bilgisi bulunmayan tüm yanıtlarda HTTP Strict Transport Security üst bilgisini ayarlar.

Uyarı

Bu ayar yanlış yapılırsa, sitenizi geri dönüşü olmayan bir şekilde (bir süreliğine) bozabilir. Önce HTTP Strict Transport Security belgelerini okuyun.

Güç bir veri tabanı sunucusu kullanın

Lütfen üretim ortamı için PostgreSQL kullanın. Bilgi almak için: Weblate için veri tabanı kurulumu.
Veri tabanı sunucusunu çalıştırmak için yakın konumları kullanın. Yoksa ağ başarımı ya da güvenilirliği sorunları Weblate deneyiminizi mahvedebilir.
Veritabanı sunucusunun başarımını denetleyin veya yapılandırmasını değiştirin. Örneğin PGTune kullanabilirsiniz.

Ayrıca bakınız

Weblate için veri tabanı kurulumu, Diğer veri tabanlarından PostgreSQL üzerine aktarım, Yapılandırmayı ayarlama, Databases

Ön bellek özelliğini açın

Olabiliyorsa, CACHES yapılandırma değişkenini ayarlayarak Django Redis kullanın. Örneğin:

CACHES = {
    "default": {
        "BACKEND": "django_redis.cache.RedisCache",
        "LOCATION": "redis://127.0.0.1:6379/0",
        # If redis is running on same host as Weblate, you might
        # want to use unix sockets instead:
        # 'LOCATION': 'unix:///var/run/redis/redis.sock?db=0',
        "OPTIONS": {
            "CLIENT_CLASS": "django_redis.client.DefaultClient",
            "PARSER_CLASS": "redis.connection.HiredisParser",
        },
    }
}

İpucu

Ön bellek için Redis ayarlarını değiştirirseniz, bunları Celery için de ayarlamanız gerekebilir. Bilgi almak için: :ref:`Celery.

Ayrıca bakınız

Avatar ön belleği, Django’s cache framework

Avatar ön belleği

Django ön belleğinin yanında, Weblate avatarları da ön belleğe alır. Bu amaçla ayrı, dosya temelli bir ön bellek kullanılması önerilir:

CACHES = {
    "default": {
        # Default caching backend setup, see above
        "BACKEND": "django_redis.cache.RedisCache",
        "LOCATION": "unix:///var/run/redis/redis.sock?db=0",
        "OPTIONS": {
            "CLIENT_CLASS": "django_redis.client.DefaultClient",
            "PARSER_CLASS": "redis.connection.HiredisParser",
        },
    },
    "avatar": {
        "BACKEND": "django.core.cache.backends.filebased.FileBasedCache",
        "LOCATION": os.path.join(DATA_DIR, "avatar-cache"),
        "TIMEOUT": 604800,
        "OPTIONS": {
            "MAX_ENTRIES": 1000,
        },
    },
}

Ayrıca bakınız

ENABLE_AVATARS, AVATAR_URL_PREFIX, Avatarlar, Ön bellek özelliğini açın, Django’s cache framework

E-posta gönderimini yapılandırın

Weblate tarafından bazı e-postaların gönderilmesi gerekir ve bu e-postaların doğru bir gönderici adresi olmalıdır. Lütfen SERVER_EMAIL ve DEFAULT_FROM_EMAIL değerlerini ortamınıza uygun şekilde yapılandırın. Örneğin:

SERVER_EMAIL = "admin@example.org"
DEFAULT_FROM_EMAIL = "weblate@example.org"

Not

Weblate tarafından e-posta gönderilmesini devre dışı bırakmak için EMAIL_BACKEND seçeneğini django.core.mail.backends.dummy.EmailBackend olarak ayarlayın.

Bu yapılandırma, kayıt ve parola sıfırlama e-postaları ile birlikte tüm e-posta gönderimini devre dışı bırakır.

Ayrıca bakınız

Yapılandırmayı ayarlama, Giden e-postayı yapılandırmak, EMAIL_BACKEND, DEFAULT_FROM_EMAIL, SERVER_EMAIL

Allowed hosts kurulumu

Django, sitenizin sunmasına izin verilen etki alanı adlarının listesini ALLOWED_HOSTS seçeneğinde tutar. Bu seçenek boş bırakılırsa tüm istekler engellenir.

Bu seçenek, HTTP sunucunuzla eşleşecek şekilde yapılandırılmamışsa, Invalid HTTP_HOST header: ‘1.1.1.1’. You may need to add ‘1.1.1.1’ to ALLOWED_HOSTS. gibi hata iletileri görürsünüz

İpucu

Docker kapsayıcısında WEBLATE_ALLOWED_HOSTS seçeneği kullanılabilir.

Ayrıca bakınız

ALLOWED_HOSTS, WEBLATE_ALLOWED_HOSTS, Doğru site etki alanını ayarlayın

Django gizli anahtarı

SECRET_KEY ayarı Django tarafından çerezleri imzalamak için kullanılır. Örnek kurulumdaki değeri kullanmayıp kendiniz için oluşturacağınız gerçek bir değeri kullanmanız gerekir.

Weblate içindeki weblate-generate-secret-key komutunu kullanarak yeni bir anahtar oluşturabilirsiniz.

Ayrıca bakınız

SECRET_KEY

Bakım görevlerini yürütmek

En iyi başarım için, bazı bakım görevlerini arka planda çalıştırmak iyi bir fikirdir. Bu işlemler Celery ile arka plan görevlerini kullanmak tarafından kendiliğinden yapılır ve şu görevleri kapsar:

Yapılandırma sağlığı denetimi (saatlik).
Bekleyen değişiklikleri işlemek (saatlik). Bilgi almak için: Lazy commit işlemeleri ve commit_pending.
Bileşen uyarılarını güncellemek (günlük).
Uzak dalları güncellemek (gecelik). Bilgi almak için: :setting:`AUTO_UPDATE’.
Çeviri belleğinin JSON yedeğini almak (günlük). Bilgi almak için: dump_memory.
Tam metin ve veri tabanı bakım görevleri (günlük ve haftalık görevler). Bilgi almak için: cleanuptrans.

3.2 sürümünde değişti: 3.2 sürümünden bu yana, bu görevleri yapmak için varsayılan olarak Celery kullanılır. Weblate içinde buna uygun yapılandırma hazırdır. Bilgi almak için: ref: celery.

Sistem yerel ayarları ve kodlama

Sistem yerel ayarları UTF-8 destekleyenler ile yapılandırılmalıdır. Çoğu Linux dağıtımında varsayılan ayar böyledir. Sisteminizde durumun böyle olmaması durumunda, lütfen yerel ayarları UTF-8 çeşidi olarak değiştirin.

Örneğin, /etc/default/locale dosyasını düzenleyerek LANG="C.UTF-8” olarak ayarlayabilirsiniz.

Bazı durumlarda, her hizmetin ayrı yerel ayar yapılandırması vardır. Bunlar, dağıtımlara ve web sunuculara göre farklılık gösterebilir. Bu konuda bilgi almak için web sunucusu paketlerinizin belgelerine bakın.

Ubuntu üzerinde Apache /etc/apache2/envvars kullanır:

export LANG='en_US.UTF-8'
export LC_ALL='en_US.UTF-8'

CentOS üzerinde Apache /etc/sysconfig/httpd (or /opt/rh/httpd24/root/etc/sysconfig/httpd) kullanır:

LANG='en_US.UTF-8'

Özel sertifika kuruluşu kullanmak

Weblate, HTTP istekleri sırasında SSL sertifikalarını doğrular. Varsayılan paketlerde güvenilmeyen bir özel sertifika kuruluşu kullanıyorsanız, sertifikasını güvenilir olarak eklemeniz gerekir.

Yeğlenen yaklaşım bunu sistem düzeyinde yapmaktır. Ayrıntılı bilgi almak için dağıtım belgelerinize bakın (örneğin debian üzerinde bu işlem, sertifika kuruluşunun sertifikasını /usr/local/share/ca-certificates/ içine yerleştirip update-ca-certificates komutunu çalıştırarak yapılabilir).

Bu işlem yapıldıktan sonra, sistem araçları sertifikaya güvenir ve Git tarafından da bu sertifika kullanılır.

Python kodu için, kendi içinde gelen sertifika yerine istekleri sistem sertifika kuruluşu paketini kullanacak şekilde yapılandırmanız gerekir. Bu işlem, aşağıdaki kod parçasını settings.py içine ekleyerek yapılabilir (yol Debian sistemine özgüdür):

import os

os.environ["REQUESTS_CA_BUNDLE"] = "/etc/ssl/certs/ca-certificates.crt"

İstemci varlıklarının sıkıştırılması

Weblate, bazı JavaScript ve CSS dosyalarıyla birlikte gelir. Başarımı artırmak için bunların bir istemciye gönderilmeden önce sıkıştırılması iyidir. Varsayılan yapılandırmada bu işlem çok az ek yük oluşturarak anında yapılır. Büyük kurulumlarda, çevrimdışı sıkıştırma kipini etkinleştirmeniz önerilir. Bunun yapılandırmada ayarlanması ve sıkıştırmanın her Weblate yükseltmesinde tetiklenmesi gerekir.

Yapılandırma, django.conf.settings.COMPRESS_OFFLINE seçeneği ve django.conf.settings.COMPRESS_OFFLINE_CONTEXT seçeneği etkinleştirilerek kolayca ayarlanır (ikincisi zaten örnek yapılandırmalara eklenmiştir):

COMPRESS_OFFLINE = True

Her dağıtımda, dosyaları geçerli sürümle eşleşecek şekilde sıkıştırmanız gerekir:

weblate compress

İpucu

Resmi Docker kalıbında bu özellik etkinleştirilmiştir.

Ayrıca bakınız

Common Deployment Scenarios, Durağan dosyalar sunmak

Sunucuyu çalıştırmak

İpucu

Aşağıda açıklanan hizmetlerle ilgili deneyiminiz yoksa, Docker ile kurmak adresine bakmak isteyebilirsiniz.

Weblate çalıştırmak için birkaç hizmete gerek duyacaksınız. Önerilen kurulum şunlardan oluşur:

Veri tabanı sunucusu (bilgi almak için: Weblate için veri tabanı kurulumu)
Ön bellek sunucusu (bilgi almak için: Ön bellek özelliğini açın)
Durağan dosyalar ve SSL ucu için ön yüz web sunucusu (bilgi almak için: Durağan dosyalar sunmak)
Devingen içerik için WSGI sunucusu (bilgi almak için: NGINX ve uWSGI için örnek yapılandırma)
Arka plan görevlerini yürütmek için Celery (bilgi almak için: Celery ile arka plan görevlerini kullanmak)

Not

Hizmetler arasında bazı bağımlılıklar bulunur. Örneğin Celery veya uwsgi işlemlerini başlatırken ön bellek ve veritabanı çalışıyor olmalıdır.

Çoğu durumda, tüm hizmetleri tek (sanal) sunucu üzerinde çalıştırırsınız. Ancak kurulumunuzun yükü ağırsa, hizmetleri ayırabilirsiniz. Bu durumda, Celery ve wsgi sunucularının DATA_DIR klasörüne erişmesini sağlamanız yeterlidir.

Not

WSGI işlemini çalıştıran kullanıcı ile Celery işlemini çalıştıran kullanıcı aynı olmalıdır. Yoksa DATA_DIR klasöründeki dosyaların sahiplikleri karışır ve bu da çalışma sırasında sorunlara yol açar.

Ayrıca Dosya sistemi izinleri ve Celery ile arka plan görevlerini kullanmak bölümlerine bakın.

Web sunucusunu çalıştırmak

Weblate çalıştırmak, diğer Django temelli programları çalıştırmaktan farklı değildir. Django genellikle uWSGI ya da fcgi olarak çalıştırılır (aşağıda farklı web sunucuları için örnekler bulabilirsiniz).

Deneme amacıyla, Django üzerindeki yerleşik web sunucusunu kullanabilirsiniz:

weblate runserver

Uyarı

BU SUNUCUYU ÜRETIM AYARIYLA KULLANMAYIN. Güvenlik denetimlerinden ya da başarım sınamalarından geçirilmemiştir. Ayrıca runserver ile ilgili Django belgelerine bakın.

İpucu

Django içindeki sunucu, yalnızca geliştirme amaçlı olduğundan yalnızca DEBUG seçeneği etkin olan durağan dosyaları sunar. Üretim kullanımı için lütfen NGINX ve uWSGI için örnek yapılandırma, Örnek Apache yapılandırması, Örnek Apache ve Gunicorn yapılandırması ve Durağan dosyalar sunmak içindeki wsgi kurulumlarına bakın.

Durağan dosyalar sunmak

2.4 sürümünde değişti: 2.4 sürümünden önce Weblate, Django durağan dosyalar çatısını düzgün kullanmıyordu ve kurulum daha karmaşıktı.

Durağan Django dosyalarının tek bir klasörde toplanması gerekiyor. Bunun için weblate collectstatic --noinput komutunu çalıştırın. Bu komut, durapan dosyaları STATIC_ROOT seçeneği ile belirtilen bir klasöre kopyalar (bu klasör, varsayılan olarak DATA_DIR içindeki static klasörüdür).

Durağan dosyaları doğrudan web sunucunuzdan sunmanız önerilir. Bunu şu yollar ile kullanmalısınız:

/static/: Weblate ve yönetici arayüzünün durağan dosyalarını sunar (STATIC_ROOT ile tanımlanmış).
/media/: Kullanıcıların ortam yüklemeleri için kullanılır (ekran görüntüleri gibi).
/favicon.ico: /static/favicon.ico dosyasını sunmak için bir kural yeniden yazılmalıdır.

Ayrıca bakınız

NGINX ve uWSGI için örnek yapılandırma, Örnek Apache yapılandırması, Örnek Apache ve Gunicorn yapılandırması, İstemci varlıklarının sıkıştırılması, How to deploy Django, How to deploy static files

İçerik güvenliği ilkesi

Varsayılan Weblate yapılandırması, Content-Security-Policy veya X-XSS-Protection gibi güvenlikle ilgili HTTP üst bilgilerini ayarlayan weblate.middleware.SecurityMiddleware ara yazılımını etkinleştirir. Bunlar varsayılan olarak Weblate ve yapılandırması ile çalışacak şekilde ayarlanmıştır. Ancak bunun için ortamınıza uygun özelleştirmeler yapmanız gerekebilir.

Ayrıca bakınız

CSP_SCRIPT_SRC, CSP_IMG_SRC, CSP_CONNECT_SRC, CSP_STYLE_SRC, CSP_FONT_SRC

NGINX ve uWSGI için örnek yapılandırma

Üretim amacıyla kullanılacak web sunucusu çalıştırmak için, Weblate ile kurulan wsgi sarmalayıcısını kullanın (sanal ortamdaysanız ~/weblate-env/lib/python3.9/site-packages/weblate/wsgi.py olarak kurulur). Kullandığınız virtualenv üzerinde Python arama yolunu ayarlamayı da unutmayın (uWSGI üzerinde virtualenv = /home/user/weblate-env gibi).

Aşağıdaki yapılandırma, NGINX web sunucusu üzerinde uWSGI olarak Weblate çalıştırır.

NGINX için yapılandırma (weblate/examples/weblate.nginx.conf dosyasında da bulunabilir):

#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate virtualenv is placed
# - change /home/weblate/data to match your DATA_DIR
# - change python3.9 to match your Python version
# - change weblate user to match your Weblate user
#
server {
    listen 80;
    server_name weblate;
    # Not used
    root /var/www/html;

    location ~ ^/favicon.ico$ {
        # DATA_DIR/static/favicon.ico
        alias /home/weblate/data/static/favicon.ico;
        expires 30d;
    }

    location /static/ {
        # DATA_DIR/static/
        alias /home/weblate/data/static/;
        expires 30d;
    }

    location /media/ {
        # DATA_DIR/media/
        alias /home/weblate/data/media/;
        expires 30d;
    }

    location / {
        include uwsgi_params;
        # Needed for long running operations in admin interface
        uwsgi_read_timeout 3600;
        # Adjust based to uwsgi configuration:
        uwsgi_pass unix:///run/uwsgi/app/weblate/socket;
        # uwsgi_pass 127.0.0.1:8080;
    }
}

uWSGI için yapılandırma (weblate/examples/weblate.uwsgi.ini dosyasında da bulunabilir):

#
# uWSGI configuration for Weblate
#
# You will want to change:
#
# - change /home/weblate/weblate-env to location where Weblate virtualenv is placed
# - change /home/weblate/data to match your DATA_DIR
# - change python3.9 to match your Python version
# - change weblate user to match your Weblate user
#
[uwsgi]
plugins       = python3
master        = true
protocol      = uwsgi
socket        = 127.0.0.1:8080
wsgi-file     = /home/weblate/weblate-env/lib/python3.9/site-packages/weblate/wsgi.py

# Add path to Weblate checkout if you did not install
# Weblate by pip
# python-path   = /path/to/weblate

# In case you're using virtualenv uncomment this:
virtualenv = /home/weblate/weblate-env

# Needed for OAuth/OpenID
buffer-size   = 8192

# Reload when consuming too much of memory
reload-on-rss = 250

# Increase number of workers for heavily loaded sites
workers       = 8

# Enable threads for Sentry error submission
enable-threads = true

# Child processes do not need file descriptors
close-on-exec = true

# Avoid default 0000 umask
umask = 0022

# Run as weblate user
uid = weblate
gid = weblate

# Enable harakiri mode (kill requests after some time)
# harakiri = 3600
# harakiri-verbose = true

# Enable uWSGI stats server
# stats = :1717
# stats-http = true

# Do not log some errors caused by client disconnects
ignore-sigpipe = true
ignore-write-errors = true
disable-write-exception = true

Ayrıca bakınız

How to use Django with uWSGI

Örnek Apache yapılandırması

Weblate ile WSGI kullanırken prefork MPM kullanılması önerilir.

Aşağıdaki yapılandırma WSGI olarak Weblate çalıştırır. mod_wsgi modülünün etkinleştirilmiş olması gerekir (weblate/examples/apache.conf dosyasında bulunabilir):

#
# VirtualHost for Weblate
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate virtualenv is placed
# - change /home/weblate/data to match your DATA_DIR
# - change python3.9 to match your Python version
# - change weblate user to match your Weblate user
#
<VirtualHost *:80>
    ServerAdmin admin@weblate.example.org
    ServerName weblate.example.org

    # DATA_DIR/static/favicon.ico
    Alias /favicon.ico /home/weblate/data/static/favicon.ico

    # DATA_DIR/static/
    Alias /static/ /home/weblate/data/static/
    <Directory /home/weblate/data/static/>
        Require all granted
    </Directory>

    # DATA_DIR/media/
    Alias /media/ /home/weblate/data/media/
    <Directory /home/weblate/data/media/>
        Require all granted
    </Directory>

    # Path to your Weblate virtualenv
    WSGIDaemonProcess weblate python-home=/home/weblate/weblate-env user=weblate request-timeout=600
    WSGIProcessGroup weblate
    WSGIApplicationGroup %{GLOBAL}

    WSGIScriptAlias / /home/weblate/weblate-env/lib/python3.9/site-packages/weblate/wsgi.py process-group=weblate
    WSGIPassAuthorization On

    <Directory /home/weblate/weblate-env/lib/python3.9/site-packages/weblate/>
        <Files wsgi.py>
        Require all granted
        </Files>
    </Directory>

</VirtualHost>

Not

Weblate için Python 3 gereklidir. Bu nedenle modwsgi modülünün Python 3 çeşidini çalıştırdığınızdan emin olun. Genellikle libapache2-mod-wsgi-py3 gibi ayrı bir paket olarak bulunur.

Ayrıca bakınız

Sistem yerel ayarları ve kodlama, How to use Django with Apache and mod_wsgi

Örnek Apache ve Gunicorn yapılandırması

Aşağıdaki yapılandırma Gunicorn ve Apache 2.4 üzerinde Weblate çalıştırır (weblate/examples/apache.gunicorn.conf dosyasında bulunabilir):

#
# VirtualHost for Weblate using gunicorn on localhost:8000
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate virtualenv is placed
# - change /home/weblate/data to match your DATA_DIR
# - change python3.9 to match your Python version
# - change weblate user to match your Weblate user
#
<VirtualHost *:443>
    ServerAdmin admin@weblate.example.org
    ServerName weblate.example.org

    # DATA_DIR/static/favicon.ico
    Alias /favicon.ico /home/weblate/data/static/favicon.ico

    # DATA_DIR/static/
    Alias /static/ /home/weblate/data/static/
    <Directory /home/weblate/data/static/>
        Require all granted
    </Directory>

    # DATA_DIR/media/
    Alias /media/ /home/weblate/data/media/
    <Directory /home/weblate/data/media/>
        Require all granted
    </Directory>

    SSLEngine on
    SSLCertificateFile /etc/apache2/ssl/https_cert.cert
    SSLCertificateKeyFile /etc/apache2/ssl/https_key.pem
    SSLProxyEngine On

    ProxyPass /favicon.ico !
    ProxyPass /static/ !
    ProxyPass /media/ !

    ProxyPass / http://localhost:8000/
    ProxyPassReverse / http://localhost:8000/
    ProxyPreserveHost On
</VirtualHost>

Ayrıca bakınız

How to use Django with Gunicorn

Bir yol altında Weblate çalıştırma yapılandırması

1.3 sürümünde geldi.

Weblate ile WSGI kullanırken prefork MPM kullanılması önerilir.

Weblate çalıştırmak için /weblate gibi bir yol kullanan örnek Apache yapılandırması. Yine mod_wsgi kullanarak (weblate/examples/apache-path.conf dosyasında bulunabilir):

#
# VirtualHost for Weblate, running under /weblate path
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate virtualenv is placed
# - change /home/weblate/data to match your DATA_DIR
# - change python3.9 to match your Python version
# - change weblate user to match your Weblate user
#
<VirtualHost *:80>
    ServerAdmin admin@weblate.example.org
    ServerName weblate.example.org

    # DATA_DIR/static/favicon.ico
    Alias /weblate/favicon.ico /home/weblate/data/static/favicon.ico

    # DATA_DIR/static/
    Alias /weblate/static/ /home/weblate/data/static/
    <Directory /home/weblate/data/static/>
        Require all granted
    </Directory>

    # DATA_DIR/media/
    Alias /weblate/media/ /home/weblate/data/media/
    <Directory /home/weblate/data/media/>
        Require all granted
    </Directory>

    # Path to your Weblate virtualenv
    WSGIDaemonProcess weblate python-home=/home/weblate/weblate-env user=weblate request-timeout=600
    WSGIProcessGroup weblate
    WSGIApplicationGroup %{GLOBAL}

    WSGIScriptAlias /weblate /home/weblate/weblate-env/lib/python3.9/site-packages/weblate/wsgi.py process-group=weblate
    WSGIPassAuthorization On

    <Directory /home/weblate/weblate-env/lib/python3.9/site-packages/weblate/>
        <Files wsgi.py>
        Require all granted
        </Files>
    </Directory>

</VirtualHost>

Ek olarak weblate/settings.py dosyasını ayarlamalısınız:

URL_PREFIX = "/weblate"

Celery ile arka plan görevlerini kullanmak

3.2 sürümünde geldi.

Weblate, düzenli olarak yapılan arka plan görevlerini yerine getirmek için Celery kullanır. Bu işlemleri yapacak bir Celery hizmeti çalıştırmanız gerekiyor. Örnek olarak, aşağıdaki işlemlerin yapılır (bu liste tam değildir):

Dış hizmetlerden web kancalarını almak (bilgi almak için: Bildirim kancaları).
Yedeklemeler, temizlemeler, günlük eklentiler veya güncellemeler gibi düzenli bakım görevlerini çalıştırmak (bilgi almak için Weblate yedeğini alma ve taşıma, BACKGROUND_TASKS, Eklentiler).
Kendiliğinden çeviri çalıştırmak.
Toplu bildirimleri göndermek.
Yük oluşturan işlemleri wsgi işlemi üzerinden almak.
Bekleyen değişiklikleri göndermek (Bilgi almak için: Lazy commit işlemeleri).

Arka uçta Redis kullanan tipik bir kurulum şöyle görünür:

CELERY_TASK_ALWAYS_EAGER = False
CELERY_BROKER_URL = "redis://localhost:6379"
CELERY_RESULT_BACKEND = CELERY_BROKER_URL

Ayrıca bakınız

Celery içindeki Redis işleyici yapılandırması

Görevleri işlemek ve zamanlanmış görevleri başlatmak için Celery işlemini de başlatmalısınız. Bu işlem doğrudan komut satırından yapılabilir (genellikle hata ayıklama veya geliştirme sırasında yararlıdır):

./weblate/examples/celery start
./weblate/examples/celery stop

Not

Celery işlemini çalıştıran kullanıcı, WSGI işlemini çalıştıran kullanıcı ile aynı olmalıdır. Yoksa DATA_DIR klasöründeki dosyaların sahiplikleri karışır ve bu da çalışma sırasında sorunlara yol açar.

Ayrıca Dosya sistemi izinleri ve Sunucuyu çalıştırmak bölümlerine bakabilirsiniz.

Wsgi üzerinde Celery görevlerini yürütürken eager kipini kullanmak

Not

Bu seçeneğin kullanılmasının web arabirimi başarımı üzerinde ciddi etkisi olur ve normal tetikleyiciye bağlı olarak özellikleri bozar (bekleyen değişiklikleri gerçekleştirmek, özet bildirimleri veya yedeklemeler gibi).

Geliştirme ortamları için, tüm görevleri anında işleyen eager yapılandırmasını kullanmak isteyebilirsiniz:

CELERY_TASK_ALWAYS_EAGER = True
CELERY_BROKER_URL = "memory://"
CELERY_TASK_EAGER_PROPAGATES = True

Celery uygulamasını sistem hizmeti olarak çalıştırmak

Büyük olasılıkla celeri:userguide/daemonizing bölümünde anlatıldığı gibi bir Celery daemon çalıştırmak isteyeceksiniz. systemd kullanan en yaygın Linux kurulumu için, hazır gelen ve aşağıda listesi bulunan examples klasöründeki örnek dosyaları kullanabilirsiniz.

/etc/systemd/system/celery-weblate.service olarak yerleştirilecek systemd birimi:

[Unit]
Description=Celery Service (Weblate)
After=network.target

[Service]
Type=forking
User=weblate
Group=weblate
EnvironmentFile=/etc/default/celery-weblate
WorkingDirectory=/home/weblate
RuntimeDirectory=celery
RuntimeDirectoryPreserve=restart
LogsDirectory=celery
ExecStart=/bin/sh -c '${CELERY_BIN} multi start ${CELERYD_NODES} \
  -A ${CELERY_APP} --pidfile=${CELERYD_PID_FILE} \
  --logfile=${CELERYD_LOG_FILE} --loglevel=${CELERYD_LOG_LEVEL} ${CELERYD_OPTS}'
ExecStop=/bin/sh -c '${CELERY_BIN} multi stopwait ${CELERYD_NODES} \
  --pidfile=${CELERYD_PID_FILE}'
ExecReload=/bin/sh -c '${CELERY_BIN} multi restart ${CELERYD_NODES} \
  -A ${CELERY_APP} --pidfile=${CELERYD_PID_FILE} \
  --logfile=${CELERYD_LOG_FILE} --loglevel=${CELERYD_LOG_LEVEL} ${CELERYD_OPTS}'

[Install]
WantedBy=multi-user.target

/etc/default/celery-weblate olarak yerleştirilecek ortam yapılandırması:

# Name of nodes to start
CELERYD_NODES="celery notify memory backup translate"

# Absolute or relative path to the 'celery' command:
CELERY_BIN="/home/weblate/weblate-env/bin/celery"

# App instance to use
# comment out this line if you don't use an app
CELERY_APP="weblate.utils"

# Extra command-line arguments to the worker,
# increase concurrency if you get weblate.E019
CELERYD_OPTS="--beat:celery --queues:celery=celery --prefetch-multiplier:celery=4 \
    --queues:notify=notify --prefetch-multiplier:notify=10 \
    --queues:memory=memory --prefetch-multiplier:memory=10 \
    --queues:translate=translate --prefetch-multiplier:translate=4 \
    --concurrency:backup=1 --queues:backup=backup  --prefetch-multiplier:backup=2"

# Logging configuration
# - %n will be replaced with the first part of the nodename.
# - %I will be replaced with the current child process index
#   and is important when using the prefork pool to avoid race conditions.
CELERYD_PID_FILE="/run/celery/weblate-%n.pid"
CELERYD_LOG_FILE="/var/log/celery/weblate-%n%I.log"
CELERYD_LOG_LEVEL="INFO"

Celery günlüklerini döndürmek için logrotate komutu kullanılarak /etc/logrotate.d/celery olarak yerleştirilecek ek yapılandırma:

/var/log/celery/*.log {
        weekly
        missingok
        rotate 12
        compress
        notifempty
}

Celery atımını kullanarak görevleri zamanlamak

Weblate, hazır bir zamanlanmış görevler kurulumuyla gelir. Bununla birlikte, settings.py dosyasından ek görevler tanımlayabilirsiniz. Örnek olarak Lazy commit işlemeleri bölümüne bakabilirsiniz.

Görevlerin Celery beats daemon tarafından yürütülmesi gerekiyor. Beklendiği gibi çalışmıyorsa, daemon çalışmıyor veya veritabanı bozulmuş olabilir. Bu durumda temel sorunu bulmak için Celery başlangıç günlüklerine bakın.

Celery durumunu izlemek

Celery görev kuyruklarının geçerli uzunluğunu Yönetim arayüzü içinden ya da komut satırında celery_queues komutunu kullanarak görebilirsiniz. Kuyruğun çok uzaması durumunda, yönetici arayüzünde de yapılandırma hatası görürsünüz.

Uyarı

Celery hataları varsayılan olarak yalnızca Celery günlüğüne kaydedilir ve kullanıcı tarafından görülemez. Bu tür hataların özetini görmek istiyorsanız, Hata raporlarını derlemek seçeneğini yapılandırmanız önerilir.

Ayrıca bakınız

Weblate uygulamasını izlemek, How can I check whether my Weblate is set up properly?, Configuration and defaults, Workers Guide, Daemonization, Monitoring and Management Guide, celery_queues

Weblate uygulamasını izlemek

Weblate, örneğin Kubernetes gibi basit durum denetimlerinde kullanılmak üzere /healthz/ adresini sunar. Docker kapsayıcısında, bu adresi kullanan iç sistem durumu denetimi bulunur.

Weblate ölçümlerini izlemek için GET /api/metrics/ API uç noktasını kullanabilirsiniz.

Ayrıca bakınız

How can I check whether my Weblate is set up properly?, Celery durumunu izlemek, Munin için Weblate uygulama eki

Hata raporlarını derlemek

Weblate, diğer yazılımlar gibi sorun çıkarabilir. Yardımcı olabilecek sorun durumlarını derlemek için üçüncü taraf hizmetlerini kullanmanızı öneririz. Bu uygulama, özellikle Celery görevlerinin yapılamaması durumunda kullanışlıdır. Yoksa hata yalnızca günlüklere bildirilir ve bunlar hakkında bildirim almazsınız. Weblate tarafından desteklenen hizmetler şunlardır:

Sentry

Weblate, Sentry desteği sunar. Kullanmak için, settings.py dosyasında SENTRY_DSN seçeneğini ayarlamak yeterlidir:

SENTRY_DSN = "https://id@your.sentry.example.com/"

Rollbar

Weblate, Rollbar desteği sunar. Kullanmak için, Rollbar notifier for Python yönergelerini izlemek yeterlidir.

Özetle, settings.py dosyasını ayarlamanız gerekir:

# Add rollbar as last middleware:
MIDDLEWARE = [
    # … other middleware classes …
    "rollbar.contrib.django.middleware.RollbarNotifierMiddleware",
]

# Configure client access
ROLLBAR = {
    "access_token": "POST_SERVER_ITEM_ACCESS_TOKEN",
    "client_token": "POST_CLIENT_ITEM_ACCESS_TOKEN",
    "environment": "development" if DEBUG else "production",
    "branch": "main",
    "root": "/absolute/path/to/code/root",
}

Bunun dışındaki her şey kendiliğinden bütünleştirilmiştir. Artık hem sunucu hem de istemci tarafı hatalarını derleyebilirsiniz.

Weblate kurulumunu başka bir sunucuya aktarmak

Weblate kurulumunu başka bir sunucuya aktarmak oldukça kolaydır. Ancak veriler dikkatli bir şekilde aktarmanız gereken birkaç konumda bulunur. En iyi yaklaşım, aktarım sırasında Weblate kopyasını durdurmaktır.

Veri tabanını aktarmak

Veritabanı arka ucunuza bağlı olarak, veritabanını aktarmak için birkaç seçeneğiniz olabilir. En basit yaklaşım, genellikle en etkili araçlar olduklarından, veritabanının kendi araçlarını kullanmaktır (mysqldump ya da pg_dump gibi). Alternatif olarak, veritabanınızın desteklemesi durumunda çoğaltma (replication) özelliğini kullanabilirsiniz.

Ayrıca bakınız

Veri tabanları arasında aktarım Diğer veri tabanlarından PostgreSQL üzerine aktarım bölümünde açılanmıştır.

Sürüm denetimi sistemi depolarını aktarmak

DATA_DIR altına kaydedilmiş sürüm denetimi sistemi depolarının da taşınması gerekir. Aktarımı daha etkili bir şekilde yapmak için bunları kopyalayabilir ya da rsync komutunu kullanabilirsiniz.

Diğer notlar

Weblate tarafından kullanılıyor olabilecek, Redis, zamanlanmış Cron görevleri veya özel kimlik doğrulama arka uçları gibi diğer hizmetleri taşımayı unutmayın.