Guida per contribuire al Manuale di Krita¶

Benvenuto/a alla Guida per contribuire al Manuale di Krita.

Se sei interessato/a a contribuire alla documentazione di Krita, ti trovi nel posto giusto.

Krita è un software open source (gratuito), che ci rende davvero un progetto di comunità, con decine di volontari che cercano di renderlo migliore. Questo richiede, naturalmente, che si tenga traccia dei manuali e delle istruzioni affinché nuovi volontari arrivino e ci aiutino. I vari posti dove abbiamo lavorato su questo aspetto sono piuttosto conosciuti, e ricevono spesso poca manutenzione. Il manuale del collaboratore è un tentativo per consolidare tutte le informazioni. È pertanto molto tecnico in alcune parti.

Questa documentazione includerà:

Un manuale di riferimento per Krita

Questo è quello che ognuno si aspetta quando va a cercare la documentazione di Krita. Un tipo d’informazione asciutta, di base, in stile «cosa fa questo pulsante».

Esercitazioni dei concetti generali.

Negli ultimi due anni, abbiamo notato che per certi tipi di utente non basta un manuale di riferimento, anche se contenente alcuni esempi. Il manuale deve fornire anche spiegazioni rapide e concise per le cose, e fornire un flusso di lavoro di base per la preparazione di un’immagine per il web.

Abbiamo anche notato che certi concetti, come la gestione dei colori e dei livelli sono molto più avanzati in Krita rispetto a quanto è abituato l’artista medio. Krita è gratuito e molti suoi utenti non avranno una preparazione formale nell’arte grafica digitale. Non è presente, dunque, una conoscenza preesistente rivolta agli artisti su come utilizzare la gestione dei colori o i livelli dei filtri.

In aggiunta, ci sono sistemi che sono unici di Krita, per esempio il sistema dei pennelli, le maschere di trasformazione, l’eredità alfa e gli assistenti di prospettiva. Infine, esistono utenti che non hanno familiarità neanche con i flussi di lavoro standard di pittura, e non sono abbastanza flessibili per capire come convertire un’esercitazione per SAI o Photoshop a Krita.

Un elenco di esercitazioni e video conosciuti

A quanto pare, uno dei grandi aspetti della squadra di Krita è il modo in cui si connette con gli artisti e riconosce la bontà del loro lavoro. Lo stesso deve valere per le esercitazioni, in particolar modo perché esistono modi per utilizzare Krita e modi di avvicinarsi alla pittura che sono unici e noi dobbiamo incoraggiare le persone a condividere le loro conoscenze.

Manuale dei collaboratori

Quello che stai leggendo in questo momento!

Esercitazioni di krita.org

Nei siti krita.org e krita-foundation.tumblr.com si trovano un sacco di esercitazioni: il primo sito si focalizza sulla spiegazione dell’uso delle nuove funzionalità, il secondo è alimentato dalle richieste degli utenti.

Domande ricorrenti

È già in linea e si compone delle diverse Domande ricorrenti in nostro possesso. È in fase di traduzione e il nostro desiderio principale è mantenerlo sempre aggiornato.

Per i principianti¶

A differenza di Mediawiki, Sphinx funziona in modo più simile a come scriviamo il codice di Krita.

Per prima cosa, vorrai parlare con noi! Per farlo, puoi unirti alla stanza chat «#krita» via matrix. Qui trovi un’introduzione a Matrix. Crea una matrix sull’account webchat.kde.org e unisciti al canale the #krita:kde.org. O, più importante, crea un account in identity.kde.org. L’account che crei in identity può essere utilizzato sia per l’accesso a invent.kde.org, sia per phabricator, il luogo dove organizziamo lo sviluppo di Krita.

Sphinx funziona scrivendo semplici file di testo con linguaggio di marcatura reStructuredText, i quali vengono poi presi e trasformati nel manuale. Teniamo traccia delle modifiche, all’interno del manuale, inserendole all’interno di un sistema di controllo versione chiamato Git.

Eseguire delle modifiche¶

