Weblate モジュールへの貢献

メインのリポジトリに加えて、Weblate は複数の Python モジュールで構成されています。これらはすべて同じ構造をしており、このドキュメントの内容は全てに当てはまります。

例えば、次のものが対象です。

組み込まれた言語の定義の拡張

The language definitions are in the language-data repository.

You are welcome to add missing language definitions to languages.csv, other files are generated from that file. The columns in the CSV file correspond to 言語の定義.

参考

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.

ドキュメント

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.

参考

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.

参考

Weblate テストスイートと継続的な連携

コミットメッセージ

Git コミットは Conventional Commits 仕様に従う必要があります。

Type checking

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

The code base is not yet completely covered by type annotations, but some modules are already enforced for type checking in the CI.

コーディング規約と低品質コードの検出

The code should follow PEP 8 coding guidelines and should be formatted using ruff code formatter.

コードの品質を検査するには、ruff を使用できます。その設定は pyproject.toml に保存されています。

これを実行する最も簡単な方法は、pre-commit をインストールすることです。リポジトリには、コミットされたファイルが正常であることを確認するための設定が含まれています。インストール後（すでに pyproject.toml に含まれています）、Weblate のチェックアウトで pre-commit install を実行して有効にします。これにより、すべての変更が自動的に検査されます。

手動で検査を実行し、すべてのファイルを検査する方法:

pre-commit run --all

Coding securely

Weblate のコードはすべて、 セキュリティ設計原則 を念頭に記述してください。

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.