Guia de col·laboració al Manual del Krita¶

Us donem la benvinguda a la guia de col·laboració amb el Manual del Krita!

Si esteu interessat a col·laborar amb la documentació del Krita, esteu en el lloc correcte.

El Krita és un programari de codi obert (lliure), el qual ens converteix efectivament en un projecte comunitari amb dotzenes de voluntaris col·laborant per a millorar-lo. Això, per descomptat, requereix que fem un seguiment dels manuals i els procediments perquè vinguin i ens ajudin nous voluntaris. Els diversos llocs en els quals hem fet això s'han estès força, de manera que el manual del col·laborador és un intent de consolidar tota la informació. Per tant, en alguns llocs és molt tècnic.

Aquesta documentació inclourà:

Un manual de referència per al Krita

Això probablement és el que tothom espera quan cerquen a la documentació del Krita. En sec, bàsicament dona el tipus d'informació «què fa aquest botó».

Guies d'aprenentatge dels conceptes generals

En els últims dos anys hem descobert que per a certs tipus d'usuaris, un manual de referència, fins i tot amb alguns exemples, simplement no és suficient. El manual també ha de proporcionar explicacions ràpides i concises de les coses, i proporcionar un flux de treball bàsic per a preparar una imatge per a la web.

També hem descobert que certs conceptes, com la gestió del color i el maneig de les capes, estan molt més avançats en el Krita del que l'artista mitjà està acostumat. El Krita és lliure i molts dels seus usuaris no tenen capacitació formal en el treball artístic digital. Per tant, no existeix un coneixement previ centrat en l'artista sobre com utilitzar la gestió del color o les capes de filtratge.

A més, hi ha sistemes que són exclusius del Krita, per exemple, el sistema de pinzells, les màscares de transformació, l'herència alfa i els assistents de perspectiva. Finalment, hi ha usuaris que no estan familiaritzats amb els fluxos de treball de la pintura estàndard, i no són prou flexibles per a entendre com adaptar una guia d'aprenentatge per al SAI o Photoshop al Krita.

Una llista de les guies d'aprenentatge i vídeos coneguts

Aparentment, una de les millors coses de l'equip del Krita és com connectem amb els artistes i reconeixem que estan fent coses genials. El mateix hauria de comptar per a les guies d'aprenentatge, especialment perquè hi ha formes d'utilitzar el Krita i formes d'apropar-se a la pintura que són úniques i hem d'encoratjar a les persones a compartir el seu coneixement.

Manual dels col·laboradors

Què esteu llegint ara mateix!

Guies d'aprenentatge a krita.org

Hi ha hagut un munt de guies d'aprenentatge a krita.org i a la krita-foundation.tumblr.com, les primeres se centren a explicar com utilitzar una característica nova i les segones són estimulades per les peticions dels usuaris.

PMF

Aquesta ja està en línia i és una fusió de les diferents preguntes freqüents (PMF) que teníem. En l'actualitat s'està traduint i esperem que aquesta sigui la principal a l'hora d'actualitzar.

Per primera vegada¶

A diferència del Mediawiki, l'Sphinx funciona més en la manera com escrivim codi per al Krita.

El primer és el primer. Voldreu parlar amb nosaltres! Per a això, podeu unir-vos a la sala de xat «#krita» a través de Matrix. Aquí s'ofereix una introducció sobre Matrix. Creeu una matriu en el compte webchat.kde.org i uniu-vos al canal #krita:kde.org. O el que és més important, creeu un compte a identity.kde.org. El compte que creeu a Identity es podrà utilitzar tant per a accedir a invent.kde.org com al phabricator, on organitzem el desenvolupament del Krita.

L'Sphinx funciona escrivint senzills fitxers de text amb el marcatge reStructuredText, i després pren aquests fitxers de text i els converteix en el manual. Portem un seguiment dels canvis en el manual posant-los en un sistema de control de versions anomenat Git.

Fer canvis¶

A causa que utilitzem el Git, només hi ha unes poques persones que poden pujar coses al sistema de control de versions, de manera que si voleu fer canvis, haureu de col·locar-los per a la seva revisió.

Crear peticions de fusió («merge request» -MR-) emprant el mode Edició¶