Siccome usiamo Git, solo poche persone possono inviare i file nel sistema di controllo versione. Se vuoi fare delle modifiche devi dunque impostarle per la revisione.

Creazione di richieste di fusione mediante la modalità Edit¶

Nota

Questo metodo è idoneo solo se non hai accesso push ai repository KDE. In caso contrario, eseguirebbe il commit delle tue modifiche direttamente al repository, che è contrario alle attuali linee guida.

Consigliato per gli utenti senza conoscenze tecniche.

Non consigliato se vuoi cambiare più di un file alla volta (vedi Creazione di richieste di fusione mediante WebIDE o Creazione di richieste di fusione mediante riga di comando se vuoi cambiare più file o semplicemente modificarne solo uno per richiesta di fusione).

Se devi contribuire a molte modifiche, ti raccomandiamo di seguire queste istruzioni.

Ottieni una identità KDE.
Collegati a KDE_gitlab.
Vai al repository e premi fork.
Sarai ora reindirizzato al fork del tuo repository. In genere è posizionato in invent.kde.org/YOUR_KDE_LOGIN_NAME/docs-krita-org.
Torna al repository ufficiale. Assicurati di essere in Documentation > Krita.org Documentation e non nel tuo fork personale: in caso contrario, questo metodo non funzionerà correttamente.

GitLab possiede un’opzione per modificare i file al suo interno. Per accedere a questa funzione, vai a Repository ‣ Files.

In cima alla pagina dovresti vedere un riquadro a tendina con master come elemento predefinito.

Trova il file da modificare, aprilo e fai clic su Edit.

Apporta le modifiche (nota: in questa modalità puoi modificare solo un file alla volta).

Vai al riquadro di testo più piccolo e scrivi un messaggio sulle modifiche che hai fatto nella sezione dei messaggi di commit. Una volta terminato premi Commit changes. Verrà creata una richiesta di fusione, completa gli altri campi come spiegato qui: Linee guida per le richieste di fusione (merge requests).

L’aspetto negativo è che al momento non vi è modo di avvisarti se utilizzando questo metodo hai commesso errori col mark-up. Verifica gli errori con l”Editor di Sphinx in linea (copia e incolla tutto il file che stai modificando).

Attenzione

Edit e WebIDE sono due cose diverse! Assicurati di aver selezionato Edit.

Creazione di richieste di fusione mediante WebIDE¶

Consigliato agli utenti che conoscono un po” Git e vogliono modificare più file alla volta.

Non consigliato se non sai cos’è un ramo (branch) (vedi invece Creazione di richieste di fusione mediante la modalità Edit).

Per accedere a KDE_gitlab e creare il tuo fork, segui le istruzioni sopra riportate.
Vai al tuo fork (accertati che l’URL contenga il tuo nome utente).
Accertati di essere sul ramo master.
Fai clic su WebIDE. Vieni indirizzato a una pagina contenente un elenco di file sulla sinistra e uno spazio vuoto per il loro contenuto sulla destra.
Apri i file da modificare ed esegui le modifiche.
Fai clic su Commit…. Fai doppio clic su tutti i file nella categoria Unstaged changes per spostarli in Staged changes.
Fai di nuovo clic su Commit… - si aprirà un riquadro per il messaggio di commit. Scrivi un messaggio esplicativo sulle modifiche apportate.
Accertati che le impostazioni siano corrette: devi selezionare Create a new branch (il nome del ramo dev’essere: [nome_utente]/[descrizione molto breve delle tue modifiche]). Se hai completato le modifiche assicurati che sia spuntata l’opzione Start a new merge request. In caso contrario dovrai eseguire manualmente una nuova richiesta di fusione successivamente.
Fai clic su Stage & Commit.
Compila correttamente tutti i campi: vedi Linee guida per le richieste di fusione (merge requests).
Per creare manualmente una nuova richiesta di fusione, vai al repository ufficiale del Manuale di Krita (assicurati che l’URL ora non contenga il tuo nome utente) e fai clic su Create a new merge request (pulsante verde acceso alla sinistra). Seleziona il tuo fork e il ramo che hai creato in WebIDE.

