Gids voor bijdragen aan de Krita handleiding¶

Welkom in de gids voor bijdragen aan de Krita handleiding|

Als u geïnteresseerd bent in bijdragen aan documentatie van Krita, dan bent u op de juiste plaats.

Krita is (vrij) open source software, wat ons daadwerkelijk een community project maakt, met een groot aantal vrijwilligers die meedoen om het beter te maken. Dit, verlangt van ons natuurlijk dat we de handleidingen en how-to’s voor nieuwe vrijwilligers die ons komen helpen up to date houden. We deden dit op verschillende plekken die nogal verspreid waren, en hielden dit vaak niet zo goed bij. De handleiding voor medewerkers is een poging om alle informatie vast te leggen. Het daarom op sommige plekken vrij technisch.

De handleiding zal bevatten:

Een referentie handleiding voor Krita

Dit is waarschijnlijk wat iedereen verwacht wanneer ze de documentatie van Krita gaan lezen. Droog, eenvoudig, ‘wat doet deze knop’ soort informatie.

Instructies over het algemene concept.

We hebben de laatste twee jaren gemerkt dat voor bepaalde soorten gebruikers, een referentie-handleiding, zelfs met enkele voorbeelden, niet genoeg is. De handleiding zou ook eenvoudige maar nauwkeurige uitleg moeten geven over dingen, en een simpele werkmethodiek om een afbeelding voor te bereiden voor het web.

We hebben ook gemerkt dat bepaalde ideeën, zoals kleurenbeheer en gebruik van lagen in Krita veel geavanceerder zijn dan de gemiddelde artiest gewent is. Krita is gratis en veel van zijn gebruikers zullen geen formele training in digitale kunstcreatie hebben gehad. Er is dus geen voorafgaande artiest-gerelateerde kennis aanwezig zijn over kleurenbeheer of lagen filteren.

Daarnaast zijn er systemen die uniek zijn voor Krita, bijvoorbeeld het penseel systeem, de transformatiemaskers, de alpha inheritance en de perspectief assistants. Tenslotte zijn er gebruikers die zelfs niet bekend zijn met standaard werkmethodieken bij schilderen, en niet flexibel genoeg zijn om te begrijpen hoe men een instructie voor SAI of Photoshop moet omzetten naar Krita.

Een lijst van bekende instructies en video-instructies

Blijkbaar is een van de mooie eigenschappen van het team van Krita dat we goed samenwerken met artiesten en hoe we erkennen dat ze mooie dingen maken. Het zelfde zou ook kunnen gelden voor de instructies, met name omdat er altijd manieren zijn waarop Krita gebruikt wordt en hoe schilderen benadert wordt die uniek zijne en waarom we mensen aanmoedigen om hun kennis te delen.

Handleiding voor medewerkers

Wat u nu aan het lezen bent!

instructies op krita.org

Er zijn een paar verzamelingen van instructies op krita.org en op krita-foundation.tumblr.com, de eerste gefocust op de uitleg hoe u nieuwe mogelijkheden kunt gebruiken en de laatste op verzoek van gebruikers.

FAQ

Deze is al online en is een samenvoeging van de verschillende FAQs die we hadden. Het wordt op dit moment vertaalt en we hopen dat dit de belangrijkste is die bijgewerkt zal worden.

Voor de beginners¶

Anders dan Mediawiki, werkt Sphinx meer zoals we code schrijven voor Krita.

Om te beginnen zal u contact met ons willen maken! Hiervoor kunt u zich bij ons voegen in de chatroom “#krita” via matrix. Een introductie over Matrix is hier te vinden. Maak een matrix-account aan op webchat.kde.org en doe mee in het kanaal #krita:kde.org. Of, nog belangrijker, maak een account aan op identity.kde.org. Met het account dat u heeft aangemaakt op identity kunt u toegang krijgen tot zowel invent.kde.org als de phabricator, waar we de ontwikkeling van Krita organiseren.

Sphinx werkt door eenvoudige tekstbestanden met reStructuredText opmaak te schrijven, waarna het deze tekstbestanden neemt en omzet naar de handleiding. We houden de wijzigingen in de handleiding bij door ze in een version control system genaamd Git te plaatsen.

Wijzigingen aanbrengen¶

