Weblate källkod

Weblate utvecklas på GitHub. Du är välkommen att förgrena koden och öppna pull-förfrågningar. Patchar i andra former är också välkomna.

Se även

Kolla in Weblate internt för att se hur Weblate ser ut inifrån.

Skriva en bra patch

Skriv separata ändringar

Det är irriterande när man får en enorm patch som sägs fixa 11 udda problem, men diskussioner och åsikter inte stämmer överens med 10 av dem eller 9 av dem redan har fixats på ett annat sätt. Då måste den person som sammanfogar denna ändring extrahera den enda intressanta patchen från någonstans i den enorma högen av källor, och det skapar en hel del extra arbete.

Helst bör varje korrigering som åtgärdar ett problem finnas i en egen patch/commit med en egen beskrivning/commit-meddelande som anger exakt vad som korrigeras, så att alla ändringar kan tillämpas selektivt av underhållaren eller andra berörda parter.

Dessutom möjliggör separata ändringar en mycket bättre uppdelning för att spåra problem och regressioner i framtiden.

Dokumentation

Dokumentation kan vara ett tråkigt arbete, men det är nödvändigt att någon gör det. Det underlättar mycket om du skickar in dokumentationen tillsammans med kodändringarna. Kom ihåg att dokumentera metoder, komplexa kodblock eller funktioner som är synliga för användaren.

Se även

Bidra till Weblate-dokumentationen

Testfall

Testerna gör det möjligt för oss att snabbt verifiera att funktionerna fungerar som de ska. För att upprätthålla denna situation och förbättra den måste alla nya funktioner som läggs till testas i testpaketet. Varje funktion som läggs till bör få minst ett giltigt testfall som verifierar att den fungerar enligt dokumentationen.

Se även

Weblate testsuite och kontinuerlig integration

Arkiveringssmeddelande

Git-commits ska följa specifikationen Conventional Commits.

Typskontroll

All ny kod bör använda PEP 484 typindikationer. Vi använder mypy för att kontrollera (eftersom det har ett Django-plugin som gör det möjligt att kontrollera typen av Django-appar).

Kodbasen är ännu inte helt täckt av typannoteringar, men vissa moduler är redan föremål för typkontroll i CI.

Kodningsstandard och linting av koden

Koden ska följa PEP 8 kodningsriktlinjer och ska formateras med hjälp av ruff kodformaterare.

För att kontrollera kodkvaliteten kan du använda ruff, vars konfiguration lagras i pyproject.toml.

Det enklaste sättet att genomföra allt detta är att installera pre-commit. Repositoriet innehåller konfiguration för att verifiera att de commitade filerna är korrekta. Efter installationen (det ingår redan i pyproject.toml) aktiverar du det genom att köra pre-commit install i Weblate checkout. På så sätt kommer alla dina ändringar att kontrolleras automatiskt.

Du kan också starta kontrollen manuellt. För att kontrollera alla filer kör du:

pre-commit run --all

Säker kodning

All kod för Weblate bör skrivas med Security by Design Principles i åtanke.

Riktlinjer för AI

När du bidrar med innehåll till projektet ger du oss tillstånd att använda det som det är, och du måste se till att du har rätt att distribuera det till oss. Genom att skicka in en ändring till oss samtycker du till att ändringarna kan och bör antas av projektet och distribueras vidare under projektlicensen. Författare bör vara uttryckligen medvetna om att det är deras ansvar att se till att ingen olicensierad kod skickas in till projektet.

Detta är oberoende av om AI används eller inte.

När du bidrar med en pull-förfrågan bör du naturligtvis alltid se till att förslaget är av god kvalitet och att det bästa möjliga arbete har lagts ner i enlighet med våra riktlinjer. En grundläggande tumregel är att om någon kan se att bidraget har skapats med hjälp av AI, har du mer arbete att göra.

Vi kan acceptera kod som skrivits med hjälp av AI i projektet, men koden måste fortfarande följa kodningsstandarder, vara tydligt skriven, dokumenterad, innehålla testfall och uppfylla alla våra normala krav.