升级 Weblate

Docker 镜像升级

官方 Docker 镜像（请参见 使用 Docker 安装）已集成了所有 Weblate 升级步骤。除了拉取最新的版本外通常无需进行手动操作。

参见

升级 Docker 容器

一般的升级指示

在升级前，请检查当前的 软件要求，因为他们可能被更改。一旦所有的要求被安装或升级，请调整你的 settings.py，来匹配配置中的更改（正确的值请咨询 settings_example.py）。

升级前，请务必查阅 与特定版本相关的指示。如果您要跳过某些版本，请按照升级中要跳过的所有版本的说明进行操作。有时最好先升级到某个中间版本，以确保顺利迁移。跨越多个版本的升级应该是可行的，但不像单一版本的升级那样经过良好的测试。

备注

推荐在升级前执行全数据库备份，使你可以在升级失败的情况下回滚数据库，请参见 备份和移动 Weblate。

1. 停止 WSGI 和 Celery 进程。升级可能执行数据库的不兼容更改，因此在升级中避免旧的进程运行总是安全的。

2. 升级 Weblate 代码。

   对于 pip 安装，可以通过以下命令实现：

   pip install -U "Weblate[all]==version"
   

   或者，如果您只想获取最新发布的版本：

   pip install -U "Weblate[all]"
   

   如果不想安装所有可选依赖项，请执行以下操作：

   pip install -U Weblate
   

   通过 Git 核实，你需要取回新的源代码并升级你的安装：

   cd weblate-src
   git pull
   # Update Weblate inside your virtualenv
   . ~/weblate-env/bin/pip install -e .
   # Install dependencies directly when not using virtualenv
   pip install --upgrade -r requirements.txt
   # Install optional dependencies directly when not using virtualenv
   pip install --upgrade -r requirements-optional.txt
   

3. 新版本 Weblate 可能有新的 可选依赖项, 快来看看有没有你感兴趣的功能。

4. 升级配置文件，所需的步骤请参考 settings_example.py 或 与特定版本相关的指示。

5. 升级数据库架构：

   weblate migrate --noinput
   

6. 收集升级的静态文件（请参见 运行服务器 和 为静态文件提供服务）：

   weblate collectstatic --noinput --clear
   

7. 压缩 JavaScript 和 CSS 文件（可选步骤，请参见 压缩客户端资源 ）：

   weblate compress
   

8. 如果你运行来自 Git 的版本，每次升级时还应该重新生成 locale 文件。可以通过调用后面的来进行：

   weblate compilemessages
   

9. 验证您的设置合理（还请参见 生产设置）：

   weblate check --deploy
   

10. 重新启动 Celery worker（请参见 使用 Celery 的后台任务）。

与特定版本相关的指示

从 2.x 升级

如果从 2.x 发布版本升级，首先总是升级到 3.0.1，然后继续在 3.x 系列中升级。跳过这步的升级不被支持，并且会中断。

参见

Weblate 3.0 文档中关于从 2.20 升级到 3.0

从 3.x 升级

如果从 3.x 发布版本升级，首先总是升级到 4.0.4 或 4.1.1，然后继续在 4.x 系列中升级。跳过这步的升级不被支持，并且会中断。

参见

Weblate 4.0 文档中关于从 3.11 升级到 4.0

从 4.0 升级到 4.1

请按照 一般的升级指示 来执行升级。

显著的配置与依赖项更改：

• 在 settings_example.py 中有几项更改，最显著的是中间件的更改，请由此调整你的设置。

• 有几个新的文件格式，在修改 WEBLATE_FORMATS 的情况下，你会想要将他们包括进来。

• 有几个新的质量检查，在修改 CHECK_LIST 的情况下，你会想要将他们包括进来。

• 在 DEFAULT_THROTTLE_CLASSES 设置中有几项更改，来允许在 API 中报告速率限制。

• 有几个新的且更新的要求。

• 在 INSTALLED_APPS 中有一些更改。

• MT_DEEPL_API_VERSION 设置已在 V4.7 中移除, DeepL 机器翻译现在使用新的 MT_DEEPL_API_URL 代替,您可能需要调整 MT_DEEPL_API_URL 以匹配您的订阅。

参见

一般的升级指示

从 4.1 升级到 4.2

请按照 一般的升级指示 来执行升级。

显著的配置与依赖项更改：