Omdat we Git gebruiken, zijn er maar een paar mensen die dingen in het version control system kunnen plaatsen, dus als u wijzigingen wilt aanbrengen dan moet u het in review geven.

Merge requests in de Edit mode creëren¶

Notitie

Deze methode is alleen geschikt als u geen push-toegang hebt tot KDE-opslagruimten. Anders zouden uw wijzigingen direct in de opslagruimte worden vastgelegd (commit), wat tegen de huidige richtlijnen is.

Aanbevolen voor gebruikers zonder technische kennis.

Niet aanbevolen als u meer dan een bestand tegelijk wilt wijzigen. (Zie Merge verzoeken met WebIDE creëren of Merge verzoeken op de commandoregel creëren als u meerdere bestanden wilt wijzigen, of gewoon alleen maar een bestand per merge-verzoek wilt wijzigen).

Als u veel wijzigingen hebt die u wilt bijdragen, dan bevelen wij u aan om deze instructies te volgen.

Verkrijg een KDE identiteit.
Login bij KDE_gitlab.
Ga naar de repository en druk op fork.
U zou nu naar de fork in uw eigen opslagruimte moeten worden gestuurd. Standaard is deze te vinden in invent.kde.org/UW_KDE_LOGIN_NAAM/docs-krita-org.
Ga terug naar de officiële opslagruimte. Let erop dat u Documentation > Krita.org Documentation bekijkt, en niet uw eigen fork. Anders werkt deze methode niet juist.

Gitlab heeft de mogelijkheid om bestanden in gitlab zelf te bewerken. Om dit te doen, gaat u naar Repository ‣ Files.

Aan de bovenkant van de pagina zou u een keuzevak moet zien met master als geselecteerd item.

Zoek het bestand op dat u wilt bewerken, open het en klik op Edit.

Maak uw wijzigingen. (Let op: in deze modus kunt maar een bestand tegelijk bewerken).

Ga naar het kleine tekstvak en schrijf een mooi bericht in de commit bericht sectie met de veranderingen die u heeft gemaakt. Als u klaar bent, druk dan op Commit changes. Dit maakt voor u een merge verzoek, vul gewoon alle velden in zoals uitgelegd in: Aanwijzingen voor nieuwe merge verzoeken.

Het nadeel is dat op dit moment er geen manier is om te vertellen dat u een vergissing heeft gemaakt met de mark up terwijl u deze methode gebruikte. Controleer u wijzigingen met de Online Sphinx Editor (kopieer en plak gewoon het hele bestand dat u bewerkte).

Let op

Edit en WebIDE zijn twee verschillende dingen! Zorg ervoor dat u Edit selecteert.

Merge verzoeken met WebIDE creëren¶

Aanbevolen voor gebruikers die een beetje kennis hebben van Git en die meerdere bestanden tegelijk willen bewerken.

Niet aanbevolen als u niet weet wat een branch is (zie Merge requests in de Edit mode creëren in plaats daarvan).

Volg bovenstaande instructies om in te loggen bij KDE_gitlab en creëer uw fork.
Ga naar uw fork (zorg ervoor dat in het url uw gebruikersnaam voorkomt).
Maak zeker dat u op de branch master bent.
Klik op WebIDE. Hierdoor zou u naar een pagina moeten gaan met links een lijst van bestanden en rechts een leeg groot vak voor de inhoud van een bestand.
Open de bestanden die u wilt bewerken en breng de wijzigingen aan.
Klik op Commit…. Dubbelklik op alle bestanden in de categorie Unstaged changes om ze te verplaatsen naar Staged changes.
Klik opnieuw op Commit… - hierdoor opent een commit bericht tekstvak. Schrijf een commit bericht waarin u uitlegt welke wijzigingen u heeft aangebracht en waarom u dat deed.
Zorg ervoor dat de instellingen correct zijn: u moet selecteren Create a new branch (de naam van de branch zou moeten zijn: [gebruikersnaam]/[hele korte omschrijving van uw wijziging]). Als u klaar bent met uw wijzigingen, zorg er dan voor dat Start a new merge request is ingeschakeld. Anders moet u later handmatig een nieuw merge verzoek aanmaken.
Klik op Stage & Commit.
Vul alle velden correct in: zie Aanwijzingen voor nieuwe merge verzoeken.
Om handmatig een nieuw merge verzoek aan te maken, gaat u naar de Krita Manual official opslagruimte (let er op dat nu in de url niet uw gebruikersnaam voor komt) en klik op Create a new merge request (helder groene knop links). Selecteer uw fork en selecteer de branch die u in WebIDE heeft gecreëerd.

