# Gjërat e brendshme të Weblate-it #### NOTE This chapter will give you basic overview of Weblate internals. Weblate derives most of its code structure from, and is based on [Django](https://www.djangoproject.com/). ## Strukturë drejtorish Quick overview of directory structure of Weblate main repository: `docs` : Source code for this documentation, which can be built using [Sphinx](https://www.sphinx-doc.org/). `dev-docker` : Docker code to run development server, see [Running Weblate locally in Docker](https://docs.weblate.org/sq/latest/contributing/start.md#dev-docker). `weblate` : Source code of Weblate as a [Django](https://www.djangoproject.com/) application, see [Gjërat e brendshme të Weblate-it](#internals). `weblate/static` : Client files (CSS, Javascript and images), see [Pjesa e dukshme e Weblate-it](https://docs.weblate.org/sq/latest/contributing/frontend.md). ## Module Weblate consists of several Django applications (some optional, see [Optional Weblate modules](https://docs.weblate.org/sq/latest/admin/optionals.md)): `accounts` > Llogari, profile dhe njoftime përdoruesi. `addons` > Add-ons to tweak Weblate behavior, see [Shtesa](https://docs.weblate.org/sq/latest/admin/addons.md#addons). `api` > API based on [Django REST framework](https://www.django-rest-framework.org/). `auth` > Mirëfilltësim dhe Leje. `billing` > The optional [Faturim](https://docs.weblate.org/sq/latest/admin/optionals.md#billing) module. `checks` > Translation string [Kontrolle cilësie](https://docs.weblate.org/sq/latest/user/checks.md#checks) module. `fonts` > Font rendering checks module. `formats` > File format abstraction layer based on translate-toolkit. `gitexport` > The optional [Git exporter](https://docs.weblate.org/sq/latest/admin/optionals.md#git-exporter) module. `lang` > Module defining language and plural models. `legal` > The optional [Legal module](https://docs.weblate.org/sq/latest/admin/optionals.md#legal) module. `machinery` > Integrim shërbimesh përkthimi nga makina. `memory` > Built-in translation memory, see [Kujtesë Përkthimesh](https://docs.weblate.org/sq/latest/admin/memory.md#translation-memory). `screenshots` > Screenshots management and OCR module. `trans` > Main module handling translations. `utils` > Various helper utilities. `vcs` > Version control system abstraction. `wladmin` > Përshtatje ndërfaqeje përgjegjësi Django. ## Translation sources A unit has a canonical file source and may have a translation from another language as its effective source. Keep `Unit.source` and `Unit.source_unit` canonical: repository synchronization and file formats depend on this. Use `effective_source` and its language and plural accessors for content shown to translators. Do not replace `source` on a copied unit to simulate an effective source; other fields and related objects still describe the canonical source. Use `Unit.source_snapshot` when an operation needs to preserve the source text, language, plural rules, and terminology metadata together. Its `identity` defines source changes for dependency reconciliation, editor conflict detection, and AI diagnostics. For historical rendering and reports, read the snapshot recorded on the change, rather than reconstructing it from the current unit. A missing configured parent remains a custom source: its text is empty, its language is retained, and its child is blocked. `effective_source_unit` is then `None`. Only removing the workflow or selecting the canonical language restores the canonical source. Text-only accessors do not load language or plural metadata. For batch consumers that need the complete effective source, use `UnitQuerySet.prefetch_translation_parent()` alongside their existing unit prefetches. `prefetch_source()` already includes this. Ordinary searches keep the canonical query path and ordinary units retain their existing content hashes. Source-dependent writes enter `source_operation()` before locking unit rows. The outer operation takes a shared project gate and reads its workflow mapping in one database round trip, including for projects without custom workflows. Workflow changes take `source_project_gate(..., exclusive=True)` before validation or persistence. Configuration changes affecting several projects acquire their gates in ascending project ID order. Never upgrade a shared gate to an exclusive one inside an operation. The database gate function locks first and reads workflows in a separate statement, so a waiter sees configuration committed while it waited. Write paths use this transaction-scoped view rather than cached model settings. Nested operations reuse it; rolled-back savepoints discard their dependency work. Queued dependencies are reconciled before commit and external memory updates are scheduled after commit. Source-change history is written in bulk, preserving individual records while batching their notification dispatch. Workflow saves and deletions compare the old and new source mappings under the exclusive gate. Reconciliation visits changed languages and their transitive dependants in either mapping, skipping components without affected translations. It loads supporting parent units without rebuilding unrelated languages. Callers that need a complete rebuild, such as restoration and language maintenance, omit the language restriction. Within each component, reconciliation updates relationships before running checks. Previous-source peer groups and units requiring checks are deduplicated. Direct unit and previous-source peer checks finish before the transaction commits; propagated check refreshes retain their existing scheduling. Translation-memory payloads use bounded batches scheduled after commit. Nested operations merge dependency work, while rolled-back savepoints discard their work and commit callbacks. Acquire any required repository locks before project gates, then component and unit row locks. Reconciliation itself only changes database state and does not acquire repository locks. Apply this boundary to bulk imports, automatic translation, file-save failures, deletion, and restoration as well as editor writes. Language and plural-rule changes require exclusive gates before their updates. Historical migrations use historical models without these runtime helpers. Machinery source selection happens before mapping language codes to a provider. Use `get_unit_source_language()` for translation and `uses_custom_source()` for workflow-specific glossary handling. Provider codes can merge distinct language variants, so code equality cannot determine whether a workflow source was selected. Explicit component or secondary source selection takes precedence over the workflow source. ## Background tasks internals #### HINT This section describes Celery task internals. [Background tasks using Celery](https://docs.weblate.org/sq/latest/admin/install.md#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.