Nota

Se non possiedi un accesso push al repository ufficiale, GitLab non ti consentirà di salvare le tue modifiche, se stai modificando per sbaglio il repository ufficiale (e Create a merge request non ti sarà di aiuto per questo: devi ancora inviare le modifiche al tuo ramo, ma se non possiedi accesso push non lo puoi fare). Otterrai semplicemente il messaggio: An error occurred whilst committing your changes. Please try again.

In questo caso, copia semplicemente il contenuto di tutti i file che hai modificato, vai al tuo fork e incollali nel WebIDE del fork.

Creazione di richieste di fusione mediante riga di comando¶

Consigliato agli utenti che sanno come funziona Git e come utilizzare la riga di comando.

Non consigliato se non sai cos’è un ramo (branch) (vedi invece Creazione di richieste di fusione mediante la modalità Edit).

Per accedere a KDE_gitlab e creare il tuo fork, segui le istruzioni sopra riportate.
Clona localmente il repository con:guilabel:git clone. La pagina del repository contiene gli URL da cui devi eseguire il git clone, e dopo poi inviare (push) al tuo fork. Il vantaggio di questa procedura è che puoi utilizzare tutti gli strumenti presenti nel computer per modificare questi file di testo, così come compilare localmente il manuale per controllare gli errori (devi procedere un passo alla volta).
# per l'accesso ssh git clone git@invent.kde.org:<username>/docs-krita-org.git git remote add upstream git@invent.kde.org:documentation/docs-krita-org.git # per l'accesso https git clone https://invent.kde.org/<username>/docs-krita-org.git git remote add upstream https://invent.kde.org/documentation/docs-krita-org.git
Ricorda di estrarre sempre le modifiche dal repository ufficiale prima di eseguire quelle nuove:
git pull upstream master
Accertati di aver creato un nuovo ramo per le tue modifiche, dato che da settembre 2019 tutte le modifiche devono essere ramificate da master.
git checkout master # poi: git checkout -b "<nome_utente>/<descrizione della nuova funzionalità>"

Dopo aver apportato le modifiche, eseguine il commit e inviale al tuo fork. Per una descrizione dettagliata su come usare Git con terminale nel caso di questa procedura, consulta Forking on Gitlab.

# installa il pacchetto python3-sphinx per il tuo sistema. Per esempio, per Ubuntu:
sudo apt install python3-sphinx
# crea il manuale (segnala potenziali errori, consente di ispezionare le modifiche nel browser)
make html
# assicurati che tutto sia corretto
git status
git diff
# aggiungi tutti i file
git add .
# esegui il commit delle tue modifiche
git commit
# invia le modifiche al tuo fork
git push

Per finire, vai al sito web del repository originale, poi a Merge Requests. Seleziona il tuo fork e il ramo corretto e crea una nuova richiesta di fusione. Per le istruzioni su come compilare i campi consulta Linee guida per le richieste di fusione (merge requests).

Linee guida per le richieste di fusione (merge requests)¶