Notitie

Als u geen schrijfrechten heeft voor de officiële opslagruimte, dan zal gitlab niet toestaan dat u uw wijzigingen opslaat als u per ongeluk de officiële opslagruimte bewerkt (en Create a merge request zal u niet daarmee helpen: u moet nog steeds uw wijzigingen in uw eigen branch vastleggen, maar als u geen schrijfrechten heeft dan kan u dat niet doen). Het zal alleen maar het bericht tonen: An error occurred whilst committing your changes. Please try again.

In dat geval, kopieer gewoon de inhoud van alle bestanden die u wijzigde, ga naar uw fork en plak ze via WebIDE in uw fork.

Merge verzoeken op de commandoregel creëren¶

Aanbevolen voor gebruikers die weten hoe Git werkt en hoe de commandoregel gebruikt moet worden.

Niet aanbevolen als u niet weet wat een branch is (zie Merge requests in de Edit mode creëren in plaats daarvan).

Volg bovenstaande instructies om in te loggen bij KDE_gitlab en creëer uw fork.
Kloon de opslagruimte lokaal met git clone. De opslagruimte-pagina heeft de urls waarvan u de git kloon kan uitvoeren, waarna u naar uw fork kunt schrijven. Het voordeel hiervan is dat u alle hulpmiddelen op uw computer kunt gebruiken om deze tekstbestanden te bewerken maar dat u ook de handleiding lokaal kan construeren voor controle op fouten. (U hoeft deze stap maar een keer uit te voeren).
# voor ssh toegang git clone git@invent.kde.org:<username>/docs-krita-org.git git remote add upstream git@invent.kde.org:documentation/docs-krita-org.git # voor https toegang git clone https://invent.kde.org/<username>/docs-krita-org.git git remote add upstream https://invent.kde.org/documentation/docs-krita-org.git
Vergeet niet om alle wijzigingen uit de officiële opslagruimte te halen voordat u nieuwe wijzigingen gaat maken:
git pull upstream master
Maak zeker dat u een nieuwe branch voor uw wijzigingnen aanmaakt, sinds september 2019 moeten alle wijzigingen afgesplitst (branched) worden van master.
git checkout master # en dan: git checkout -b "<username>/<description of the new feature>"

Na het maken van uw wijzigingen, leg ze vast in uw fork. Voor een gedetailleerde beschrijving van hoe u Git in terminal gebruikt voor deze werkvolgorde, gaat u naar Forking on Gitlab.

# installeer het pakket python3-sphinx voor uw systeem. Bijvoorbeeld voor Ubuntu:
sudo apt install python3-sphinx
# bouw de handleiding (rapporteert potentiële fouten, biedt het inspecteren van wijzigingen in de browser)
make html
# Zorg ervoor dat alles juist is
git status
git diff
# voeg al deze bestanden toe
git add .
# leg uw wijzigingen vast
git commit
# voeg uw wijzigingen toe aan uw fork
git push

Ga tenslotte naar de website van de originele opslagruimte en ga naar Merge Requests. Selecteer uw fork en de correcte branch en creëer een nieuwe merge request. Voor instructies over hoe de velden in te vullen, zie Aanwijzingen voor nieuwe merge verzoeken.

Aanwijzingen voor nieuwe merge verzoeken¶

