配置手册¶
软件要求¶
操作系统¶
Weblate 已知运行在 Linux 、 FreeBSD 和 macOS 上。其他类 Unix 的系统也很可能支持运行。
Windows 不支持 Weblate 。但仍然可能工作,并愿意接受补丁。
其他服务¶
Weblate 为其操作使用其他服务。至少需要后面的服务运行:
PostgreSQL 数据库服务器,请参见 Weblate 的数据库设置 。
Redis 服务器,用于缓存和任务队列,请参见 使用 Celery 的后台任务 。
SMTP 服务器,用于发送电子邮件,请参见 配置电子邮件发件箱 。
Python 依赖性¶
Weblate 用 Python 编写,并且支持 Python 3.6 或更新版本。可以使用 pip 或你的发布包来安装依赖性,完全列表可在 requirements.txt
中找到。
最重要的依赖性:
- Django
- Celery
- Translate Toolkit (翻译工具包)
- translation-finder
- Python Social Auth
- Django REST 框架
可选依赖性¶
后面的模块对 Weblate的一些特性是必须的。可以在 requirements-optional.txt
中找到。
Mercurial
(对 Mercurial 仓库支持是可选的)phply
(对 PHP 支持是可选的)tesserocr
(对截屏 OCR 是可选的)akismet
(对建议垃圾邮件保护是可选的)ruamel.yaml
(对 YAML files 是可选的)Zeep
(对 Microsoft Terminology Service 是可选的)aeidon
(对 Subtitle files 是可选的)
数据库后端依赖性¶
Weblate 支持 PostgreSQL 、 MySQL 和 MariaDB 数据库,更多细节请参见 Weblate 的数据库设置 和后端文件。
其他系统要求¶
后面的依赖性必须安装在系统上:
Git
- Pango 、 Cairo 和相关的头文件与 gir introspection 数据
https://cairographics.org/ , https://pango.gnome.org/ ,请参见 Pango 和 Cairo
git-review
(对 Gerrit 支持是可选的)git-svn
(对 Subversion 支持是可选的)tesseract
及其数据(对截屏 OCR 是可选的)licensee
(当新建组件时可选用与删除许可)
编译时间依赖性¶
为了编译一些 Python 依赖性 ,会需要安装其依赖性。这依赖于如何安装它们,因此请每个独立包的文件。如果使用 pip
安装或使用发布包而使用预编译的 Wheels
时不会需要那些。
Pango 和 Cairo¶
在 3.7 版更改.
Weblate 使用 Pango 和 Cairo 来提供位图 widget(请参参见 Promoting the translation )并提供检查(请参见 管理字型 )。为了适当地安装 Python 绑定需要首先安装系统库的那些—— Cairo 和 Pango 都是需要的,由此需要 Glib 。所有那些需要与开发文件和 GObject 内省数据一起安装。
验证发布签名¶
Weblate 的发布由发布开发者通过密码签发。当前是 Michal Čihař 。他的 PGP 密钥指纹是:
63CB 1DF1 EF12 CF2A C0EE 5A32 9C27 B313 42B7 511D
并且可以从 <https://keybase.io/nijel> 得到更多识别信息。
应该验证签名与下载的压缩档案匹配。这种方式可以确保你使用发布的相同编码。还应该核实签名的日期,确定下载了最新的版本。
每个压缩档案伴随 .asc
文件在一起,它包含了需要使用的 PGP 签名。一旦它们处于相同的文件夹内,就可以验证签名了:
$ 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
正如你所看到的,GPG抱怨它不知道公钥。此时应该执行以下步骤之一:
使用 wkd 来下载密钥:
$ 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’s server 下载钥匙链,然后将其导入:
$ gpg --import wmxth3chu9jfxdxywj1skpmhsj311mzm
从一个密钥服务器下载并导入密钥:
$ 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
这会将情况改善一点——在这点上可以验证给定密钥的签名是正确的,但仍然不能相信密钥中使用的名称:
$ 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
这里的问题是任何人可以以这个名称发布密钥。需要确定密钥实际由提到的人所有。GNU 隐私手册在 Validating other keys on your public keyring (‘在你的公共钥匙链上验证其它密钥’)章节涵盖了这个题目。最可靠的方法是与开发者的真人真实交流,并交换密钥指纹,然后还可以依赖于可信任的 Web 。这种方式你可以信任通过其他签名的密钥,而其他人必须接触开发者真人。
一旦信任了密钥,警告就不会发生:
$ 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]
如果签名非法(压缩的档案被更改),那么会得到清晰的错误,而无论密钥是否可信:
$ 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]
文件系统权限¶
Weblate 过程需要能够读取并写入保存数据的文件夹—— DATA_DIR
。文件夹内的所有文件应该被用户运行的 Weblate 所有并可写入。
默认的配置放置在 Weblate 源的相同树下,然而你会想要将这些移动到更好的位置,如: /var/lib/weblate
。
Weblate 试图自动建立这些文件夹,但当没有权限去执行时会失败。
当运行 管理命令 时应该小心,它们应该由 Weblate 自己运行的相同用户来运行,否则一些文件的权限会是错误的。
在 Docker 容器中, /app/data
卷中的所有文件必须由容器内的 Weblate 用户(UID 1000)所有。
参见
Weblate 的数据库设置¶
推荐使用 PostgreSQL 数据库服务器来运行 Weblate。
PostgreSQL¶
PostgreSQL 通常是基于 Django 的网站的最好选择。它是实现 Django 数据库层而使用的参考数据库。
注解
Weblate 使用三字母的扩展名,在某些情况下需要单独安装。查找 postgresql-contrib
或类似命名的包。
建立 PostgreSQL数据库¶
在另一个单独的数据库中运行 Weblate ,并将用户账户分开通常是个好方法:
# 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 -O weblate weblate
提示
如果不想 Weblate 在 PostgreSQL 中使用超级用户,可以省略掉。在模式中必须作为 PostgreSQL 超级用户,来手动执行一些迁移步骤的情况下, Weblate 将使用:
CREATE EXTENSION IF NOT EXISTS pg_trgm WITH SCHEMA weblate;
配置 Weblate 来使用 PostgreSQL¶
PostgreSQL 的 settings.py
片段:
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": "",
}
}
迁移代码假定角色名称与身份验证时使用的用户名匹配,在不匹配的情况下,请设置``ALTER_ROLE``。否则会在数据库迁移过程中得到惧色不存在的 PostgreSQL 错误(psycopg2.errors.UndefinedObject: role "weblate@hostname" does not exist
)。
MySQL 和 MariaDB¶
Weblate 还可以使用 MySQL 或 MariaDB ,使用与两个数据库相关的 Django 而导致的警告,请参见 MySQL notes 和 MariaDB notes 。
提示
一些 Weblate 特性使用 PostgreSQL 会执行得更好。这包括搜索与翻译记忆,它们都使用了数据库中的全文本特性,而 PostgreSQL 的实施更胜一筹。
因此,在新的安装时推荐使用 PostgreSQL 。
推荐 Weblate 使用后面的设置:
使用
utf8mb4
字符集来允许表示更高的 Unicode 平面(例如 emojis 表情符号)。用
Innodb_large_prefix
配置服务器,来允许文本字段上更长的标记体。设置隔离级别为
READ COMMITTED
。SQL 模式应该设置为
STRICT_TRANS_TABLES
。
其他配置¶
配置电子邮件发件箱¶
Weblate 在各种情况下会发出电子邮件——用于激活账户,以及用户配置的各种通知。对于这些需要访问 SMTP 服务器。
使用这些设置: EMAIL_HOST
、 EMAIL_HOST_PASSWORD
、 setting:django:EMAIL_HOST_USER 和 EMAIL_PORT
来配置邮件服务器的设置。其名称都是自我解释的,也可以在 Django 文件中找到更多信息。
注解
可以通过使用 sendtestemail
管理命令(关于在不同环境中如何调用它的指示说明请参见 调用管理命令 ),来验证电子邮件发件箱是否正确工作。
在反向代理后面运行¶
Weblate 的几个特性依赖于能够得到客户端 IP 地址。这包括 频次限制 、 针对垃圾邮件的保护 或 审计日志。
在默认设置中, Weblate 从 WSGI 句柄设置的 REMOTE_ADDR
中解析 IP 地址。
在运行反向代理的情况下,这个字段很可能包含其地址。需要配置 Weblate 来信任附加的 HTTP 标头,并从中解析 IP 地址。这不能默认允许,因为在不使用反向代理的安装时,这会允许 IP 地址欺骗。允许 IP_BEHIND_REVERSE_PROXY
对多数常见设置就足够了,但你还必须调整 IP_PROXY_HEADER
和 IP_PROXY_OFFSET
。
HTTP 代理¶
Weblate 执行版本控制系统(VCS )命令,并且那些从环境中接受代理配置。推荐的方法是在 settings.py
中定义代理设置:
import os
os.environ['http_proxy'] = "http://proxy.example.com:8080"
os.environ['HTTPS_PROXY'] = "http://proxy.example.com:8080"
调整配置¶
参见
将 weblate/settings_example.py
复制到 weblate/settings.py
,并且调整它与你的设置匹配。你可能想要调整后面的选项:
ADMINS
网站管理者的列表,当发生故障时它们接收通知,例如合并失败或 Django 错误的通知。
参见
ALLOWED_HOSTS
需要设置这个,来列出你的网站支持服务的主机。例如:
ALLOWED_HOSTS = ['demo.weblate.org']另外可以包括通配符:
ALLOWED_HOSTS = ['*']
SESSION_ENGINE
配置如何存储会话。在保持默认的数据库后端引擎的情况下,应该安排 weblate clearsessions 从数据库中删除旧的会话。
如果使用 Redis 作为缓存(请参见 允许缓存 ),推荐也使用它作为会话:
SESSION_ENGINE = 'django.contrib.sessions.backends.cache'
DATABASES
到数据库服务器的连接性,细节请查看 Django 的文件。
DEBUG
对于任何生产服务器禁止这项。允许调试模式时, Django 会在出错的情况下向用户显示回溯信息,当禁止时,错误会根据电子邮箱发送到
ADMINS
(请参见上面)。调试模式还使 Weblate 变慢,因为在这种情况下 Django 内部存储了非常多的信息。
参见
DEFAULT_FROM_EMAIL
用于发送电子邮件的电子邮件发件人地址,例如注册电子邮箱。
SECRET_KEY
Django 使用的密钥,用于在 cookie 中登录一些信息,更多信息请参见 Django 密钥 。
参见
SERVER_EMAIL
用作向管理员发送电子邮件的发送者地址的邮箱,例如通知失败的合并。
参见
填满数据库¶
在配置准备好之后,可以运行 weblate migrate
来建立数据库结构。现在你将能够使用管理界面建立翻译项目。
在想要非交互式地运行安装的情况下,可以使用 weblate migrate --noinput
,然后使用 createadmin
命令来建立管理用户。
一旦完成,你将可以在管理界面检查 Performance report ,它会提示你网站上潜在的非最优的配置。
生产设置¶
对于生产设置,可以进行后面的章节中描述的调整。最严格的设置将触发警告,如果超级用户登录的话,警告由顶部条的感叹标记来指示:
同样也推荐查看由 Django 触发的检查(尽管可能不需要修复所有的检查):
weblate check --deploy
禁止调试模式¶
禁止 Django 的调试模式( DEBUG
):
DEBUG = False
在调试模式打开时,Django 存储所有执行的查询,并将错误的回溯显示给用户,这在生产设置中是不需要的。
参见
是当地配置管理设置¶
将正确的管理地址设置到 ADMINS
设置中,来确定服务器出现一些故障时谁接收电子邮件,例如:
ADMINS = (
('Your Name', 'your_email@example.com'),
)
参见
设置正确的网站域名¶
在管理界面调整网站名称和域名,否则 RSS 中的链接或注册电子邮件地址将不工作。这使用 SITE_DOMAIN
来配置,它应该包含网站域名。
在 4.2 版更改: 在 4.2 版本之前,替代使用了 Django 网站框架,请参见 The “sites” framework 。
正确配置 HTTPS¶
强烈推荐使用加密的 HTTPS 协议 运行 Weblate。将其允许后,可以在设置中设置 ENABLE_HTTPS
:
ENABLE_HTTPS = True
提示
你还会想要新建 HSTS,更多细节请参见 SSL/HTTPS 。
参见
适当设置 SECURE_HSTS_SECONDS¶
如果你的网站基于 SSL 上提供服务,那么必须考虑 settings.py
中 SECURE_HSTS_SECONDS
的设置值,来允许 HTTP Strict Transport Security ( HTTP 脚本传输安全)。默认设置为 0 ,如下所示。
SECURE_HSTS_SECONDS = 0
如果设置为非 0 整数,那么在所有还不曾具有它的响应时, django.middleware.security.SecurityMiddleware
设置 HTTP Strict Transport Security 标头。
警告
不正确地设置这项会导致你的网站不可逆地(有时)崩溃。请首先阅读 HTTP Strict Transport Security 文件。
使用强力的数据库引擎¶
请使用 PostgreSQL 作为生产环境,更多信息请参见 Weblate 的数据库设置 。
允许缓存¶
如果可能,通过调整 CACHES
配置变量来使用来自 Django 的 Redis ,例如:
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',
}
}
}
头像缓存¶
除了 Django 的缓存, Weblate 还执行头像缓存。推荐使用单独的、文件后端缓存来用于这个目的:
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,
},
}
配置电子邮件发送的设置¶
Weblate 需要在几种情况下发送电子邮件,这些电子邮件应具有正确的发送者地址,请配置:setting:SERVER_EMAIL 和 DEFAULT_FROM_EMAIL
,与你的环境匹配,例如:
SERVER_EMAIL = 'admin@example.org'
DEFAULT_FROM_EMAIL = 'weblate@example.org'
注解
为了禁止 Weblate 发送电子邮件,将 EMAIL_BACKEND
设置为 django.core.mail.backends.dummy.EmailBackend
。
这将禁止 所有 电子邮件的投递,包括注册或密码重置电子邮件。
允许主机设置¶
Django 需要 ALLOWED_HOSTS
保存你的网站允许服务的域名列表,将其保持空置会屏蔽任何请求。
在没有配置来匹配 HTTP 服务器的情况下,会得到错误信息,如 Invalid HTTP_HOST header: '1.1.1.1'. You may need to add '1.1.1.1' to ALLOWED_HOSTS.
提示
在 Docker 容器上,这可以使用,为 WEBLATE_ALLOWED_HOSTS
。
Django 密钥¶
SECRET_KEY
设置由 Django 使用来进行 cookies 签名,应该真正产生自己的值,而不是使用来自举例的设置的值。
可以使用与 Weblate 一起上市的 weblate/examples/generate-secret-key
, 来产生新的密钥。
参见
Home 目录¶
在 2.1 版更改: 这不再需要了, Weblate现在将所有数据存储在 DATA_DIR
。
给用户运行 Weblate 的主目录应该存在,并且可以被这个用户写入。如果想要使用 SSH 来访问私有仓库,这是特别重要的,但 Git 也会需要访问这个目录(依赖于你使用的 Git 版本)。
可以在 settings.py
中更改 Weblate 使用的目录,例如,将其设置到 Weblate 树下面的 configuration
目录中:
os.environ['HOME'] = os.path.join(BASE_DIR, 'configuration')
注解
在 Linux 和其他类似 UNIX 系统上,到用户主目录的路径在 /etc/passwd
中确定。很多发布默认用户使用不可写入目录来提供 Web 内容服务(如 apache
、 www-data
或 wwwrun
)。
模板加载¶
对于 Django 推荐使用缓存模板的加载程序。它将已分析的模板装入,并避免对每个单独的请求多进行分析。可以使用后面的模板来配置它(这里 loaders
设置很重要):
TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
'DIRS': [
os.path.join(BASE_DIR, 'templates'),
],
'OPTIONS': {
'context_processors': [
'django.contrib.auth.context_processors.auth',
'django.template.context_processors.debug',
'django.template.context_processors.i18n',
'django.template.context_processors.request',
'django.template.context_processors.csrf',
'django.contrib.messages.context_processors.messages',
'weblate.trans.context_processors.weblate_context',
],
'loaders': [
('django.template.loaders.cached.Loader', [
'django.template.loaders.filesystem.Loader',
'django.template.loaders.app_directories.Loader',
]),
],
},
},
]
运行维护任务¶
为了优化性能,在后台运行一些维护任务是个好方法。现在这由 使用 Celery 的后台任务 自动进行,并且包括后面的任务:
配置健康性的检查(每小时)。
进行挂起更改(每小时),请参见 惰性提交 和
commit_pending
。更新组件警告(每天)。
更新远程分支(每晚),请参见
AUTO_UPDATE
。翻译记忆备份到 JSON (每天),请参见
dump_memory
。全文本和数据库维护任务(每天和每周任务),请参见
cleanuptrans
。
在 3.2 版更改: 从 3.2 版本开始,执行这些任务的默认方式是使用 Celery ,并且 Weblate 已经具有一些适当的配置,请参见 使用 Celery 的后台任务 。
系统的地区与编码¶
系统的地区应该设置为兼容 UTF-8 的。在多数 Linux 发布中这是默认的设置。在你的系统不能兼容的情况下,请将地区更改为 UTF-8 变体。
例如通过编辑 /etc/default/locale
并设置 LANG="C.UTF-8"
。
在一些情况下,各个服务对不同的地区具有不同的设置。例如当使用 Apache 时,你会想要在 /etc/apache2/envvars
中设置它:
export LANG='en_US.UTF-8'
export LC_ALL='en_US.UTF-8'
使用定制的证书授权¶
Weblate 在 HTTP 请求时验证 SSL 证书。在使用 定制的证书授权的情况下,这样定制的证书授权在默认 bundles 的中不被信任,你必须将其证书添加为可信任。
倾向使用的方法是在系统层次进行,更多细节请查看你的发布的文件(例如在 debian 中,这可以通过将 CA 证书放置在 /usr/local/share/ca-certificates/
,并运行 update-ca-certificates 来完成)。
一旦完成,系统工具就会信任证书,这包括 Git 。
对于 Python 代码,需要配置请求来使用系统 CA bundle,而不是与它一起上市的那个。这可以通过将后面的模板放到 settings.py
来实现(路径是 Debian 特有的):
import os
os.environ["REQUESTS_CA_BUNDLE"] = "/etc/ssl/certs/ca-certificates.crt"
压缩客户资产¶
Weblate 带有一组 JavaScript 和 CSS 文件。由于性能的原因,在将其发送到客户端前最好进行压缩。在默认配置中,这通过耗费一点经常资源而在运行中完成。在大型安装中,推荐允许离线压缩模式。这需要在配置中完成,并且必须在每次 weblate 升级时触发压缩。
配置切换很简单,通过允许 django.conf.settings.COMPRESS_OFFLINE
,并配置 django.conf.settings.COMPRESS_OFFLINE_CONTEXT
(后者已经包括在例子的配置中):
COMPRESS_OFFLINE = True
在每个部署中,您需要压缩文件来匹配当前的版本:
weblate compress
提示
官方 Docker 镜像已经允许了这个特性。
运行服务器¶
需要几个服务来运行Weblate,推荐的设置包括:
数据库服务器(请参见 Weblate 的数据库设置 )
缓存服务器(请参见 允许缓存 )
用于静态文件和终结 SSL 的前端 web 服务器(请参见 为静态文件提供服务 )
用于动态内容的 Wsgi 服务器(请参见 NGINX 和 uWSGI 的配置例子 )
用于执行后台任务的 Celery (请参见 使用 Celery 的后台任务 )
注解
这些服务之间由一些依赖性,例如当启动 Celery 或 uwsgi 进程时,缓存和数据库应该运行。
在多数情况下,需要在单一(虚拟)服务器上运行所有服务,但在您的安装是重载的情况下,可以将这些服务拆开。对此的唯一限制是 Celery 和 Wsgi 服务器需要访问 DATA_DIR
。
运行 web 服务器¶
运行 Weblate 与运行其他任何基于 Django 的程序没什么不同。 Django通常作为 uWSGI 或 fcgi 执行(请参见下面不同 web 服务器的例子)。
为了检测的目的,您可以在 Django 中使用内建的 web 服务器:
weblate runserver
警告
在生产设置中不要使用这个服务器。它还没有通过安全审查或性能检测。还请参见 runserver
上的 Django 文件。
提示
Django 内建服务只通过允许 DEBUG
来为静态文件提供服务,因为它只用于开发的目的。对于生产使用,请参见 NGINX 和 uWSGI 的配置例子 、 Apache 的配置例子 Apache 和 Gunicorn 的配置例子 和 为静态文件提供服务 中的wsgi 设置。
为静态文件提供服务¶
在 2.4 版更改: 在 2.4 版本之前, Weblate 不能正常使用 Django 静态文件框架,并且设置更复杂。
Django 需要将其静态文件收集在一个单一文件夹中。为此,执行 weblate collectstatic --noinput
。这会将静态静态文件复制到 STATIC_ROOT
设置指定的文件夹中(这默认为 DATA_DIR
内的 static
文件夹)。
推荐直接从你的 web 服务器为静态文件提供服务,对于后面的路径应该使用它:
/static/
为 Weblate 的静态文件和 管理界面(由
STATIC_ROOT
定义)提供服务。/media/
用于上传用户媒体(例如截屏)。
/favicon.ico
应该重写,重写规则为
/static/favicon.ico
提供服务。
内容安全政策¶
默认的 Weblate 配置允许 weblate.middleware.SecurityMiddleware
中间件,它设置与 HTTP 标头相关的安全,如 Content-Security-Policy
或 X-XSS-Protection
。这些被默认新建,与 Weblate 及其配置一起工作,但这对你的环境需要定制化。
NGINX 和 uWSGI 的配置例子¶
为了运行生产 web 服务器,使用与 Weblate 一起安装的 wsgi 封装(在虚拟 env 的情况下,它安装为 ~/weblate-env/lib/python3.7/site-packages/weblate/wsgi.py
)。别忘了将 Python 的搜索路径同样设置为 您的虚拟 env (例如在 uWSGI 中使用 virtualenv = /home/user/weblate-env
)。
后面的配置将 Weblate 作为 NGINX web 服务器下的 uWSGI 来运行。
NGINX 的配置(还作为 weblate/examples/weblate.nginx.conf
来获得):
# This example assumes Weblate is installed in virtualenv in /home/weblate/weblate-env
# and DATA_DIR is set to /home/weblate/data, please adjust paths to match your setup.
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 的配置(还作为 weblate/examples/weblate.uwsgi.ini
来获得):
# This example assumes Weblate is installed in virtualenv in /home/weblate/weblate-env
# and DATA_DIR is set to /home/weblate/data, please adjust paths to match your setup.
[uwsgi]
plugins = python3
master = true
protocol = uwsgi
socket = 127.0.0.1:8080
wsgi-file = /home/weblate/weblate-env/lib/python3.7/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
Apache 的配置例子¶
后面的配置将 Weblate 作为 WSGI 来运行,您需要允许 mod_wsgi (作为 weblate/examples/apache.conf
来获得):
#
# VirtualHost for Weblate
#
# This example assumes Weblate is installed in virtualenv in /home/weblate/weblate-env
# and DATA_DIR is set to /home/weblate/data, please adjust paths to match your setup.
#
<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
WSGIProcessGroup weblate
WSGIApplicationGroup %{GLOBAL}
WSGIScriptAlias / /home/weblate/weblate-env/lib/python3.7/site-packages/weblate/wsgi.py process-group=weblate
WSGIPassAuthorization On
<Directory /home/weblate/weblate-env/lib/python3.7/site-packages/weblate/>
<Files wsgi.py>
Require all granted
</Files>
</Directory>
</VirtualHost>
注解
Weblate 需要 Python 3 ,所以请确认您运行 modwsgi 的 Python 3 变体。它通常作为独立的包来获得,例如 libapache2-mod-wsgi-py3
。
Apache 和 Gunicorn 的配置例子¶
后面的配置在 Gunicorn 和 Apache 2.4 中运行 Weblate (作为 weblate/examples/apache.gunicorn.conf
获得):
#
# VirtualHost for Weblate using gunicorn on localhost:8000
#
# This example assumes Weblate is installed in virtualenv in /home/weblate/weblate-env
# and DATA_DIR is set to /home/weblate/data, please adjust paths to match your setup.
#
<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>
在路径下运行 Weblate¶
在 1.3 版更改: 从 Weblate 1.3 开始支持。
为``/weblate`` 下的 Weblate 提供服务的 Apache 配置的例子。再次使用 mod_wsgi (还作为 weblate/examples/apache-path.conf
获得):
#
# VirtualHost for Weblate, running under /weblate path
#
# This example assumes Weblate is installed in virtualenv in /home/weblate/weblate-env
# and DATA_DIR is set to /home/weblate/data, please adjust paths to match your setup.
#
<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
WSGIProcessGroup weblate
WSGIApplicationGroup %{GLOBAL}
WSGIScriptAlias /weblate /home/weblate/weblate-env/lib/python3.7/site-packages/weblate/wsgi.py process-group=weblate
WSGIPassAuthorization On
<Directory /home/weblate/weblate-env/lib/python3.7/site-packages/weblate/>
<Files wsgi.py>
Require all granted
</Files>
</Directory>
</VirtualHost>
此外,您必须调整 weblate/settings.py
:
URL_PREFIX = '/weblate'
使用 Celery 的后台任务¶
3.2 新版功能.
Weblate 使用 Celery 来处理后台任务。设置例子与紧急配置在一起,它在通常的位置处理所有任务,但您会针对生产设置想要将其更改为更合理的内容。
使用 Redis 作为后端的典型设置看起来像这样:
CELERY_TASK_ALWAYS_EAGER = False
CELERY_BROKER_URL = 'redis://localhost:6379'
CELERY_RESULT_BACKEND = CELERY_BROKER_URL
您应该启动 Celery worker 来处理任务,并且定时任务,这可以直接在命令行完成(调试和开发时最有用):
./weblate/examples/celery start
./weblate/examples/celery stop
运行 Celery 作为系统服务¶
您更可能想要运行 Celery 作为守护进程,这由 Daemonization 来涵盖。对于使用 systemd 的最通常的 Linux 设置,您可以使用与下面列出的 examples
文件夹一起上市的例子文件。
Systemd 单元作为 /etc/systemd/system/celery-weblate.service
放置:
[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
放置:
# 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 concurency 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="/var/run/celery/weblate-%n.pid"
CELERYD_LOG_FILE="/var/log/celery/weblate-%n%I.log"
CELERYD_LOG_LEVEL="INFO"
# Internal Weblate variable to indicate we're running inside Celery
CELERY_WORKER_RUNNING="1"
Logrotate 配置作为 /etc/logrotate.d/celery
放置:
/var/log/celery/*.log {
weekly
missingok
rotate 12
compress
notifempty
}
注解
Celery 进程必须在相同的用户下作为 Weblate 和 WSGI 进程执行,否则 DATA_DIR
中的文件将以混合的所有权来存储,导致运行问题。
使用 Celery beat 的周期性任务¶
Weblate 带有内建的定时任务设置。然而您可以在 settings.py
中定义另外的任务,例如请参见 惰性提交 。
任务应该由 Celery beats 守护进程执行。在不能正常工作的情况下,它可能不会运行,或者其数据库崩溃。在这样的情况下检查 Celery 启动日志,来找出根本原因。
监测 Celery 状态¶
可以使用 celery_queues
来查看当前 Celery 任务队列的长度。在队列太长的情况下,会在管理界面得到配置错误。
警告
Celery 错误默认之存储在 Celery 日志中,并且用户不可见。在您想要了解故障概况的情况下,推荐配置 收集错误报告 。
监测 Weblate¶
Weblate 提供 /healthz/
URL 作为简单的健康检查来使用,例如使用 Kubernetes 。
收集错误报告¶
与其他任何软件一样,Weblate 可能会失败。为了收集有用的故障状态,我们推荐使用第三方服务来收集此类信息。这在 Celery 任务失败的情况下尤其有用,否则将只会向日志报告错误,而您不会收到有关它们的通知。Weblate 支持以下服务:
Sentry¶
Weblate 内置了对 Sentry 的支持。要使用它,只需在 settings.py
中设置 SENTRY_DSN
:
SENTRY_DSN = "https://id@your.sentry.example.com/"
Rollbar¶
Weblate 具有对 Rollbar 的内置支持。要使用它,只需遵循 Rollbar notifier for Python 的说明即可。
简而言之,您需要调整 settings.py
:
# 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': 'master',
'root': '/absolute/path/to/code/root',
}
其他所有内容都是自动集成的,您现在将同时收集服务器和客户端错误。
将 Weblate 迁移到其他服务其中¶
将 Weblate 迁移到其他服务器应该非常简单,然而它将数据存储在几个位置,您应该小心迁移。最佳的方式时停止 Weblate 再迁移。
迁移数据库¶
依赖于您的数据库后端,会有几个选项来迁移数据库。最直接的是将数据库转储到一个服务器上,并将它导入新的服务器中。另外,在数据库支持的情况下可以使用数据库复制。
最好的方式是使用数据库自带工具,因为它们通常最有效(例如 mysqldump 或 pg_dump )。如果您想要在不同的数据库之间迁移,唯一的选项恐怕是使用 Django 管理来转储并导入数据库:
# Export current data
weblate dumpdata > /tmp/weblate.dump
# Import dump
weblate loaddata /tmp/weblate.dump
其他注释¶
不要忘记移动 Weblate 会使用的其他服务,如 Redis 、 Cron 任务或定制的身份验证后端。