Weblate internals

Note

This chapter will give you basic overview of Weblate internals.

Weblate derives most of its code structure from, and is based on Django.

Structure du répertoire

Aperçu rapide de la structure du répertoire du dépôt principal de Weblate :

docs

Code source de cette documentation que vous pouvez compiler à l’aide de Sphinx.

dev-docker

Code Docker pour exécuter le serveur de développement, voir Exécuter Weblate localement dans Docker.

weblate

Code source de Weblate en tant qu’application Django , voir Weblate internals.

weblate/static

Fichiers clients (CSS, Javascript et images), voir Interface de Weblate.

Modules

Weblate est composé de différentes applications Django (dont certaines sont optionnelles, voir Modules Weblate optionnels) :

accounts

Compte utilisateur, profils et notifications.

addons

Greffons pour affiner le comportement de Weblate, voir Extensions.

api

API basée sur Django REST framework.

auth

Authentification et privilèges.

billing

Module optionnel de facturation Facturation.

checks

Module Contrôles qualité de vérification de la chaîne à traduire.

fonts

Module de vérification du rendu des polices de caractères.

formats

Niveau d’abstraction de format de ficher basé sur les outils de traduction.

gitexport

Module optionnel Exportateur Git.

lang

Module définissant les modèles de langue et les formes plurielles.

legal

Module facultatif Legal module.

machinery

Integration des services de traduction automatique.

memory

Mémoire de traduction intégré, voir Mémoire de traduction.

screenshots

Gestion des captures d’écran et module OCR.

trans

Module principal de gestion des traductions.

utils

Divers utilitaires d’aide.

vcs

Abstraction du système de contrôle des versions.

wladmin

Personnalisation de l’interface utilisateur de Django.

Background tasks internals

Indication

This section describes Celery task internals. Tâches en arrière-plan utilisant 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.