I tuoi messaggi di commit devono rispettare gli standard qui spiegati: How to Write a Git Commit Message
Title e Description devono spiegare quali modifiche hai fatto e perché le hai fatte, proprio come un messaggio di commit. Anche in questo caso segui le linee guida dal collegamento sopra indicato.
Target deve puntare a master.
Se sei certo che la richiesta di fusione esiga delle modifiche successive, inizia il titolo della richiesta di fusione con [WIP].
Accertati di aver attivato l’opzione Allow commits from members who can merge to the target branch. – per ragioni tecniche si rende necessaria l’esecuzione del rebase della richiesta di fusione su master, operazione che modifica tecnicamente la richiesta, ma non ne cambia l’effettivo contenuto. Il rebase può essere eseguito da te o dal revisore – se non vuoi preoccuparti troppo in seguito è meglio che attivi questa opzione, in modo che il revisore lo possa eseguire in pochi passaggi.
Nella maggior parte dei casi, puoi tranquillamente attivare l’opzione Delete source branch when merge request is accepted.
A meno che i revisori non indichino diversamente, attiva l’opzione Squash commits when merge request is accepted. La prima riga del messaggio di commit proverrà dal Titolo della tua richiesta di fusione e il resto verrà preso dalla sua Descrizione.
Quando hai terminato la tua richiesta di fusione, collegati a IRC (vedi Internet Relay Chat) e chiedi a qualcuno con accesso push di aggiungere l’etichetta Needs Review alla tua richiesta.
Se sono presenti errori, potresti ricevere dei commenti sulla tua richiesta di fusione. Correggi gli errori nel tuo ramo con uno dei metodi seguenti.
- Se vuoi utilizzare la modalità Edit, vai alla sezione Changes della richiesta di fusione e fai clic sull’icona a forma di matita (che contiene il suggerimento Edit) per utilizzare di nuovo la modalità Modifica.
- Se vuoi utilizzare la modalità WebIDE, vai al tuo fork, seleziona il ramo in cui sono presenti le modifiche e vai al WebIDE.
- Se modifichi i file nel tuo computer e lavori col terminale, assicurati di trovarti nel ramo corretto e invia le tue modifiche - GitLab aggiornerà automaticamente la tua richiesta di fusione.
Dopo aver eseguito le modifiche, assicurati di chiedere a qualcuno di cambiare l’etichetta di nuovo in Needs Review.

Per informazioni più dettagliate, consulta Forking on Gitlab nella sezione tecnica.

Nota

Al momento della stesura di questa guida, l’impostazione delle etichette sulle richieste di fusione è possibile solo dai collaboratori con permessi di scrittura nel repository ufficiale (se non sai cosa significa, probabilmente non sei uno di loro). Per questo motivo, quando crei o modifiche la tua richiesta di fusione devi accedere a IRC (vedi La Comunità di Krita) e chiedere a qualcuno di impostare le etichette per te.

Costruire il manuale tramite riga di comando¶

Per coloro i quali vogliono per prima cosa provare delle modifiche prima di imbarcarsi subito in una richiesta di fusione (e già sanno utilizzare git e la riga di comando), questo aspetto è descritto come parte del passaggio 5. in Creazione di richieste di fusione mediante riga di comando.

Filosofia generale¶

Serve per determinare quale sia uno stile di scrittura appropriato. Uno stile di scrittura, che si considerino o no le sue qualità pratiche o estetiche, si basa su un obiettivo o una filosofia generale. Cosa vogliamo ottenere col manuale e a chi è esso rivolto?

Popolazione di interesse e pubblico di riferimento¶

Non possiamo parlare di uno specifico segmento di popolazione come se sapessimo che tutti gli utenti di Krita sono uomini di 55 anni. Krita è utilizzato da una grande varietà di persone, e siamo davvero molto orgogliosi di avere una base di utenti così varia.

Tuttavia, sappiamo alcune cose sui nostri utenti:

Sono artisti. Questo è esplicitamente il tipo di utente cui siamo rivolti.
- Sappiamo, dunque, che preferiscono le belle immagini.
- Sono visivi.
- Cercano di realizzare belle immagini.

Dunque lo scopo implicito di ciascuna pagina dovrebbe essere descrivere la funzionalità utilizzata per ottenere belle immagini.

Oltre a ciò, abbiamo osservato i gruppi seguenti:

Gli studenti delle scuole superiori e dei college provano il software grafico per le illustrazioni. In genere hanno qualche esperienza precedente di software grafico, tipo Paint Tool SAI o Photoshop, ma hanno bisogno di essere introdotti alle possibilità in Krita. La forza di questo gruppo è che si condividono molte informazioni, quali suggerimenti, consigli ed esercitazioni.
I professionisti, persone che vivono guadagnando il proprio denaro col software grafico digitale. La forza di questo gruppo è che possiedono molte conoscenze e sono disposti a donare per migliorare il programma. Ce ne sono di due tipi:
- Professionisti non tecnici. Sono persone che non comprendono veramente la parte prettamente tecnica di un pezzo di software, ma hanno sviluppato negli anni un metodo di lavoro solido e lavorano col software utilizzando il loro istinto finemente perfezionato. Sono in genere illustratori, pittori e persone che lavorano con la stampa.
- Professionisti tecnici. Sono persone che utilizzano Krita come parte di una serie di strumenti e sono interessati alla matematica precisa e la manipolazione precisa dei pixel. In genere lavorano nel settore dei giochi e dell’industria degli effetti speciali, ma tra di loro si trovano occasionalmente anche esperti scientifici.
Hobbisti adulti e anziani. Questo gruppo non sa molto sui computer e sembra sempre inciampare in quel piccolo gradino che manca da un’esercitazione. La forza del loro gruppo è che si adatta a metodi di lavoro non convenzionali tratti dalla vita reale di cui gli studenti non conoscono molto e per i quali i professionisti non hanno tempo, creando del buon materiale, e avendo pure influenze sugli atteggiamenti del primo gruppo nelle comunità più estese.

Da questi quattro gruppi si evince che…

ne esiste solo uno tecnico. È per tale motivo che abbiamo bisogno delle pagine concettuali, affinché si possa creare una base solida su cui basarsi per scrivere i testi dei nostri manuali.
tre di essi hanno avuto esperienza precedente col software e potrebbero aver bisogno di guide e procedure alla migrazione.
due di essi necessitano sapere come far cooperare Krita con altro software.
due di essi non sanno cosa stanno facendo e potrebbero avere la necessità di essere guidati attraverso i passaggi di base.

Da tutto ciò possiamo ricavare le regole seguenti:

Scrittura generale¶

Usa l’inglese americano, se possibile.: Nel manuale utilizziamo l’inglese americano, conformemente al suo uso predefinito per l’interfaccia grafica di Krita.
Usa un linguaggio garbato, ma non accademico.: Come comunità vogliamo essere graditi agli utenti, dunque cerchiamo di evitare un linguaggio che sia ostile. La volgarità non è permessa da KDE ma, all’opposto, uno stile accademico a cui né lo scrittore, né il lettore sono avvezzi, potrebbe trasmettere l’idea che il testo sia molto più complesso del dovuto e allontanare di conseguenza gli utenti.
Evita l’uso di immagini GIF (oggetto di discussione): La ragione è che le persone affette da epilessia potrebbero avere problemi con immagini che si muovono ad alta velocità. Per lo stesso motivo, le immagini GIF possono a volte veicolare un carico eccessivo di informazioni. Se non puoi fare a meno di utilizzare immagini GIF, avvisa almeno il lettore di questo problema all’inizio della pagina.
Mantieni il tutto compatibile con le traduzioni: Questo significa l’uso di immagini SVG per le infografiche, e l’uso del markup appropriato per un testo specificato.

A proposito di foto e disegni¶

Scoraggeremmo l’uso di foto e disegni tradizionali nel manuale, se essi non illustrano un concetto. La ragione risiede nel fatto che è piuttosto stupido, e un po” disonesto, mostrare un lavoro di Rembrandt all’interno dell’interfaccia grafica di Krita, quando ci sono tanti lavori contemporanei che sono stati fatti con Krita. Tutti i disegni del fumetto Pepper&Carrot è stato fatto con Krita e sono disponibili i file originali, dunque se non hai a portata di mano un’immagine, inizia da lì. Le fotografie dovrebbero essere evitate, dato che Krita è un programma di disegno. Troppe foto possono dare l’impressione che Krita stia cercando di essere una soluzione per il ritocco fotografico, che non è per nulla il suo obbiettivo.
Naturalmente vogliamo ancora mostrare determinati concetti in gioco nelle fotografie e nei quadri dei maestri, quali l’effetto lucido o la luce indiretta. In questo caso, aggiungi un titolo che menziona il quadro o il pittore, oppure specifica che è una fotografia.
Le foto possono essere ancora utilizzate per il photobashing e simili, ma solo se utilizzate, ovviamente, in un contesto relativo al photobashing.

