Дополнительные модули Weblate

Для вашей установки доступно несколько дополнительных модулей.

Экспортер Git

Предоставляет доступ на чтение к нижележащему репозиторию Git через HTTP(S).

Установка

  1. Добавьте weblate.gitexport в установленные приложения в файле settings.py:

    INSTALLED_APPS += ("weblate.gitexport",)

  2. Экспортируйте существующие репозитории, выполнив перено своей базы данных после установки:

    weblate migrate

Подсказка

Git-экспортёр включён в нашем официальном образе Docker. Чтобы отключить его, используйте:

WEBLATE_REMOVE_APPS=weblate.gitexport

Использование

Модуль автоматически внедряется в Weblate и устанавливает URL-адрес экспортируемого репозитория в Настройки компонента. Репозитории доступны в части /git/ URL-адреса Weblate, например https://example.org/git/weblate/main/.

Репозитории для проектов, доступных публично, могут быть клонированы без авторизации:

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

Доступ к просмотру репозиториев с ограниченным доступом (с Private access control или когда REQUIRE_LOGIN включён) требует токен API, который можно получить в вашем user profile:

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

Примечание

Weblate обслуживает сам репозиторий Git, но не обслуживает объекты Git LFS. См. Git LFS для поддерживаемого поведения. Клонируйте репозитории с использованием Git LFS из вышестоящего репозитория и добавьте Weblate как другой удалённый репозиторий. Если вам нужны только файлы, отслеживаемые Git, вы можете клонировать из Weblate с GIT_LFS_SKIP_SMUDGE=1, чтобы пропустить загрузку объектов Git LFS.

Подсказка

По умолчанию члены группы Пользователи и анонимные пользователи имеют доступ к репозиториям публичных проектов через роли Доступ к репозиторию и Опытный пользователь.

Выставление счетов

Этот модуль используется на Облачном хостинге Weblate, для задания тарифных планов, а также отслеживания платежей и лимитов.

Установка

Добавьте weblate.billing в установленные приложения в файле settings.py:

INSTALLED_APPS += ("weblate.billing",)

  1. Запустите миграцию базы данных для необязательной установки для модуля дополнительных структур базы данных:

weblate migrate

Создание и назначение тарифного плана

Сначала вам нужно создать тарифный план, чтобы активировать биллинг. Перейдите в раздел Администрирование (обозначен значком гаечного ключа) и откройте экран Инструменты. Оттуда перейдите в Интерфейс администратора Django.

В интерфейсе администратора Django найдите раздел BILLING и добавьте тарифный план. Например, вы можете добавить бесплатный план Free.

Если вы хотите назначить тарифный план существующему проекту, это также можно сделать в Интерфейсе администратора Django с помощью параметра Customer billings.

Наконец, Интерфейс администратора Django предоставляет параметр Invoice для регистрации платежей ваших клиентов.

Использование

После установки вы можете управлять биллингом в интерфейсе администратора. Пользователи с включённым биллингом получат новую вкладку Billing в своём Профиль пользователя.

Модуль тарифных планов также позволяет пользователям создавать новые проекты и компоненты без прав суперпользователя (см. Добавление проектов и компонентов перевода). Это возможно при выполнении следующих условий:

  • Тариф не исчерпал заданные лимиты (любое избыточное использование ресурсов влечёт блокировку создания проектов/компонентов) и оплачен (если он не бесплатный)

  • Пользователь имеет разрешение Добавление проектов в рабочее пространство для рабочего пространства, охваченного тарифным планом.

При создании проекта пользователь может выбрать, в каком рабочем пространстве должен находиться проект. Проекты, созданные в рабочем пространстве с тарификацией, учитываются в тарифном плане, назначенном этому рабочему пространству. Пользователи с разрешением Редактирование настроек рабочего пространства могут просматривать и оплачивать тарифный план; этим пользователям отправляются уведомления о тарификации по электронной почте. Подробнее см. Выставление счетов.

Аватары

Аватары загружаются и кэшируются на стороне сервера, чтобы уменьшить утечку информации на сайты, обслуживающие их по умолчанию. Встроенную поддержку получения аватаров из настроенных для этого адресов электронной почты можно отключить с помощью параметра ENABLE_AVATARS.

В настоящее время Weblate поддерживает:

См. также

CDN локализации

Надстройки CDN локализации JavaScript и CDN файлов перевода записывают файлы в LOCALIZE_CDN_PATH; Weblate не обслуживает их. Настройте веб-сервер или CDN, обслуживающий LOCALIZE_CDN_URL, как общедоступный, доступный только для чтения хост статических файлов.

Обрабатывайте каждый опубликованный CDN-файл как общедоступный. Специфичный для надстройки UUID в URL-адресе не является механизмом контроля доступа. Не включайте CDN-надстройки для компонентов, которые содержат приватные строки, текст невыпущенного продукта, данные клиентов, внутренние URL-адреса, примеры API, пути к репозиториям, комментарии переводчиков или метаданные формата файлов, которые не должны быть раскрыты.

Надстройка CDN файлов перевода публикует необработанные файлы переводов в форматах, поддерживаемых Weblate. Некоторые форматы могут интерпретироваться браузерами или другими клиентами как HTML, SVG, XML, JavaScript, YAML или специфичная для приложения конфигурация. Обслуживайте CDN с выделенного домена, отдельного от Weblate и от приложения, потребляющего переводы. Не передавайте куки аутентификации домену CDN.