• 从 3.x 发布版本升级不再支持，请首先升级到 4.0 或 4.1。

• 有几个新的且更新的要求。

• 在 settings_example.py 中有几项更改，最显著的是新中间件和更改的应用订购。

• 基于 JSON 格式的密钥是不再包括前导的点。在数据库迁移过程中调整字符串，但在你依赖于导出或 API 中的密钥时，外部部件会需要调整。

• Celery 配置更改，不再使用 memory 队列。请调整你的启动脚本和 CELERY_TASK_ROUTES 设置。

• 现在在设置中配置 Weblate 域，请参见 SITE_DOMAIN`（或 :envvar:`WEBLATE_SITE_DOMAIN）。在运行 Weblate 前你将不得不配置它。

• 用户数据库上的用户名和电子邮件字段现在应该不因为大小写敏感而不同。它之前错误地没有被 PostgreSQL 强制。

参见

一般的升级指示

从 4.2 升级到 4.3

请按照 一般的升级指示 来执行升级。

显著的配置与依赖项更改：

• 在质量检查中有一些更改，在你调整 CHECK_LIST 的情况下会想将他们包括进来。

• 源语言属性从项目移动到 API 中暴露的部件。在使用时你会需要更新 Weblate 客户端。

• 数据库迁移到 4.3 可能需要很长时间，取决于要翻译的字符串数（预计每 10 万条字符串大约需要 1 小时的迁移时间）。

• 在 INSTALLED_APPS 中有一些更改。

• 有个新的设置 SESSION_COOKIE_AGE_AUTHENTICATED，补充了 SESSION_COOKIE_AGE。

• 如果你使用 hub 或 lab 与 GitHub 或 GitLab 集成，则需要重新配置，请参见 GITHUB_CREDENTIALS 和 GITLAB_CREDENTIALS。

在 4.3.1 版本发生变更:

• Celery 配置更改，加入了 memory 队列。请调整你的启动脚本和 CELERY_TASK_ROUTES 设置。

在 4.3.2 版本发生变更:

• 附加组件的 post_update 方法现在接受额外的 skip_push 参数。

参见

一般的升级指示

从 4.3 升级到 4.4

请按照 一般的升级指示 来执行升级。

显著的配置与依赖项更改：

• 在 INSTALLED_APPS 中有一处更改，必须将 weblate.configuration 添加在那里。

• 现在需要 Django 3.1。

• 在使用 MySQL 或 MariaDB 的情况下，需要的最低版本提高了，请参见 MySQL 和 MariaDB。

在 4.4.1 版本发生变更:

• 单语 gettext 现在同时使用 msgid 和 ``msgctxt``（若存在）。这将改变此类文件中翻译字符串的标识，破坏到与 Weblate 扩展数据（如截图和审校状态）的链接。请确保在升级之前提交此类文件的待处理更改，建议使用 loadpo 强制加载受影响的部件。

• 增加了 translate-toolkit 的最低要求版本，以解决几个文件格式问题。

参见

一般的升级指示

从 4.4 升级到 4.5

请按照 一般的升级指示 来执行升级。

显著的配置与依赖项更改：

• 如果你的的术语表过大，迁移可能需要相当长的时间。

• 术语表现在存储为常规部件。

• 术语表 API 已移除，请使用常规翻译 API 访问术语表。

• INSTALLED_APPS 中有一处更改，应添加 weblate.metrics。

在 4.5.1 版本发生变更:

• pyahocorasick 模块有一个新的依赖项。

参见

一般的升级指示

从 4.5 升级到了 4.6

请按照 一般的升级指示 来执行升级。

显著的配置与依赖项更改：

• 有几个新的文件格式，在修改 WEBLATE_FORMATS 的情况下，你会想要将他们包括进来。

• 创建部件的 API 现在自动使用 Weblate 内部网址，参考 POST /api/projects/(string:project)/components/ 。

• 在依赖关系和 PASSWORD_HASHERS 中，有一个变化，即在密码散列中优先使用 Argon2。

参见

一般的升级指示

从 4.6 升级到了 4.7

请按照 一般的升级指示 来执行升级。

显著的配置与依赖项更改：

• 在 settings_example.py 中有几项更改，最显著的是中间件的更改(MIDDLEWARE)，请由此调整你的设置。