Uw commit bericht moet voldoen aan standaarden die hier worden uitgelegd: How to Write a Git Commit Message
Title en Description zouden duidelijk moeten maken welke wijzigingen u heeft gemaakt en waarom u ze heeft gemaakt, net zoals een commit bericht, volg daarom ook in dit geval de aanwijzingen uit de link hierboven.
Target moet naar master wijzen.
Als u er zeker van bent dat het merge verzoek later nog meer wijzigingen vereist, start dan de titel van uw merge verzoek met [WIP].
Zorg er voor dat u Allow commits from members who can merge to the target branch. heeft ingeschakeld – het is vaak vanwege technische redenen nodig dat een merge verzoek wordt gerebased op master, wat technisch het merge verzoek wijzigt, maar niet de werkelijke inhoud wijzigt. Rebase kan door u of door de reviewer worden gedaan – als u later niet teveel lastig wil worden gevallen, dan kunt u beter dit keuzevakje inschakelen zodat de reviewer dit zelf met een paar muisklikken kan doen.
U kunt in de meeste gevallen zonder problemen Delete source branch when merge request is accepted inschakelen.
Tenzij uw reviewers iets anders opdragen, schakelt u Squash commits when merge request is accepted in. De eerste regel van het commit bericht zal van de Title van uw merge verzoek en de rest zal van de Description van het merge verzoek komen.
Als u klaar bent met het creëren van uw merge verzoek, ga dan naar IRC (see Internet Relay Chat) en vraag of iemand met schrijfrechten het label Needs Review op uw merge verzoek toevoegt.
U zal feedback op uw merge verzoek krijgen als er fouten in voorkomen. Herstel gewoon de fouten in uw branch op een van de volgende manieren.
- Als u Edit mode wilt gebruiken, ga dan naar Changes sectie van het merge verzoek en klik op het potlood pictogram (met een tekstballon waarin staat Edit) om de Edit mode nog een keer te gebruiken.
- Als u WebIDE mode wilt gebruiken, ga dan naar uw fork, selecteer de branch waarin uw wijzigingen zijn en ga naar de WebIDE.
- Als u de bestanden op uw computer bewerkt en met een terminal werkt, zorg er dan voor dat u met de juiste branch werkt en push (uw wijzigingen vastleggen) uw wijzigingen - gitlab zal uw merge verzoek automatisch verwerken.
Zorg er voor dat nadat u de wijzigingen heeft gemaakt, u aan iemand vraagt om opnieuw de label naar Needs Review om te zetten.

Voor meer gedetailleerde informatie, gaat u naar Forking on Gitlab in de technische sectie.

Notitie

Op het moment dat deze handleiding werd geschreven was het instellen van labels van merge verzoeken alleen mogelijk door ontwikkelaars met schrijfrechten voor de officiële opslagruimte. (Als u niet weet wat dat betekent dan bent u waarschijnlijk daar niet een van). Daarom moet u als u een merge verzoek creëert of wijzigt, naar IRC gaan (zie De Krita gemeenschap) en iemand vragen om het voor u te labelen.

De handleiding op de opdrachtregel bouwen¶

Voor diegene die eerst enige wijzigingen wil uitproberen alvorens direct een verzoek voor merge te doen (en al weet hoe git en de opdrachtregel te gebruiken) dit is beschreven als onderdeel van stap 5. in Merge verzoeken op de commandoregel creëren.

Algemene filosofie¶

Dit is om te bepalen wat een toepasselijke schrijfstijl is. Een schrijfstijl, of we zijn praktische of esthetische kwaliteiten beschouwen, wordt meestal vastgelegd door een doel of algemene filosofie. Wat willen we bereiken met de handleiding, en voor wie is de handleiding bedoeld?

Demografie en beoogde gebruikers¶

We kunnen niet over een demografie praten in de zin dat alle Krita gebruikers die we kennen 55 jaar oude mannen zijn. Krita wordt gebruikt door zeer verschillende mensen, en we zijn er eigenlijk trots op dat dergelijke verschillende gebruikers hebben.

Desondanks weten we een paar dingen over onze gebruikers:

Ze zijn artiesten. Dat zijn duidelijk het soort gebruikers wat we als doel hebben.
- Daarom weten we dat ze de voorkeur geven aan mooie afbeeldingen,
- Ze zijn visueel.
- Ze proberen om mooie afbeeldingen te maken.

Het uiteindelijke doel van elke pagina zou daarom moeten zijn dat de functionaliteit wordt gebruikt voor mooie afbeeldingen.

Afgezien hiervan hebben we de volgende groepen gesignaleerd:

Studenten van de middelbare school die die teken-programma’s uitproberen. Zij hebben meestal al enige ervaring met teken-programma’s, zoals Paint Tool SAI of Photoshop, maar moeten wegwijs gemaakt worden in de mogelijkheden van Krita. De kracht van deze groep is dat ze veel informatie met elkaar delen zoals tips en tricks en tutorials.
Beroeps, mensen die hun salaris verdienen met digitale teken-programma’s. De kracht van deze groep is dat ze veel kennis hebben en bereid zijn om voor verbeteringen van het programma te doneren. Ze zijn er in twee types:
- Niet technische beroeps. Dit zijn mensen die de meer wiskundige formules in een stuk software niet echt begrijpen, maar in de loop der jaren een goede werkmethodiek hebben ontwikkelt en met programma’s werken door hun goed ontwikkelde instinct te volgen. Dit zijn meestal illustratoren, schilders en drukkers.
- Technische beroeps. Dit zijn mensen die Krita als onderdeel van een pipeline gebruiken, en de precieze formules en hoe de pixels verplaatst worden belangrijk vinden. Dit zijn meestal mensen die games en VFX industrie werken, maar soms is er ook een wetenschapper bij.
Volwassen en gepensioneerde hobbyisten. Deze groep heeft niet veel kennis over computers, en zij lijken altijd te struikelen over dat ene kleine ontbrekende stapje in de instructie. Hun kracht als groep is dat ze ongewone werkmethodieken ontwikkelen die studenten niet kennen en waarvoor de beroeps geen tijd voor hebben en waarmee ze leuke dingen mee creëren, maar ook dat ze in de grotere gemeenschap een kalmerend effect op de eerste groep hebben.

Van deze vier groepen…

is er maar een dat technisch is. Daarom hebben we de concept pagina’s nodig, zodat we een solide basis hebben om de tekst van onze handleiding te schrijven.
drie van hun hebben waarschijnlijk eerdere ervaring met programma’s en hebben misschien overstap-instructies nodig
twee van hun willen weten hoe Krita samenwerkt met andere programma’s.
twee van hun hebben geen idee wat ze doen en hebben misschien hulp nodig bij de meest eenvoudige stappen.

Hieruit komen de volgende regels:

Algemene teksten¶

Gebruik zoveel mogelijk Amerikaans Engels.: We gebruiken in de handleiding Amerikaans Engels, in overeenstemming met dat de Krita’s UI standaard Amerikaans Engels gebruikt.
Houd de taal beleeft, maar gebruik geen academische taal.: Als gemeenschap willen we open staan voor gebruikers, daarom proberen we onvriendelijke taal te vermijden. Vloeken is al niet toegestaan bij KDE, maar helemaal naar de andere kant doorslaan, een academische stijl wat afstand houd van zowel de schrijver als de lezer kan het idee geven dat de tekst veel complexer dan noodzakelijk is en kan dus de lezer afschrikken.
Vermijdt het gebruik van GIFs (staat ter discussie): De reden is dat mensen met epilepsie last kunnen hebben van snel bewegende plaatjes. Vergelijkbaar kunnen GIFs teveel uitleg nodig hebben. Als u zonder GIFs niet kan helpen, waarschuw dan tenminste de lezer hiervoor in de introductie van de pagina.
Zorg dat het vertaalbaar is: Dit bestaat uit het gebruik van SVG voor grafieken, en de juiste opmaak voor een betreffende tekst.

Wat betreft foto’s en schilderijen¶

We zouden het gebruik van foto’s en traditionele schilderijen in de handleiding afraden als ze niet een concept illustreren. De reden is dat het vrij kinderachtig en een beetje oneerlijk overkomt als we een Rembrand in de Krita GUI tonen, terwijl we zoveel modernere werken hebben die met Krita gemaakt zijn. Alles van de Pepper&Carrot kunst is gemaakt in Krita en de originele bestanden zijn beschikbaar, als u dus geen afbeelding beschikbaar heeft, start dan hier. Foto’s moet u vermijden omdat Krita een schilder-programma is. Teveel foto’s kunnen de indruk geven dat Krita probeert om een oplossing te zijn voor het retoucheren van foto’s, terwijl dat echt niet de focus is.
Natuurlijk willen we bepaalde concepten die bij foto’s en beroemde schilderijen spelen laten zien, zoals as glimmen of indirect licht. Voeg in dat geval een onderschrift toe wat de naam van het schilderij of schilder vermeld, of wat vermeld dat het een foto is.
Foto’s kunnen natuurlijk nog steeds bij photobashing en dergelijke worden gebruikt, maar alleen als het duidelijk in de context van photobashing is.

Wat betreft afbeeldingen in het algemeen¶