A proposito delle immagini in generale¶

Evita il testo nelle immagini e utilizza invece la didascalia. Puoi farlo con la direttiva figure.
Se proprio devi utilizzare del testo, crea un SVG, in modo che il testo all’interno possa essere facilmente manipolato, oppure cerca di minimizzarne la quantità.
Cerca di creare immagini di alta qualità. Diamo l’idea che stiamo utilizzando un programma di disegno!
Ricorda che il manuale è rilasciato sotto licenza GDPL 1.3, dunque anche immagini inviate saranno rilasciate sotto tale licenza. Nel caso di licenza CC-By-Sa/CC-By, assicurati che il file sia correttamente attribuito tramite una didascalia per figure. Inutile sottolinearlo, non inviare immagini protette da copyright restrittivo.

Protocollo¶

Qui definiamo tutta la procedura di lavoro noiosa.

Attribuzione di tag e rami¶

L’aggiunta e la rimozione di testi sarà fatta nel ramo draft.

I risultati delle revisioni per le pagine vecchie saranno considerati correzioni di errori (bugfixes) e passeranno dunque al ramo master e fusi nel ramo draft, laddove necessario.

Prima che il ramo draft sia fuso per un rilascio spcificato:

Nel ramo master sarà creato un tag con la versione vecchia.
Il ramo draft viene prima verificato due volte: che sia aggiornato sia il suo numero di versione, sia la copertina epub.

Il ramo draft non sarà fuso fino a un giorno prima del rilascio, per mantenere le pagine intatte per abbastanza tempo.

Ciascun rilascio conterrà una versione del file epub caricato come parte del processo di rilascio. .. Da dove scarico i file POT? E le versioni tradotte?

Rimozione delle pagine¶

Se in una determinata versione una funzionalità viene rimossa, le pagine corrispondenti:

saranno prima contrassegnate come disapprovate (deprecated).

Questa azione si esegue in questo modo:

.. deprecated:: version number

    Testo che indica cosa l'utente deve fare senza questa funzionalità.

Sarà collegata a una pagina chiamata «deprecated»
Se la versione successiva si ripresenta, tutte le pagine collegate nella sezione «deprecated» saranno rimosse.

Aggiunta delle pagine¶

Assicurati che si trovi nella posizione giusta.
Segui Convenzioni di mark-up per il Manuale di Krita in modo da assicurarti che la pagina sia correttamente formattata.
Aggiungi la pagina all’indice dei contenuti.

Se una funzionalità è nuova, aggiungi in versionadded:

.. versionadded:: version number

    qualcosa di opzionale o altro.

Come per le immagini, non aggiungere testo se non hai il permesso di aggiungerlo. Ciò significa che il testo o è scritto da te, o l’autore originale ti ha permesso di trasferirlo. Il manuale è rilasciato con licenza GDPL 1.3+, dunque anche il testo sarà rilasciato sotto questa licenza.

Modifica delle pagine¶

Se riscrivi completamente una pagina, al contrario della revisione, la pagina risultante deve essere revisionata.

Se modifichi una pagina perché una funzionalità è stata cambiata, e sei autorizzato ad applicare direttamente i tuoi cambiamenti, la modifica può essere inviata senza revisione (a meno che tu non preferisca che sia revisionata), ma devi aggiungere:

.. versionchanged:: version number

    Questa e quella modificate.

In ogni caso, verifica se vuoi aggiungere te stesso al campo autore nella sezione metadati che si trova in alto.

L’uso di deprecated, versionadded e versionchanged col numero di versione ci consente di ricercare facilmente questi termini nel manuale col comando grep:

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

Pagine difettose¶

Se una pagina sfugge al controllo, …

Crea una richiesta di fusione (merge request) come specificato nella sezione Eseguire delle modifiche.
Crea un’attività nel Manual Project Workboard.
Fai una segnalazione di errore in bugzilla sotto il progetto Krita alla sezione “documentation”.

Revisione¶

Ci sono due tipi di revisione da fare.