• mt-deepl`机器翻译现在有一个通用的 ``MT_DEEPL_API_URL` 设置，以更灵活地适应不同的订阅模式。MT_DEEPL_API_VERSION 设置不再使用。

• 现在需要 Django 3.2。

参见

一般的升级指示

从 4.7 升级到 4.8

请按照 一般的升级指示 来执行升级。

此版本中不需要额外的升级步骤。

参见

一般的升级指示

从 4.8 升级到 4.9

请按照 一般的升级指示 来执行升级。

• 存储指标有变化，在较大的站点上升级可能需要很长时间。

参见

一般的升级指示

从 4.9 升级到 4.10

请按照 一般的升级指示 来执行升级。

• 每个项目组有一个变化，在有成千上万个项目的网站上，升级可能需要很长的时间。

• Django 4.0 做了一些不兼容的改动，见 Backwards incompatible changes in 4.0。Weblate 仍然支持 Django 3.2，以防其中有问题。可能影响 Weblate 的最显著的变化：

  • 去掉了对 PostgreSQL 9.6 的支持，Django 4.0 支持 PostgreSQL 10 及以上版本。

  • CSRF_TRUSTED_ORIGINS 的格式已经改变。

• Docker 容器现在使用 Django 4.0，有关更改，请参见上文。

参见

一般的升级指示

从 4.10 升级到 4.11

请按照 一般的升级指示 来执行升级。

• Weblate 现在需要 Python 3.7 或更新版本。

• 管理每个项目的访问控制 的实现已经改变，从组名中删除了项目前缀。这影响到了 API 用户。

• Weblate 现在使用 charset-normalizer 而不是 chardet 模块来检测字符集。

• 4.11.1 更改： REST_FRAMEWORK 设置有一处改动 (删去了 DEFAULT_AUTHENTICATION_CLASSES 中的一个后端)。

参见

一般的升级指示

从 4.11 升级到 4.12

请按照 一般的升级指示 来执行升级。

• 无需特殊步骤。

参见

一般的升级指示

从 4.12 升级到 4.13

请按照 一般的升级指示 来执行升级。

• 语言定义 现在会在升级时自动更新，使用 UPDATE_LANGUAGES 来禁用它。

• 对 Windows RC 文件, HTML 文件, IDML 格式, 和 文本文件 文件格式的上下文和位置的处理已经改变.在大多数情况下，上下文现在被显示为位置。

• 机器翻译服务现在可以使用用户界面进行配置，配置文件中的设置将在数据库迁移期间导入。

参见

一般的升级指示

从 4.13 升级到 4.14

请按照 一般的升级指示 来执行升级。

• Java 格式检查现在匹配 GNU gettext 标记。Weblate 中设置的标记会自动迁移，但第三方脚本需要使用 java-printf-format 代替 java-format 和 java-format 代替 java-messageformat.

• jellyfish 依赖项已被 rapidfuzz 取代。

• 在 4.14.2 版中的变化： 弃用通过 _TOKEN/_USERNAME 配置而不是 _CREDENTIALS 列表对版本控制系统（VCS）服务 API 密钥进行不安全配置。在 Docker 中，请添加匹配的 _HOST 指令。示例参考 WEBLATE_GITHUB_HOST 和 GITHUB_CREDENTIALS。

参见

一般的升级指示

从 4.14 升级到 4.15

请按照 一般的升级指示 来执行升级。

• Weblate 现在需要 PostgreSQL 中的 btree_gin 扩展。如果具有足够的权限，迁移过程中将安装它。请参阅 创建 PostgreSQL 数据库 进行手动设置。

• 该 Docker 镜像不再默认启用调试模式。如果你想要它，使用 WEBLATE_DEBUG 在环境中启用。

• 由于要重新创建一些索引，数据库迁移在较大的实例上可能需要花费数小时。

• 在 4.15.1 版中发生改变: 更改了 rest 框架设置中 DEFAULT_PAGINATION_CLASS 的默认值。

参见

一般的升级指示

从 4.15 升级到 4.16

请按照 一般的升级指示 来执行升级。

• Celery beat 现在在数据库中保存任务计划，需要为此更改 CELERY_BEAT_SCHEDULER 和 INSTALLED_APPS。

• 不再支持已废弃的 VCS 凭据设置，见 从 4.13 升级到 4.14。

• 升级 django-crispy-forms 需要在 INSTALLED_APPS 中进行更改。