Nota

Aquest mètode només és adequat si no teniu accés de fer «push» als repositoris del KDE. En cas contrari, cometeu els canvis directament al repositori, el qual va en contra de les directrius actuals.

Recomanat per a usuaris sense coneixements tècnics.

No es recomana quan vulgueu canviar més d'un fitxer alhora. (Vegeu Crear peticions de fusió («merge request» -MR-) emprant el WebIDE o Crear peticions de fusió («merge request» -MR-) emprant la línia d'ordres si voleu canviar més fitxers, o simplement editeu-ne un per a crear la petició de fusió).

Si voleu contribuir amb molts canvis, recomanem que intenteu seguir aquestes instruccions.

Obteniu una identitat del KDE.
Accediu al KDE_gitlab.
Aneu al repository i premeu Fork (Bifurca).
Ara hauríeu de ser redirigit a la bifurcació del vostre repositori. En general, es troba a invent.kde.org/NOM_KDE_PER_ACCEDIR/docs-krita-org.
Torneu al repositori oficial. Assegureu-vos d'estar navegant per Documentation > Krita.org Documentation, no per la vostra pròpia bifurcació. Altrament, aquest mètode no funcionarà correctament.

El Gitlab té una opció per a editar els fitxers al mateix GitLab. Per a accedir-hi, aneu a «Repositori ‣ Fitxers».

A la part superior de la pàgina, hauríeu de veure una llista desplegable amb master com a element triat.

Cerqueu el fitxer que voleu editar, obriu-lo i després feu clic a Edita.

Feu els vostres canvis. (Nota: en aquest mode només podreu editar un fitxer alhora).

Aneu al quadre de text més petit que hi ha a continuació i escriviu un bon missatge a la secció del missatge de comissió (commit) amb els canvis que heu realitzat. Quan acabeu, premeu Commit changes (Comet els canvis). Això crearà una petició de fusió, simplement completeu tots els camps com s'explica aquí: Directrius per a les peticions de fusió («merge request» -MR-) noves.

El desavantatge és que en aquest moment no hi ha forma de saber si emprant aquest mètode heu entregat errors amb el marcatge. Verifiqueu els vostres canvis amb l'Editor de Sphinx en línia (simplement copieu i enganxeu tot el fitxer que esteu editant).

Atenció

Edita i el WebIDE són dues coses diferents! Assegureu-vos que heu seleccionat Edita.

Crear peticions de fusió («merge request» -MR-) emprant el WebIDE¶

Recomanat per a usuaris amb una mica de coneixement sobre Git que volen editar múltiples fitxers alhora.

No es recomana quan no sabeu què és una branca (en el seu lloc, vegeu Crear peticions de fusió («merge request» -MR-) emprant el mode Edició).

