Componentes internos do Weblate

Nota

Este capítulo lhe dará uma visão geral básica dos componentes internos do Weblate.

Weblate deriva a maior parte da estrutura de código dele e é baseado no Django.

Estrutura de pasta

Visão geral rápida da estrutura de pasta do repositório principal de Weblate:

docs

Código fonte para esta documentação, que pode ser criada utilizando Sphinx.

dev-docker

Código de Docker para executar o servidor de desenvolvimento, consulte Executando Weblate localmente no Docker.

weblate

Código fonte de Weblate como uma aplicação Django, consulte Componentes internos do Weblate.

weblate/static

Ficheiro de cliente (CSS, Javascript e imagens), veja Frontend do Weblate.

Módulos

O Weblate consiste em vários aplicações Django (alguns opcionais, veja Módulos opcionais do Weblate):

accounts

Conta do utilizador, perfis e notificações.

addons

Extensões para ajustar o comportamento do Weblate, veja Extensões.

api

API baseada no framework Django REST.

auth

Autenticação e permissões.

billing

O módulo opcional de Faturação.

checks

Módulo de Verificações de qualidade de cadeia de tradução.

fonts

Módulo de verificações de renderização de fonte.

formats

Camada de abstração de formato de ficheiro baseada no translate-toolkit.

gitexport

O módulo opcional Exportador git.

lang

Módulo que define idioma e modelos plurais.

legal

O módulo opcional Módulo legal.

machinery

Integração de serviços de tradução de máquina.

memory

Memória de tradução integrada, ver Memória de Tradução.

screenshots

Gestão de capturas de ecrã e módulo OCR.

trans

Módulo principal que trata das traduções.

utils

Várias utilidades de ajuda.

vcs

Abstração do sistema de controle de versão.

wladmin

Personalização da interface administrativa do Django.

Background tasks internals

Dica

This section describes Celery task internals. Tarefas de fundo a usar o Celery describes how to configure Celery to run the tasks.

Weblate uses Celery to execute tasks in the background. Some tasks are event-triggered, and some tasks are schedule-triggered.

The Celery Beat is used for scheduling tasks, and django-celery-beat is used to store the periodic task schedule in the database. The tasks schedule is configured in tasks.py in each of the Django apps.

The tasks are consumed using several queues; the routing is configured in settings.py. The queues were designed to separate different types of workload:

celery

The default queue where background tasks are processed.

notify

Delivers notification e-mails, both for events within Weblate and for authentication or registration. This is a separate queue to make e-mail delivery smooth even if there is a backlog of other tasks.

memory

Updates translation memory entries. The updating queue can be long when importing new strings, and long processing does not matter much here, so having a separate queue avoids blocking other tasks.

backup

The backup tasks cannot be executed in parallel, and a single dedicated worker makes this easier.

translate

Automatic translation tasks are known to take long because they hit external services.