Código-fonte do Weblate

O Weblate é desenvolvido no GitHub. Você é bem-vindo para criar um fork do código e abrir pull requests. Patches em qualquer outra forma são bem-vindos também.

Ver também

Confira Componentes internos do Weblate para ver como o Weblate se parece por dentro.

Writing a good patch

Write separate changes

It is annoying when you get a massive patch that is said to fix 11 odd problems, but discussions and opinions do not agree with 10 of them or 9 of them were already fixed differently. Then the person merging this change needs to extract the single interesting patch from somewhere within the massive pile of sources, and that creates a lot of extra work.

Preferably, each fix that addresses an issue should be in its own patch/commit with its own description/commit message stating exactly what they correct so that all changes can be selectively applied by the maintainer or other interested parties.

Furthermore, separate changes enable bisecting much better for tracking issues and regression in the future.

Documentação

Documentation can be a tedious task; however, it is necessary for someone to complete it. It makes things a lot easier if you submit the documentation together with code changes. Please remember to document methods, complex code blocks, or user-visible features.

Ver também

Contribuir com a documentação do Weblate

Test cases

The tests allow us to quickly verify that the features are working as they are supposed to. To maintain this situation and improve it, all new features and functions that are added need to be tested in the test suite. Every feature that is added should get at least one valid test case that verifies that it works as documented.

Ver também

Conjunto de testes e integração contínua do Weblate

Mensagens de commit

Os commits do Git devem seguir a especificação de Conventional Commits.

Type checking

Any new code should utilize PEP 484 type hints. We are using mypy to check them because it has a Django plugin that makes type checking of Django apps practical.

New and changed code should not introduce new mypy failures where current Django typing support makes that practical. The code base is not yet completely covered by type annotations, and some Django constructs are difficult to annotate precisely. CI therefore enforces mypy only for selected modules and reports other findings separately.

Padrão de codificação e linting do código

O código deve seguir as diretrizes de codificação PEP 8 e deve ser formatado usando o formatador de código ruff.

Para verificar a qualidade do código, você pode usar ruff e sua configuração é armazenada em pyproject.toml.

When suppressing a ruff diagnostic, prefer # ruff: ignore[rule-name] with the human-readable rule name. Place the comment on the line above the logical statement or block when that does not broaden the suppression scope. Keep the comment inline when moving it would change the scope, affect import sorting, or get between another tool’s disable-next comment and the code it targets.

The easiest approach to enforce all this is to install prek. This is a third-party reimplementation of the pre-commit tool used by Weblate. It is included in the development dependencies declared in pyproject.toml, so installing those dependencies makes prek available.

To check all files manually, run:

uv run prek run --all-files

If you prefer the original pre-commit client, it uses the same configuration from .pre-commit-config.yaml.

Coding securely

Qualquer código para Weblate deve ser escrito com Princípios de Segurança por Design (inglês) em mente.

AI guidelines

When contributing content to the project, you give us permission to use it as-is, and you must make sure you are allowed to distribute it to us. By submitting a change to us, you agree that the changes can and should be adopted by the project and get redistributed under the project license. Authors should be explicitly aware that the burden is on them to ensure no unlicensed code is submitted to the project.

This is independent of whether AI is used or not.

When contributing a pull request, you should, of course, always make sure that the proposal is of good quality and the best effort that follows our guidelines. A basic rule of thumb is that if someone can spot that the contribution was made with the help of AI, you have more work to do.

We can accept code written with the help of AI into the project, but the code must still follow coding standards, be written clearly, be documented, feature test cases, and adhere to all the normal requirements we have.

Recording acting users

Use acting_user_context(user) from weblate.utils.change_origin around operations that change model settings outside an authenticated request. Request authentication establishes this context automatically. Models read the actor with get_acting_user(); they no longer retain acting_user attributes. Nested contexts restore the previous actor, and passing None explicitly clears it. Use the anonymous user for intentional anonymous changes and the appropriate bot for automated operations.

Continue passing an explicit user when recording history. The actor context does not supply missing users to Change automatically and does not replace permission checks or content authorship. Pending file writes retain their own persisted actors and authors.

Wrap deferred transaction callbacks with capture_change_origin() when registering them. This captures both the origin and actor before their scopes exit. Celery tasks propagate the actor through a separate internal header; only the user identifier is serialized. Origin metadata stored in history does not include this identifier. Tasks with an invalid or deleted actor fail without executing their body.