Seguiu les anteriors instruccions per a iniciar una sessió al KDE_gitlab i creeu la vostra bifurcació.
Aneu a la vostra bifurcació (assegureu-vos que l'URL contingui el vostre nom d'usuari).
Assegureu-vos que esteu a la branca master.
Feu clic al WebIDE. Això hauria de portar-vos a una pàgina que té una llista de fitxers al costat esquerre i un gran espai buit per al contingut del fitxer al costat dret.
Obriu els fitxers que voleu editar i feu els canvis.
Feu clic a Commit... (Comissió). Feu doble clic a tots els fitxers a la categoria Unstaged changes (Canvis sense classificar) per a moure'ls a Staged changes (Canvis preparats).
Feu clic a Commit... (comissió) de nou: s'expandirà un quadre de text del missatge de la comissió. Escriviu-hi un missatge que expliqui quins canvis heu realitzat i per què.
Assegureu-vos que les opcions de configuració són correctes: haureu de seleccionar Create a new branch (Crea una branca nova) (el nom de la branca haurà de ser: [nom_usuari]/[descripció_molt_breu_dels_vostres_canvis]). Si els heu acabat, assegureu-vos que heu marcat Start a new merge request (Inicia una petició de fusió nova). En cas contrari, més tard haureu de realitzar una petició de fusió nova manualment.
Feu clic a Stage & Commit (Etapa i comissió).
Empleneu tots els camps correctament: vegeu les Directrius per a les peticions de fusió («merge request» -MR-) noves.
Per a crear una petició de fusió nova manualment, aneu al repositori oficial del «Krita Manual» (assegureu-vos que l'URL ara no conté el nom d'usuari) i feu clic a Create a new merge request (Crea una petició de fusió nova) (el botó verd brillant que hi ha a l'esquerra). Seleccioneu la vostra bifurcació i la branca que heu creat al WebIDE.

Nota

Si no teniu accés de «push» (publicació) al repositori oficial, el GitLab no us permetrà desar els canvis si per error estàveu editant el repositori oficial (i Create a merge request (Crea una petició de fusió) no ajudarà amb això: encara necessiteu cometre (commit) els canvis a la vostra branca, però si no teniu accés de «push», no podreu fer-ho). Simplement es mostrarà el missatge: S'ha produït un error en cometre els canvis. Intenteu-ho de nou.

En aquest cas, simplement copieu el contingut de tots els fitxers que heu modificat, aneu a la vostra bifurcació i enganxeu-los a la bifurcació del WebIDE.

Crear peticions de fusió («merge request» -MR-) emprant la línia d'ordres¶

Està recomanat per als usuaris que saben com funciona el Git i com utilitzar la línia d'ordres.

No es recomana quan no sabeu què és una branca (en el seu lloc, vegeu Crear peticions de fusió («merge request» -MR-) emprant el mode Edició).

Seguiu les anteriors instruccions per a iniciar una sessió al KDE_gitlab i creeu la vostra bifurcació.
Cloneu localment el repositori amb git clone. La pàgina del repositori té els URL des dels quals podreu fer-ho, i després feu «push» a la vostra bifurcació. L'avantatge d'això és que podreu utilitzar totes les eines a l'ordinador per a editar aquests fitxers de text, així com construir el manual localment per a verificar si hi ha cap error. (Només haureu de fer aquest pas una vegada).
# per a accés amb SSH git clone git@invent.kde.org:<nom_usuari>/docs-krita-org.git git remote add upstream git@invent.kde.org:documentation/docs-krita-org.git # per a accés amb HTTPS git clone https://invent.kde.org/<nom_usuari>/docs-krita-org.git git remote add upstream https://invent.kde.org/documentation/docs-krita-org.git
Recordeu fer «pull» (extreure) sempre per als canvis des del repositori oficial abans de realitzar canvis nous:
git pull upstream master
Assegureu-vos de crear una branca nova per als vostres canvis, des de setembre de 2019, tots els canvis hauran de bifurcar-se des de la branca master.
git checkout master # i després: git checkout -b "<nom_usuari>/<descripció_de_la_característica_nova>"

Després de fer els canvis, feu «commit» (cometre) i «push» (publicar) a la vostra branca. Per a obtenir una descripció detallada sobre com utilitzar el Git des del terminal en un cas com aquest flux de treball, aneu a Forking on Gitlab.

# instal·leu el paquet python3-sphinx per al vostre sistema. Per exemple, per a la Ubuntu:
sudo apt install python3-sphinx
# construïu el manual (informa dels errors potencials, permet inspeccionar canvis en el navegador)
make html
# assegureu-vos que tot és correcte
git status
git diff
# afegiu tots els fitxers
git add .
# cometeu els vostres canvis
git commit
# entregueu els canvis a la vostra bifurcació
git push

Finalment, aneu al lloc web del repositori original, i després a «Merge Requests» (Peticions de fusió). Seleccioneu la vostra bifurcació, la branca correcta i creeu una petició de fusió nova. Per a obtenir instruccions sobre com omplir els camps, vegeu les Directrius per a les peticions de fusió («merge request» -MR-) noves.

Directrius per a les peticions de fusió («merge request» -MR-) noves¶

Els vostres missatges de comissió (commit) hauran de complir amb els estàndards que s'expliquen aquí: How to Write a Git Commit Message (Com escriure un missatge de comissió al Git)
El Títol i la Descripció hauran d'explicar quins canvis heu realitzat i per què, com en un missatge de commit (comissió), de manera que aquí també haureu de seguir les pautes de l'enllaç anterior.
Target (Destinació) haurà d'apuntar a master.
Si esteu segur que la petició de fusió exigirà alguns canvis més endavant, poseu [WIP] al començament del títol de la vostra petició de fusió.
Assegureu-vos de marcar Allow commits from members who can merge to the target branch (Permetre les comissions dels membres que poden fusionar amb la branca de destinació) -sovint és necessari per raons tècniques que la petició de fusió faci «rebase» sobre master, el qual tècnicament canviarà la petició de fusió, però no canviarà el contingut real d'aquesta. Vós o el revisor podran realitzar el «rebase»- si no voleu que us molestin més tard, marqueu aquesta casella de selecció perquè el revisor pugui fer-ho sol amb uns quants clics.
En la majoria dels casos podreu marcar amb seguretat Delete source branch when merge request is accepted (Suprimeix la branca d'origen quan s'accepti la petició de fusió).
A menys que els revisors us indiquin el contrari, marqueu Squash commits when merge request is accepted (Aixafa les comissions quan s'accepti la petició de fusió). La primera línia del missatge d'entrega esdevindrà del títol de la vostra petició de fusió i la resta es prendrà des de la Descripció de la vostra petició de fusió.
Quan acabeu de crear la vostra petició de fusió, aneu a l'IRC i (vegeu Internet Relay Chat) i demaneu-li a algú amb accés de «push» que afegeixi l'etiqueta Needs Review (Necessita revisió) a la vostra petició de fusió.
Si aquesta conté errors, és possible que rebeu comentaris sobre la vostra petició de fusió. Simplement corregiu-los a la vostra branca d'una de les següents maneres.
- Si voleu utilitzar el mode Edita, simplement aneu a la secció Changes (Canvis) de la petició de fusió i feu clic sobre la icona de llapis (amb un consell d'eina que diu Edita).
- Si voleu utilitzar el Mode WebIDE, aneu a la vostra bifurcació, seleccioneu la branca que conté els canvis i aneu al WebIDE.
- Si editeu els fitxers a l'ordinador i treballeu amb el terminal, assegureu-vos d'estar a la branca correcta i feu «push» (publiqueu) els vostres canvis -el GitLab actualitzarà la vostra petició de fusió de manera automàtica-.
Després de fer els canvis, assegureu-vos de demanar-li a algú que canviï l'etiqueta altra vegada a Needs Review (Necessita revisió).

Per a obtenir informació més detallada, reviseu Forking on Gitlab a la secció tècnica.

Nota

Al moment d'escriure aquesta guia, l'establiment de les etiquetes a les peticions de fusió només és possible per als col·laboradors amb accés d'escriptura al repositori oficial. (Si no sabeu què vol dir això, probablement no sou un d'ells). Per això, quan creeu o canvieu la vostra petició de fusió, haureu d'entrar a l'IRC (vegeu La comunitat del Krita) i demaneu-li a algú que l'etiqueti.

Construir el manual des de la línia d'ordres¶

Per a aquells que primer vulguin provar alguns canvis abans d'embarcar-se immediatament en una petició de fusió (i ja saben com utilitzar el Git i la línia d'ordres), això es descriu com a part del pas 5 a Crear peticions de fusió («merge request» -MR-) emprant la línia d'ordres.

Filosofia general¶

Serveix per a determinar quin serà un estil d'escriptura adequat. Un estil d'escriptura, tant si tenim en compte les seves qualitats pràctiques com estètiques, generalment es basa en un objectiu o filosofia general. Què volem aconseguir amb el manual i per a qui serà?

Demografia i públic de destinació¶

No podem parlar d'un grup demogràfic en el sentit que sabem que tots els usuaris del Krita són homes de 55 anys. El Krita és utilitzat per una quantitat molt diversa de persones, i estem realment orgullosos de tenir una base d'usuaris tan variada.

Tot i això, sabem un parell de coses sobre els nostres usuaris:

Són artistes. Aquest és explícitament el tipus d'usuaris als quals ens dirigim.
- Per tant, sabem que prefereixen imatges boniques.
- Són visuals.
- Miren d'aconseguir imatges boniques.

Per tant, l'objectiu implícit de cada pàgina serà plasmar la característica emprada per a imatges boniques.

A part d'això, hem observat els següents grups:

Estudiants de secundària i universitaris que proven programari de dibuix per a il·lustracions. En general, no tenen cap experiència anterior amb un programari de dibuix, com el Paint Tool SAI o el Photoshop, però necessiten una introducció a les possibilitats en el Krita. El punt fort d'aquest grup és que comparteixen molta informació entre ells, com consells, trucs i guies d'aprenentatge.
Professionals, gent que es guanya la vida amb el programari de dibuix digital. El punt fort d'aquest grup és que tenen molts coneixements i estan disposats a fer donacions per a millorar el programa. Venen en dos tipus:
- Professionals no tècnics. Són gent que en realitat no comprenen les peculiaritats més matemàtiques d'una peça de programari, però que han desenvolupat fluxos de treball sòlids al llarg dels anys i treballen amb programari utilitzant els seus instints finament perfeccionats. Tendeixen a ser il·lustradors, pintors i persones que treballen amb la impressió.
- Professionals tècnics. Són gent que utilitzen el Krita com a part d'un flux, i es preocupen per les matemàtiques precises i l'empenta dels píxels. Solen ser gent que treballa a la indústria dels jocs i els efectes visuals, però a vegades també hi ha algun científic.
Adults i gent gran aficionada. Aquest grup no sap gaire sobre els ordinadors, i sempre semblen enredar-se en aquest petit pas quan manca una guia d'aprenentatge. El seu punt fort com a grup és que adapten fluxos de treball no convencionals de la vida real que l'estudiant no coneix i amb els quals el professional no té temps per a crear coses genials, així com que tenen un efecte moderador sobre l'entusiasme excessiu en tota la comunitat.

D'aquests quatre grups...

Només n'hi ha un que és tècnic. És per això que necessitem les pàgines de concepte, perquè puguem crear una base sòlida sobre la qual escriure els nostres textos del manual.
És probable que tres d'ells no tinguin experiència amb el programari i que necessitin guies de migració i se'ls hagi de dir com fer-ho.
Dos d'ells necessiten saber com fer que el Krita cooperi amb un altre programari.
Dos d'ells no tenen ni idea del que estan fent i és possible que necessitin ser guiats pels passos més bàsics.

D'això obtenim les següents regles:

En general durant l'escriptura¶

Emprar l'anglès americà si és possible: Emprarem l'anglès americà en el manual, d'acord amb la interfície d'usuari del Krita, la qual de manera predeterminada està en anglès americà.
Mantenir un idioma educat, però no utilitzeu llenguatge acadèmic: Com a comunitat, volem donar la benvinguda als usuaris, de manera que tractarem d'evitar un llenguatge que no sigui de benvinguda. Per descomptat, el KDE no accepta les paraulotes, però anant a l'altre extrem, un estil acadèmic en el qual no es reconeix ni a l'escriptor ni al lector podria donar la idea que el text és molt més complex del que és necessari i, per tant, farà fugir als usuaris.
Eviteu utilitzar GIF (està obert al debat): La raó és que les persones amb epilèpsia poden veure's afectades per imatges en moviment ràpid. De la mateixa manera, els GIF de vegades poden portar massa càrrega de l'explicació. Si no ho podeu evitar, almenys notifiqueu-ho al lector a la introducció de la pàgina.
Mantenir-ho compatible amb la traducció: Això consisteix a utilitzar SVG per a les infografies i el marcatge adequat per a un text donat.

Pel que fa a les fotografies i pintures¶

Ens agradaria desencoratjar les fotografies i pintures tradicionals en el manual si no il·lustren un concepte. La raó és que és molt ximple i una mica deshonest mostrar el treball de Rembrandt dins de la IGU del Krita, quan tenim tantes obres modernes que es van crear amb el Krita. Tot el treball artístic a Pepper&Carrot es va crear en el Krita i està disponible amb els fitxers originals, de manera que quan no tingueu una imatge a mà, comenceu allà. S'han d'evitar les fotografies perquè el Krita és un programa de pintura. Massa fotografies poden fer la impressió que el Krita tracta de ser una solució per al retoc fotogràfic, el qual en realitat no és el nostre objectiu.
Per descomptat, encara voldrem mostrar alguns conceptes amb les fotografies i pintures, com fer veladures o la llum indirecta. En aquests casos, afegiu una llegenda que esmenti el nom de la pintura o del pintor, o esmenti que es tracta d'una fotografia.
Les fotografies encara es poden utilitzar per a basar-se en les fotografies («foto-bashing») i similars, però només si òbviament s'utilitza en aquest context.

Pel que fa a les imatges en general¶

Eviteu el text en les imatges i en el seu lloc utilitzeu la llegenda («caption»). Podreu fer-ho amb la directiva «figure».
Si necessita utilitzar text, creeu un SVG, perquè el text que contingui es pugui manipular amb més facilitat, o intenteu minimitzar la quantitat de text.
Intenteu crear les vostres imatges en alta qualitat/boniques. Donem-li a la gent la idea que estan utilitzant un programa per a dibuixar!
Recordeu que el manual està llicenciat sota la GDPL 1.3, de manera que les imatges enviades estaran sota aquesta llicència. En el cas de CC-By-Sa/CC-By, assegureu-vos que el fitxer s'atribueix de manera adequada a través d'una llegenda a «figure». No cal dir que no envieu imatges que no puguin restar sota cap d'aquestes llicències.

Protocol¶

Així que aquí detallem tots els fluxos de treball avorrits.

Etiquetatge i branques¶

L'addició i eliminació de text es farà a la branca draft.

El resultat de la revisió per a pàgines antigues es considerarà com a esmenes d'errors i, per tant, aniran a la branca master i es fusionaran a dins de la branca draft segons sigui necessari.

Abans de fusionar a la branca draft per a un cert llançament:

La branca master s'etiquetarà amb la versió anterior.
Primer es verificarà la branca draft perquè hagi actualitzat el número de versió i la portada de l'epub.

La branca draft no es fusionarà fins al dia anterior a un llançament per tal de mantenir les pàgines intactes durant el temps suficient.

Cada llançament tindrà carregada una versió de l'epub com a part del procés de llançament. On obtenim els fitxers POT? I les versions traduïdes?

Eliminar pàgines¶

Si s'elimina una característica en una certa versió, les pàgines corresponents:

Primer s'hauran de marcar com a obsoletes.

Això es pot fer de la següent manera:

.. deprecated:: número_de_versió

    Text per a indicar què haurà de fer l'usuari sense aquesta característica.

Es vincularà amb una pàgina anomenada «deprecated» (obsoleta).
Si apareix la pròxima versió, s'eliminaran totes les pàgines vinculades amb la secció obsoleta.

Afegir pàgines¶

Assegureu-vos que estiguin ubicades en el lloc correcte.
Seguiu les Convencions del marcatge per al Manual del Krita per a assegurar-vos que la pàgina estigui amb el format correcte.
Afegiu la pàgina a la TOC (taula de contingut).

Si la característica és nova, afegiu-la a versionadded:

.. versionadded:: número_de_versió

    Quelcom opcional o alguna altra cosa.

Igual que amb les imatges, no afegiu text si no teniu permís per a afegir-lo. Això vol dir que el text l'heu escrit vosaltres o que teniu permís per part de l'autor original. El manual és GDPL 1.3+, per tant, el text es tornarà a llicenciar segons aquesta.

Canviar a les pàgines¶

Si reescriviu completament una pàgina, en lloc de corregir-la, la pàgina resultant s'haurà de revisar.

Canvieu una pàgina perquè una característica ha canviat i teniu accés de comissió (commit), el canvi es pot enviar sense revisió (a no ser us resulti més còmode amb una revisió), però haureu d'afegir:

.. versionchanged:: número_de_versió

    S'ha canviat això i això.

En tots els casos, comproveu si voleu afegir-vos al camp d'autor a la secció de les metadades que hi ha a la part superior.

L'ús de «deprecated», «versionadded» i «versionchanged» amb el número de versió ens permet cercar amb facilitat en el manual emprant aquests termes amb l'ordre «grep»:

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

Pàgines amb defectes¶

Si alguna cosa va malament amb la pàgina...

Creeu una petició de fusió segons la secció Fer canvis.
Creeu una tasca al Manual Project Workboard.
Creeu un error al bugzilla sota el projecte Krita a la secció «documentation».

Cal revisar¶

Hi ha dos tipus de correccions que s'hauran de fer.

La més important és revisar els canvis que fa la gent. Això es pot fer al KDE_gitlab de dues maneres:

Revisant les peticions de fusió

Podeu ajudar a revisar les peticions de fusió. En general, els programadors fan la revisió de les peticions per a trobar errors en el codi de l'altra, però com que el codi de programació es basa en text de la mateixa manera que el text normal, també podem emprar això per a verificar els errors tipogràfics!

Una petició de fusió, és una quantitat de canvis realitzats en un document (afegit, eliminat) col·locat en un fitxer de lectura per la màquina. Quan algú envia una petició de revisió (en un sistema com el GitLab o GitHub, aquesta serà una petició de «merge» (fusió) o «pull» (publicació)), la gent que manté els fitxers originals hauran de revisar-los i poden fer comentaris sobre les coses que necessiten canviar. Això els permetrà comentar coses com errors tipogràfics, escriptura massa complicada, però també coses que són incorrectes. Una vegada que s'ha acceptat un pedaç, es podrà publicar (fer «push») en el sistema de control de versions.
Comentant els canvis en el manual

Els comentaris sobre els canvis ocorreran després del fet. Podreu comentar un canvi anant al missatge de comissió (des de la pàgina del repositori, aneu a l'historial i després feu clic sobre una entrada). Allà podreu fer comentaris sobre els canvis realitzats.

En ambdós casos, la interfície consisteix en la diferència que es mostra, amb la versió antiga a l'esquerra i la versió nova a la dreta. Les línies que s'hagin afegit es marcaran en verd, mentre que les línies que s'hagin eliminat es marcaran en vermell. Podreu fer clic sobre la icona d'un cercle de debat per a afegir un comentari «a la línia».

La segona forma principal en què el manual necessita ser revisat és sobre tots els fitxers. Moltes de les pàgines només han estat verificades per a la seva correcció, però no pel seu estil i gramàtica.

Per a això, haureu de seguir la secció Fer canvis, de manera que pugueu tenir accés complet a les pàgines i editar-les.

Traduir¶

La traducció del manual és manejada per la Comunitat de Localització del KDE. Per a unir-vos a l'esforç de traducció, aneu al lloc de localització, seleccioneu la llista dels equips de traducció, seleccioneu l'idioma per al qual voleu traduir i seguiu les instruccions que hi hagi a la pàgina de l'equip per a posar-vos en contacte amb l'equip de traducció.

Consulteu https://community.kde.org/Get_Involved/translation per a obtenir més instruccions generals per a participar en la localització del KDE.

L'equip de localització té accés als fitxers PO per a aquest manual, el qual és un tipus de fitxer emprat pels programes de traducció com el POEdit i el Lokalize. Un equip de traducció pot treballar conjuntament per a traduir-los i pujar-los traduïts al SVN. Després, diàriament un script especial prendrà les traduccions des del SVN i les portarà a la secció del manual per tal d'incorporar-les.

Les imatges es poden traduir si un equip de traducció vol proporcionar les seves pròpies imatges. Totes les imatges a la carpeta «images» estan de manera predeterminada en anglès («en»). Quan vulgueu traduir una imatge específica, aneu a la carpeta «images» i afegiu una altra carpeta amb el vostre codi d'idioma («ca» per al català) per a afegir les versions traduïdes de les imatges. Llavors, l'Sphinx cercarà una versió neerlandesa de /images/Pixels-brushstroke.png a /images/nl/Pixels-brushstroke.png i per a /images/dockers/Krita-tutorial2-I.1-2.png la cercarà a /images/dockers/nl/Krita-tutorial2-I.1-2.png.

Les traduccions acabades també s'hauran d'afegir a l'script de compilació per a aparèixer en línia. Els equips de traductors que confien en l'estat de la seva traducció ho hauran de comunicar a l'equip principal del Krita a través de la llista de correu kimageshop (kimageshop@kde.org), o foundation@krita.org.

Altres¶

Per a les convencions del text reestructurat, comproveu les Convencions del marcatge per al Manual del Krita.