• django-cors-headers 集成需要在 INSTALLED_APPS 和 MIDDLEWARE 中做出更改。

参见

一般的升级指示

从 4.16 升级到了 4.17

请按照 一般的升级指示 来执行升级。

• 在较大的 Weblate 实例上迁移到重写的 metrics 存储可能耗费相当长的时间（每 GB 的 metrics_metric` 预计需要约15分钟）。为了减少实例下线时间，你可以将来自 Weblate 4.17 的 weblate/metrics/migrations/*.py 文件复制到 4.16，并在后台启动迁移。一旦完毕，请照常执行完整升级。

参见

一般的升级指示

从 Python 2 升级到 Python 3

Weblate 不再支持早于 3.6 版本的 Python。在仍然运行在较早版本的情况下，请首先在现有版本上执行到 Python 3 的迁移，并在后面进行升级。请参见 Weblate 3.11.1 文档中的从 Python 2 升级到 Python 3（英文） 。

从其它数据库迁移到 PostgreSQL

如果在 PostgreSQL 以外的数据库上运行 Weblate，你应该考虑迁移到 PostgreSQL，因为 Weblate 与它搭配表现最佳。后面的步骤将引导你在数据库之间迁移数据。请记住迁移前要停止 web 和 Celery 服务器，否则会导致不一致的数据。

创建 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 -D -P weblate

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

使用 Django JSON 转储来迁移

最简单的迁移方法是使用 Django JSON 转储。这对于较小的安装工作得很好。在更大的网站，你会想要使用 pgloader 代替，请参见 使用 pgloader 迁移到 PostgreSQL。

1. 将 PostgreSQL 作为附加数据库连接添加到 settings.py：

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": "database.example.com",
        # Set to empty string for default
        "PORT": "",
        # Additional database options
        "OPTIONS": {
            # In case of using an older MySQL server, which has MyISAM as a default storage
            # 'init_command': 'SET storage_engine=INNODB',
            # Uncomment for MySQL older than 5.7:
            # 'init_command': "SET sql_mode='STRICT_TRANS_TABLES'",
            # If your server supports it, see the Unicode issues above
            "charset": "utf8mb4",
            # Change connection timeout in case you get MySQL gone away error:
            "connect_timeout": 28800,
        },
    },
    "postgresql": {
        # Database engine
        "ENGINE": "django.db.backends.postgresql",
        # Database name
        "NAME": "weblate",
        # Database user
        "USER": "weblate",
        # Database password
        "PASSWORD": "password",
        # Set to empty string for localhost
        "HOST": "database.example.com",
        # Set to empty string for default
        "PORT": "",
    },
}

2. 运行迁移，并将任何插入到表格中的数据 drop 掉：

weblate migrate --database=postgresql
weblate sqlflush --database=postgresql | weblate dbshell --database=postgresql

3. 将遗留数据库进行转储，并导入 PostgreSQL

weblate dumpdata --all --output weblate.json
weblate loaddata weblate.json --database=postgresql

4. 调整 DATABASES 而只使用 PostgreSQL 数据库作为默认，将遗留连接删除掉。

现在 Weblate 应该准备好从 PostgreSQL 数据库运行了。

使用 pgloader 迁移到 PostgreSQL

pgloader 是通用迁移工具，将数据迁移到 PostgreSQL。你可以使用它来迁移 Weblate 数据库。

1. 调整 settings.py 文件而将 PostgreSQL 用作数据库。

2. 迁移 PostgreSQL 中的模式：

   weblate migrate
   weblate sqlflush | weblate dbshell
   

3. 运行 pgloader 来转移数据。后面的脚本可以用于迁移数据库，但你会想要学习更多关于 pgloader 的知识，来理解它做什么以及调整它来匹配你的设置：

   LOAD DATABASE
        FROM      mysql://weblate:password@localhost/weblate
        INTO postgresql://weblate:password@localhost/weblate
   
   WITH include no drop, truncate, create no tables, create no indexes, no foreign keys, disable triggers, reset sequences, data only
   
   ALTER SCHEMA 'weblate' RENAME TO 'public'
   ;
   

从 Pootle 迁移

由于 Weblate 最初是作为 Pootle 的替代品而编写的，因此支持从 Pootle 迁移用户账户。你可以从 Pootle 转储用户，并使用 importusers 将其导入。