Vermijd tekst in afbeeldingen en gebruik in plaats daarvan de onderschrift.U kunt dit doen met de figure instructie.
Als het gebruik van tekst noodzakelijk is, maak dan naar keuze een SVG, zodat de tekst daarin makkelijker bewerkt kan worden, of probeer de hoeveelheid tekst te minimaliseren.
Probeer uw afbeeldingen zo goed mogelijk te maken. Geef de mensen het idee dat een programma gebruiken om te tekenen!
Vergeet niet dat de handleiding onder de licentie GDPL 1.3 vallen, zodat ook de gedoneerde afbeeldingen ook onder deze licentie vallen. Zorg ervoor dat in het geval van CC-By-Sa/CC-By dat het bestand een correcte verwijzing in het onderschrift van de afbeelding krijgt. Overbodig om te zeggen, doneer geen afbeeldingen die niet onder een van deze licentie kunnen vallen.

Protocol¶

Hier zetten we nog een keer alle saaie werkmethodieken op een rij.

Taggen en Branches¶

Het toevoegen en verwijderen van tekst doet u in de draft branch.

De resultaten van het nalezen van oude pagina’s worden als bugfixes beschouwt en zullen dus in de master branch terechtkomen en later indien nodig met de draft branch worden samengevoegd.

Voordat de draft branch wegens een bepaalde release wordt samengevoegd:

De master branch wordt getagged met de oude versie.
De draft branch wordt eerst dubbel gecontroleerd dat het de nieuwe versie nummer en een bijgewerkte epub cover heeft.

De draft branch wordt niet eerder samengevoegd dan de dag voor een release om de pagina’s lang genoeg intact te houden.

Bij elke release zal een versie van de epub worden geupload als onderdeel van het release proces. .. Waar komen de POT-bestanden vandaan? Zelfs de vertaalde versies?

Pagina’s verwijderen¶

Als in een bepaalde versie een functionaliteit is verwijdert, dan zullen de corresponderende pagina’s:

Eerst worden gemarkeerd als deprecated.

Dit kan als volgt worden gedaan:

.. deprecated:: versie nummer

    Tekst dat aangeeft wat de gebruiker zou moeten doen zonder deze functionaliteit.

Krijgt een koppeling op een pagina genaamd ‘deprecated’
Als de volgende versie wordt verspreid, dan zullen alle pagina’s in de deprecated sectie worden verwijderd.

Pagina’s toevoegen¶

Controleer dat het op de correcte locatie staat.
Volg de Mark-up conventies voor de Krita handleiding om er zeker van te zijn dat de pagina correct is opgemaakt.
Voeg de pagina toe aan de TOC.

Als de functionaliteit nieuw is, voeg het dan toe in versionadded:

.. versionadded:: versie nummer

    optioneel nog iet anders.

Net zoals met afbeeldingen, voeg geen tekst toe waarvoor u geen toestemming heeft om het te doneren. Dit houd in dat u de tekst zelf heeft geschreven, of dat u toestemming van de originele auteur heeft om het om te zetten. De handleiding is GDPL 1.3+ zodat de tekst hieronder zijn herlicentie krijgt.

Pagina’s wijzigen¶

Als u een pagina volledig herschrijft, in plaats van het te controleren, dan zou de resulterende pagina gereviewed moeten worden.

Als u een pagina wijzigt omdat een functionaliteit is gewijzigd, en u heeft commit toegang, dan kan de wijziging pushed (vastgelegd) zonder review (tenzij u zich comfortabeler voelt met een review), maar u moet wel toevoegen:

.. versionchanged:: versie nummer

    Dit en dat is gewijzigd.

In alle gevallen, bedenk of u uw eigen naam aan het auteursveld in de metadata sectie bovenaan wilt toevoegen.

Door deprecated, versionadded en versionchanged met de versienummer te gebruiken, kunnen we makkelijker de handleiding met grep op deze termen kunnen doorzoeken:

grep -d recurse versionadded * --exclude-dir={_build,locale}

Pagina’s met fouten¶

Als een pagina er tussendoor slipt, voer dan naar keuze uit…

Maak dan een merge verzoek zoals beschreven in de Wijzigingen aanbrengen sectie.
Maak een taak aan op het Manual Project Workboard.
Maak een bugrapport aan op bugzilla in het project Krita in de sectie ‘documentation’.

Nalezen¶

