Weblate por dentro¶
Nota
This chapter will give you basic overview of Weblate internals.
Weblate derives most of its code structure from, and is based on Django.
Estructura de directorios¶
Quick overview of directory structure of Weblate main repository:
docsSource code for this documentation, which can be built using Sphinx.
dev-dockerDocker code to run development server, see Ejecutar Weblate localmente en Docker.
weblateSource code of Weblate as a Django application, see Weblate por dentro.
weblate/staticClient files (CSS, Javascript and images), see Interfaz de Weblate.
Módulos¶
Weblate se compone de varias aplicaciones de Django (algunas son opcionales; consulte Módulos opcionales de Weblate):
accounts
Cuenta de usuario, perfiles y notificaciones.
addons
Add-ons to tweak Weblate behavior, see Complementos.
api
API based on Django REST framework.
auth
Authentication and permissions.
billing
The optional Facturación module.
checks
Translation string Comprobaciones de calidad module.
fonts
Font rendering checks module.
formats
File format abstraction layer based on translate-toolkit.
gitexport
The optional Git exporter module.
lang
Módulo que define los idiomas y los modelos de pluralización.
legal
El módulo facultativo Legal module.
machinery
Integración de servicios de traducción automática.
memory
Memoria de traducción integrada, consulte Memoria de traducción.
screenshots
Gestión de capturas de pantalla y módulo de OCR.
trans
Módulo principal que manipula las traducciones.
utils
Diversas utilidades auxiliares.
vcs
Abstracción del sistema de control de versiones.
wladmin
Personalización de la interfaz administrativa de Django.
Background tasks internals¶
Consejo
This section describes Celery task internals. Tareas en segundo plano con 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:
celeryThe default queue where background tasks are processed.
notifyDelivers 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.
memoryUpdates 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.
backupThe backup tasks cannot be executed in parallel, and a single dedicated worker makes this easier.
translateAutomatic translation tasks are known to take long because they hit external services.