Рекомендуемая конфигурация сервера:

  • Обслуживайте только каталог, настроенный параметром LOCALIZE_CDN_PATH; не раскрывайте репозитории Weblate, резервные копии, медиафайлы, конфигурацию или весь каталог данных.

  • Отключите листинг каталогов.

  • Используйте HTTPS и сделайте хост CDN доступным только для чтения с веб-сервера.

  • Отправляйте X-Content-Type-Options с nosniff.

  • Настройте консервативные MIME-типы. Обслуживайте неизвестные форматы переводов как text/plain или application/octet-stream; обслуживайте weblate.js только как JavaScript.

  • Для необработанных форматов переводов, не предназначенных для отображения в браузере, рассмотрите возможность добавления Content-Disposition с attachment.

  • Настраивайте Access-Control-Allow-Origin только для сайтов, которым требуется доступ браузера к файлам.

  • Установите время жизни кэша, соответствующее вашим ожиданиям обновления, и очищайте кэши CDN, когда устаревшие переводы должны быстро исчезнуть.

Следующий фрагмент nginx обслуживает только настроенный CDN-каталог и применяет консервативные значения по умолчанию для необработанных файлов переводов:

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;
    }
}

См. также

Подписание коммитов Git с помощью GnuPG

Все коммиты могут быть подписаны с помощью ключа GnuPG вашего экземпляра Weblate.

  • Включите WEBLATE_GPG_IDENTITY. (Weblate при необходимости создаст ключ GnuPG и будет использовать его для подписи всех коммитов переводов.)

    Эта функция требует установки GnuPG 2.1 или новее.

    Этот ключ будет хранится по пути, указанному в DATA_DIR, а открытый ключ будет отображаться на странице «О Weblate» (/about/):

    ../_images/about-gpg.webp

  • В качестве альтернативы вы также можете импортировать существующие ключи в Weblate, просто установите HOME=$DATA_DIR/home при вызове gpg.

Подсказка

Ключевой материал кэшируется Weblate на длительный период. Если вы позволяете Weblate создать ключ с WEBLATE_GPG_IDENTITY, а затем импортировать ключ с тем же идентификатором, чтобы использовать существующий ключ, рекомендуется очистить кэш Redis, чтобы увидеть эффект такого изменения.

Примечание

При совместном использовании DATA_DIR между несколькими серверами, пожалуйста, следуйте инструкциям на https://wiki.gnupg.org/NFS для обеспечения надёжной работы подписи GnuPG.

См. также

WEBLATE_GPG_IDENTITY

Ограничение частоты запросов

Изменено в версии 4.6: Ограничение частоты больше не применяется к вошедшим в систему суперпользователям.

Некоторые операции в Weblate ограничены по частоте. Ограничения оцениваются независимо для каждой области действия. Допускается не более RATELIMIT_ATTEMPTS попыток в течение RATELIMIT_WINDOW секунд в одной области действия. Эта область действия затем блокируется на RATELIMIT_LOCKOUT; Weblate не превращает это в общесайтовую временную блокировку IP. Превышение одной области, например TRANSLATE или SEARCH, само по себе не блокирует несвязанные области, такие как LOGIN или SECOND_FACTOR. Существуют также настройки, специфичные для областей, например RATELIMIT_CONTACT_ATTEMPTS или RATELIMIT_TRANSLATE_ATTEMPTS. В таблице ниже приведён полный список доступных областей.

Следующие операции подвержены ограничению частоты запросов:

Имя

Область

Допустимо попыток

Временное окно

Период блокировки

Регистрация

REGISTRATION

5

300

600

Отправка сообщения администраторам

MESSAGE

2

300

600

Аутентификация по паролю при входе

LOGIN

5

300

600

Двухфакторная аутентификация

SECOND_FACTOR

5

300

600

Поиск по всему сайту

SEARCH

6

60

60

Перевод

TRANSLATE

30

60

600

Добавление в словарь

GLOSSARY

30

60

600

Начало перевода на новый язык

LANGUAGE

2

300

600

Создание нового проекта

PROJECT

5

600

600

Подключение учётной записи GitHub

GITHUB_SETUP

100

3600

600

В пределах каждой области ограничение частоты основано на сеансах, когда пользователь вошёл в систему, и на IP-адресе, если не вошёл.

Для вошедших в систему пользователей Weblate записывает первый отклонённый запрос во время каждой блокировки активной области действия в Журнал аудита, включая область действия и путь запроса. Повторные отклонения во время той же блокировки не создают дополнительных записей в журнале аудита.

Если у пользователя не получается войти AUTH_LOCK_ATTEMPTS раз, то авторизация по паролю полностью отключается до тех пор, пока пользователь не сбросит свой пароль.

Настройки можно также применить в Docker-контейнере, добавив префикс WEBLATE_ к имени настройки, например RATELIMIT_ATTEMPTS становится WEBLATE_RATELIMIT_ATTEMPTS.

Для API есть отдельные настройки ограничения количества запросов, смотреть раздел Ограничение частоты запросов API.

См. также