Er zijn twee soorten nalezen dat moet worden gedaan.

De meest belangrijke is de wijzigingen die mensen hebben gemaakt reviewen. U kunt dit in KDE_gitlab op twee manieren doen:

Merge verzoeken nakijken

U kunt helpen bij het reviewen van merge verzoeken. Het reviewen van request wordt normaal gesproken gedaan door programmeurs om fouten te vinden in elkaars code, maar omdat programma-code tekst-gebaseerd is net zoals gewone tekst, kunnen we dit ook gebruiken om te controleren op typefouten!

Een merge verzoek is een aantal wijzigingen in een document uitgevoerd (toegevoegd, verwijdert) in een door machines leesbaar bestand. Als iemand een review verzoek (bij systemen zoals gitlab of github is dit een merge of pull request) indient, dan zullen mensen die de originele bestanden beheren ze bekijken en commentaar geven over dingen die anders moeten. Hierdoor kunnen ze commentaar geven over dingen zoals typefouten, te ingewikkelde manier van schrijven maar ook als zaken niet correct zijn. Nadat een patch geaccepteerd is, kant het in het version control system vastgelegd worden..
Commentaar geven op wijzigingen in de handleiding.

Commentaar geven over wijzigingen gebeurt pas nadat het gebeurt is. U kunt commentaar geven op een wijziging door naar het commit bericht (op de opslagruimte-pagina gaat u naar de geschiedenis en klik dan op een item) te gaan, waar u commentaar kunt geven op de gemaakte wijzigingen.

In beide gevallen toont de interface de verschillen, met links de oude versie, en rechts de nieuwe versie. De toegevoegde regels zijn met groen gemarkeerd terwijl de verwijderde regels met rood zijn gemarkeerd. U kunt op de pictogram met de tekstballon klikken om ‘inline’ commentaar toe te voegen..

De tweede belangrijke manier waarop de handleiding moet worden nagekeken is over het hele bestand. Veel pagina’s zijn alleen gecontroleerd of ze correct zijn maar niet op stijl en grammatica.

Dit moet u volgens de Wijzigingen aanbrengen sectie doen, zodat u complete toegang heeft tot de pagina’s en ze kan bewerken.

Vertalen¶

Het vertalen van de handleiding wordt gedaan door de KDE localization community. Om te helpen bij het vertalen gaat u naar de localization site, selecteer u de lijst met vertaal-teams <https://l10n.kde.org/teams-list.php>`_, selecteert u de taal waarnaar u wilt helpen vertalen, en volgt u de instructies op de pagina van het team om in contact te komen met de andere vertalers.

Kijk op https://community.kde.org/Get_Involved/translation voor meer algemene instructies over meedoen in lokalisatie van KDE.

Het vertaal-team heeft toegang tot de PO-bestanden van deze handleiding, wat een bestandsformaat is dat door vertaal-programma’s zoals POEdit en Lokalize wordt gebruikt. Een vertaal-team kan samenwerken om deze bestanden te vertalen en upteloaden naar het vertaal-SVN. Een speciaal script neemt daarna dagelijks de vertalingen uit de SVN om ze naar de betreffende handleiding-sectie te brengen.

Als een vertaal-team hun eigen afbeeldingen wilt maken dan kunnen ze de afbeeldingen vertalen. Standaard zijn alle afbeeldingen in de map images voor ‘en’. Als u een specifieke afbeelding wilt vertalen, dan gaat u naar die map en voegt u een andere map toe met uw taalcode als naam om daarin de vertaalde versies van de afbeeldingen te plaatsen. Sphinx zal dan zoeken naar de Nederlandse versie van /images/Pixels-brushstroke.png in /images/nl/Pixels-brushstroke.png en voor de Nederlandse versie van /images/dockers/Krita-tutorial2-I.1-2.png in /images/dockers/nl/Krita-tutorial2-I.1-2.png.

Vertalingen die klaar zijn, moeten ook aan de build script toegevoegd worden voordat ze online zichtbaar zijn. Vertaal-teams die vertrouwen hebben in de staat van hun vertalingen , kunnen contact opnemen met het main Krita team via de kimageshop mailinglist(kimageshop@kde.org), of foundation@krita.org, om dit in orde te krijgen.

Overig¶

Voor afspraken over restructured text, lees Mark-up conventies voor de Krita handleiding.