为 Weblate 模块作贡献¶
除了主仓库之外Weblate 还包含几个 Python 模块，所有这些都遵循相同的结构本文档涵盖了所有这些。
例如，这涵盖了：
wlc，Python 客户端库，请参阅 Weblate 客户端
translation-finder 用于发现仓库中的可翻译文件
language-data, language definitions for Weblate, see 语言定义
扩展内置语言定义¶
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
语言定义.
许可证和版权¶
贡献代码时，您同意将所做改动和新代码置于和仓库正使用的同一许可证下，除非另有声明和约定。
参见
Weblate 许可 更详细地解释代码许可问题。
写一个好补丁¶
撰写不相关更改¶
获得一个声称修复 11 个古怪问题的补丁令人烦恼，关于该补丁的讨论和意见不同意它们中的 10 个算问题，或者认为这些问题中的 9 个已经用另一方式被修复了。然后，合并这一更改的人需要从成堆的源码中提取出单一的有趣补丁，而这样做产生许多额外的工作。
更可取的方式是，每个解决一个问题的 fix 应当在其自己的 patch/commit 中，有自己的描述/提交信息，说清楚这个 fix 修正的是什么，这样维护者或其他感兴趣的人可以有选择地应用所有改动。
另外，单独更改启用二等分要好得多，这样便于跟踪 issues 和将来的 regression。
文档¶
文档工作也许枯燥乏味；然而，需要有人来完成这项工作。如果在提交代码改动时能一并提交文档信息会让事情变得容易的多。请记得记录下方法、复杂的代码块，或用户可见的功能。
测试用例¶
这些测试允许我们快速验证功能是否正如预想那样运转。为了保持这一状况并改进它，所有添加的新特性和功能都需要在测试套件中测试，每个新添加的特性都应至少获得一个有效测试用例，来验证其如文档中记录的那样工作。
提交说明¶
Git 提交应该遵守 Conventional Commits 规范。
类型检查¶
任何新代码都应使用 PEP 484 类型提示。我们在使用 mypy 进行检查（因为它有一个让 Django 应用的类型检查可做的 Django 插件）。
代码基还未完全被类型注解覆盖，但一些模块已被强制在 CI 中进行类型检查。
编码标准和代码检查¶
代码应该遵循 PEP 8 coding guidelines and should be formatted using ruff 代码格式化程序。
要检查代码质量，你可以使用 ruff，其配置存储在 pyproject.toml 中。
将所有这些强制的最简单的方法是安装 pre-commit。仓库为此包含了配置，来确定提交的文件是正常的。安装后（它已经包括在 pyproject.toml 中了）通过在 Weblate 的付款台运行 pre-commit install 来将它打开。通过这种方法，所有更改都将被自动检查。
还可以手动触发检查，来检查所有文件的运行：
pre-commit run --all
安全地写代码¶
在为 Weblate 编写任何代码时都应该考虑到 从设计上就是安全的这一原则。
AI 指南¶
在向项目贡献内容时，您同意我们照原样使用它，且您必须确保您被允许将它分发给我们。向我们提交改动代表您同意这些更改能够并应当被本项目采用，并在本项目许可证下再次分发。作者应明确知道确保没有未经许可的代码被提交至本项目的责任在于作者。
这无关是否使用 AI。
贡献拉取请求时，你理所应当应该始终确保提议的质量上佳，并尽了最大努力遵守我们的指南。基本的经验法则是如果某人可以指出贡献是在 AI 帮助下做出的，那么你有更多的工作要去做。
本项目可以接受在 AI 帮助下写出的代码，但这样的代码仍必须遵守代码标准，要编写清晰、有记录、有特性测试用例，并遵照所有我们拥有的常规要求。