La più importante è la revisione delle modifiche apportate dagli utenti. Puoi farlo in KDE_gitlab in due modi:

Revisione delle richieste di fusione (merge requests)

Puoi aiutare a revisionare le richieste di fusione. La revisione delle richieste viene fatta in genere dai programmatori per ricercare errori nel codice altrui, ma dato che il codice di programmazione non è altro che normale testo, possiamo utilizzarla per controllare anche tutti i refusi!

Una richiesta di fusione (merge request) è un insieme di modifiche apportate a un documento (aggiunte, rimozioni) inserito in un file comprensibile dalla macchina. Quando un utente invia una richiesta di revisione (su un sistema come GitLab o GitHub esso si chiama merge o pull request), le persone responsabili dei file originali dovranno controllarli e commentare le parti che devono essere modificate. Questo permette loro di commentare su parti come refusi o scrittura eccessivamente elaborata, ma anche parti sbagliate. Dopo che è stata accettata, la patch può essere inviata (pushed) al sistema di controllo della versione.
Commento delle modifiche nel manuale.

Il commento delle modifiche accade a posteriori. Puoi commentare una modifica andando al messaggio di invio (commit; dalla pagina del deposito, vai alla cronologia e fai clic su una voce), dove potrai fare commenti sulle modifiche apportate.

In entrambi i casi, l’interfaccia consiste in un’esposizione delle differenze: sulla sinistra si trova la vecchia versione, sulla destra la nuova. Le righe che sono state aggiunte saranno contrassegnate in verde e quelle che sono state rimosse in rosso. Per aggiungere un commento “in linea” puoi fare clic sull’icona a forma di fumetto.

Il secondo importante passaggio in cui il manuale deve essere revisionato è sull’intero file. Molte pagine sono state verificate per la correttezza, ma non per lo stile e la grammatica.

Per questo passaggio dovrai seguire le indicazioni contenute nella sezione Eseguire delle modifiche, in modo da avere accesso completo alle pagine e poterle modificare.

Traduzione¶

La traduzione del manuale è gestita dalla Comunità di localizzazione di KDE. Per collaborare al lavoro di traduzione, vai al sito della localizzazione, seleziona l’elenco delle squadre di traduzione, seleziona la lingua in cui vuoi tradurre e segui le istruzioni contenute nella pagina della squadra per metterti in contatto con i traduttori esistenti.

Per istruzioni più generali riguardo la collaborazione nella localizzazione di KDE, consulta https://community.kde.org/Get_Involved/translation.

La squadra di localizzazione ha accesso ai file PO di questo manuale, che è un tipo di file utilizzato dai programmi di traduzione come POEdit e Lokalize. Una squadra di traduzione è in grado di lavorare insieme alla traduzione di questi file e caricarli nel server SVN delle traduzioni. Ogni giorno uno speciale script preleverà le traduzioni da SVN e le invierà alla sezione del manuale per la loro incorporazione.

Se una squadra di traduzione vuole fornire le proprie immagini, queste possono essere tradotte. Tutte le immagini che si trovano nella cartella delle immagini sono, per impostazione predefinita, per il codice linguistico «en», ossia inglese. Quando vuoi tradurre un’immagine specifica, vai in quella cartella, crea una sotto-cartella col codice della tua lingua e aggiungici dentro le versioni tradotte delle immagini. In questo modo Sphinx ricercherà la versione italiana di /images/Pixels-brushstroke.png in /images/it/Pixels-brushstroke.png e una versione italiana di /images/dockers/Krita-tutorial2-I.1-2.png in /images/dockers/it/Krita-tutorial2-I.1-2.png.

Anche le traduzioni completate devono essere aggiunte allo script per la compilazione al fine di comparire in linea. Per farlo, le squadre di traduzione che sono certe dello stato della loro traduzione devono contattare la squadra di Krita principale tramite la mailing list kimageshop (kimageshop@kde.org) o foundation@krita.org.

Altro¶

Per le convenzioni del testo in formato «restructured», consulta Convenzioni di mark-up per il Manuale di Krita.