Mitarbeit an Weblate-Modulen¶
Neben dem Haupt-Repository besteht Weblate aus mehreren Python-Modulen. Diese folgen alle der gleichen Struktur und diese Dokumentation deckt sie alle ab.
Dies gilt zum Beispiel für:
wlc, Python-Client-Bibliothek, siehe Weblate-Client
translation-finder, um übersetzbare Dateien im Repository zu finden
language-data, Sprachdefinitionen für Weblate, siehe Sprachdefinitionen
translate-toolkit, the library to manipulate the translation files, originally third-party library but now maintained by Weblate.
Integrierte Sprachdefinitionen erweitern¶
Die Sprachdefinitionen befinden sich im Repository language-data.
Sie können fehlende Sprachdefinitionen gerne in languages.csv ergänzen, andere Dateien werden aus dieser Datei erzeugt. Die Spalten in der CSV-Datei entsprechen denen der Sprachdefinitionen.
Siehe auch
Lizenz und Urheberrecht¶
Wenn Sie Code beitragen, stimmen Sie zu, Ihre Änderungen und neuen Code unter dieselbe Lizenz zu stellen, die das Repository bereits verwendet, sofern nicht anders angegeben und vereinbart.
Siehe auch
Weblate-Lizenz erklärt die Lizenzierung genauer.
Einen guten Patch schreiben¶
Separate Änderungen schreiben¶
Es ist ärgerlich, wenn man einen großen Patch erhält, der angeblich 11 Probleme behebt, aber die Diskussionen und Meinungen stimmen mit 10 davon nicht überein oder 9 davon wurden bereits anders behoben. Dann muss die Person, die diese Änderung zusammenführt, den einzigen interessanten Patch irgendwo aus dem riesigen Haufen von Quellen herausziehen, und das verursacht eine Menge zusätzliche Arbeit.
Vorzugsweise sollte jede Korrektur, die ein Problem behebt, in einem eigenen Patch/Commit mit einer eigenen Beschreibung/Commit-Nachricht sein, die genau angibt, was korrigiert wird, so dass alle Änderungen vom Betreuer oder anderen interessierten Parteien selektiv angewendet werden können.
Außerdem lassen sich durch getrennte Änderungen Probleme und Regressionen in Zukunft viel besser verfolgen.
Dokumentation¶
Dokumentation kann eine mühsame Aufgabe sein, aber es ist notwendig, dass jemand sie erledigt. Es macht die Sache viel einfacher, wenn Sie die Dokumentation zusammen mit den Codeänderungen einreichen. Bitte denken Sie daran, Methoden, komplexe Codeblöcke oder für den Benutzer sichtbare Funktionen zu dokumentieren.
Siehe auch
Testfälle¶
Die Tests ermöglichen es uns, schnell zu überprüfen, ob die Funktionen wie vorgesehen funktionieren. Um dies aufrechtzuerhalten und zu verbessern, müssen alle neu hinzugefügten Funktionen in der Testsuite getestet werden. Für jede hinzugefügte Funktion sollte mindestens ein gültiger Testfall erstellt werden, der die dokumentierte Funktion überprüft.
Commit-Nachrichten¶
Git-Commits sollten der Spezifikation Conventional Commits folgen.
Typprüfung¶
Jeder neue Code sollte PEP 484-Typhinweise verwenden. Wir verwenden mypy zur Überprüfung (da es ein Django-Plugin hat, das die Typprüfung von Django-Apps ermöglicht).
Der Quellcode ist noch nicht vollständig durch Typbeschriftungen abgedeckt, für einige Module wird jedoch bereits eine Typprüfung im CI erzwungen.
Codierungsstandard und Codeanalyse¶
Der Code sollte den PEP 8-Programmierrichtlinien entsprechen und mit dem Code-Formatierer ruff formatiert werden.
Um die Codequalität zu überprüfen, kann ruff verwendet werden, dessen Konfiguration in pyproject.toml gespeichert ist.
Der einfachste Ansatz, all dies zu erzwingen, ist die Installation von pre-commit. Das Repository enthält eine entsprechende Konfiguration, um zu überprüfen, ob die committeten Dateien in Ordnung sind. Nachdem es installiert wurde (es ist bereits in der pyproject.toml enthalten), aktivieren Sie es, indem Sie pre-commit install im Weblate-Checkout ausführen. Auf diese Weise werden alle Ihre Änderungen automatisch überprüft.
Sie können die Prüfung auch manuell auslösen, um alle Dateien zu prüfen:
pre-commit run --all
Sicheres Programmieren¶
Jeder Code für Weblate sollte unter Berücksichtigung von Security by Design Principles geschrieben werden.
KI-Richtlinien¶
Wenn Sie Inhalte zum Projekt beitragen, erteilen Sie uns die Erlaubnis, diese unverändert zu verwenden, und Sie müssen sicherstellen, dass Sie sie an uns weitergeben dürfen. Indem Sie uns eine Änderung übermitteln, stimmen Sie zu, dass die Änderungen vom Projekt übernommen und unter der Projektlizenz weiterverbreitet werden können. Die Autoren sollten sich ausdrücklich darüber im Klaren sein, dass sie dafür verantwortlich sind, dass kein unlizenzierter Code an das Projekt übermittelt wird.
Dies ist unabhängig davon, ob KI eingesetzt wird oder nicht.
Wenn Sie einen Pull Request einreichen, sollten Sie natürlich immer darauf achten, dass der Vorschlag qualitativ hochwertig ist und unseren Richtlinien entspricht. Als Faustregel gilt: Wenn jemand erkennen kann, dass der Beitrag mithilfe von KI erstellt wurde, haben Sie mehr Arbeit zu erledigen.
Wir können mithilfe von KI geschriebenen Code in das Projekt aufnehmen, aber der Code muss weiterhin den Codierungsstandards entsprechen, klar geschrieben und dokumentiert sein, Testfälle enthalten und alle unsere normalen Anforderungen erfüllen.